> If we make collections role-aware for example (replicas of that collection can only be > placed on nodes with a specific role, in addition to the other role based constraints), > the set of roles should be user extensible and not fixed. > If collections are not role aware, the constraints introduced by roles apply to all collections > equally which might be insufficient if a user needs for example a heavily used collection to > only be placed on more powerful nodes.
I feel node roles and role-aware collections are orthogonal topics. What you describe above can be achieved by the autoscaling+replica placement framework where the placement plugins take the node roles as one of the inputs. > It does impact the design from early on: the set of roles need to be expandable by a user > by creating a collection with new roles for example (consumed by placement plugins) and be > able to start nodes with new (arbitrary) roles. Should such roles follow some naming syntax to > differentiate them from built in roles? To be able to fail on typos on roles - that otherwise can be > crippling and hard to debug. This implies in any case that the current design can't assume all > roles are known at compile time or define them in a Java enum. I think this should be achieved by something different from roles. Something like node *labels* (user defined) which can then be used in a replica placement plugin to assign replicas. I see roles as more closely associated with kinds of functionality a node is designated for. Therefore, I feel that replica placements and user defined node labels is out of scope for this SIP. It can be added later in a separate SIP, without being at odds with this proposal. On Mon, Nov 1, 2021 at 8:42 PM 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. > > > (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] > >
