I agree with Jan, when thinking about making Solr as cloud friendly as possible EnvVars and (to a lesser extent) sysProps are much preferable than having a setting in the solr.xml. This is because it's easier to customize EnvVars per-node, while customizing a config file is much harder, as those tend to be static and shared across a whole environment.
Also thanks for linking that SIP Jan, very applicable. - Houston On Fri, Nov 5, 2021 at 5:19 PM Jan Høydahl <jan....@cominvent.com> wrote: > Thinking of these roles as labels, I think sysProps and envVars are the > two universal methods, and nothing wrong with that. > I keep trying to think cloud native and container, so having excellent 1st > class support for env.vars for such configs is a priority to me. > Most tools, CI-environments etc have built-in support for env.vars, and so > it makes sense to me. > > See > https://cwiki.apache.org/confluence/display/SOLR/SIP-11+Uniform+cluster-level+configuration+API > for some interesting ideas around cluster/node level config. > > See > > 5. nov. 2021 kl. 15:04 skrev Gus Heck <gus.h...@gmail.com>: > > Agree better to something other than sysprops. an arg in the start script > would be friendlier than -D props which generally are irritatingly verbose > and expose too much implementation. > > We lack a config file per level. solr.xml does double duty as global and > per-node depending on how it's used (zk or filesystem). > > Config file names are confusing too. Our file names are legacy of > non-cloud mode I think, and we really should at some point (10.x?) rework > configs to be cluster.xml, node.xml, collection.xml (formerly > solrconfig.xml) and schema.xml (and maybe support something other than xml, > but that's not nearly as important as clarity in naming, and having > features) > > But this is all straying way off topic and should have its own SIP if > someone seems to have time for it :) > > On Thu, Nov 4, 2021 at 6:07 PM Shawn Heisey <elyog...@elyograg.org> wrote: > >> On 11/4/21 2:51 PM, Noble Paul wrote: >> > The SIP can be boiled down to the following >> > >> > * *Tag a node with a label (role) using a system property* >> > ** Use the placement plugin to whitelist/block list certain nodes* >> > ** Publish the roles through an API* >> >> >> In general, for Solr, do we like the idea of having things controlled by >> system properties? >> >> I would think solr.xml would be the right place to configure this, >> except that people can and probably do put solr.xml in zookeeper, which >> would mean every system would have the SAME solr.xml, and we're back to >> system properties as a way to customize solr.xml on each system. >> >> I have never used system properties to configure Solr. When I customize >> the config, I will often remove property substitutions from it and go >> with explicit settings. My general opinion about system properties is >> that if they're going to be used, they should DIRECTLY configure the >> application, not be sent in via property substitution in a config file. >> I've never liked the way our default configs use that paradigm. It >> means you cannot look at the config and know exactly how things are >> configured, without finding out whether system properties have been set. >> >> What color do others think that bikeshed should be painted? >> >> Thanks, >> Shawn >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > > >
