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 <[email protected]>: > > 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 <[email protected] > <mailto:[email protected]>> 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: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play)
