The categories and your comments make sense to me.
I looked across some of the individual proposals:
> collection.configName
Where is this used as a system property override? I looked and don't see
it.
"enabled" vs "disabled": can we standardize on "enabled"?
> managed.schema.mutable
In this case (and likely others if I found one), there is no production
code containing this string. It is only a test config file containing
${managed.schema.mutable} and probably test code that sets it. I don't
think we should put these in the list; the list is long enough as it is.
> disable.configEdit. => solr.configset.edit.disabled
We should then broaden its use to cover the configset broadly, thus block
the schema edit API and maybe more. Right now it only covers mutability of
solrconfig.xml (via a JSON overlay). I'm good with that, but it increases
the scope.
On Fri, Jan 12, 2024 at 6:39 AM Jan Høydahl <jan....@cominvent.com> wrote:
> I like the simplicity of lowercasing and changing underscore for dot, so
> if we can avoid camelCase that would be best.
>
>
> I started a WIKI page for easier collaboration on this topic:
> https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure
>
> There I enumerated each source folder and tried to deduce some commonality
> and structure.
>
> I also enumerated all current sysProps used in the codebase (by scanning
> src for various System.getProperty, Boolean.getBoolean, EnvUtils.getProp
> variations). That is the second table on the page. Looking at all those
> system property names we have today is depressing, they are all over the
> place and 157 in number (although some are zk, hadoop or java owned and
> some relate to tests).
>
> I did a small stab on mapping those old props to a new proposed name, but
> the list is looong, so good with some collaboration on this. I experience
> that the shape of the hiearchy molds as I encounter more real-life
> examples. And there are tons of decisions, e.g. wether we should force
> solr.security as a prefix for all things security or to keep the shorter
> solr.auth.*. Same with solr.search.*
>
> It is also encouraging to see the list of existing solr.xxx keys in use
> that are already well structured (solr.jetty.keystore.password,
> solr.kerberos.keystore.password, solr.log.level etc).
>
> Jan
>
>
> > 11. jan. 2024 kl. 03:36 skrev David Smiley <dsmi...@apache.org>:
> >
> > On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl <jan....@cominvent.com
> <mailto:jan....@cominvent.com>> wrote:
> >
> >> Hi,
> >>
> >>> Using this one as an example; what would you propose?:
> >>> * solr.shardSplit.checkDiskSpace.enabled
> >>
> >> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
> >> But say we standardized the first component layer to be one of "query",
> >> "index", "collection", "schema", "cluster", "node" or whatever set of
> >> top-level components make sense. Then I guess shard split would be
> >> "solr.collection.shard.split.checkDiskSpace.enabled" or similar.
> However, I
> >> find it hard to find good generic top-level categories for Solr that are
> >> consise and no overlapping.
> >>
> >
> > So the module can't be camel-case but checkDiskSpace can? What about
> > hyphens in a sys prop, mapped to an underscore in an env var?
> >
> >> "solr.collection.shard.split.checkDiskSpace.enabled"
> >
> > Not bad.
> > I bet it's hard to find good generic top-level categories. Feel free
> to
> > take a stab at this and share for review. It doesn't need to be perfect,
> > just not nausea inducing :-)
> >
> >
> >>> Are you saying the camel case is a problem?
> >>
> >> No necessarily. The concern was that there should be a well-defined way
> to
> >> translate an SOLR_ENV_VAR into system property, so we don't need to
> touch
> >> bin/solr[.cmd] every single time. And it would be hard for an algorithm
> to
> >> know that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED
> >> env.var into the exact combination of dot separation and camelCase used
> >> above. An alternative could be using a combination of underscore and
> dash,
> >> such as "SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate
> >> underscore with dot and dash with Camelcase. We'd need to disallow dash
> in
> >> property names then...
> >>
> >
> > Alternatively simply normalize both sys props and env vars using the same
> > scheme. In theory it would allow crazy variation but if we only document
> > each named toggle a certain way then it doesn't matter.
>
>
