On Mon, Nov 1, 2021 at 11:12 AM Jan Høydahl <[email protected]> wrote:
> > > > 1. nov. 2021 kl. 14:46 skrev Ilan Ginzburg <[email protected]>: > > A node not having node.roles defined should be assumed to have all > roles. Not only data. I don't see a reason to special case this one or any > role. > > +1, make it simple and transparent. No role == all roles. Explicit list of > roles = exactly those roles. > I want this to be the user's experience, but I'm hoping for it to be implemented such that on startup, the node assumes (declares) all roles if none are specified. It then displays exactly the same configuration as if one manually explicitly configured all roles. Failing to declare roles when starting the node should be indistinguishable at runtime from having declared every role. This is so that client code isn't special casing every check. > > > (Gus) See my comment above, but maybe preference is something handled as > a feature of the role rather than via role designation? > > Yea, we always need an overseer, so that feature can decide to use its > list of nodes as a preference if it so chooses. > > > Aside: I think it makes it easier if we always prefix Solr env.vars and > sys.props with "SOLR_" or "solr.", i.e. -Dsolr.node.roles=foo. That way we > can get away from having to have explicit code in bin/solr, bin/solr.cmd > and SolrCLI to manage every single property. Instead we can parse all ENVs > and Props with the solr prefix in our bootstrap code. And we can by > convention allow e.g. docker run -e SOLR_NODE_ROLES=foo solr:9 and it would > be the same ting... > > Jan > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
