I've updated the SIP document with the recent changes. Also, added a new section to provide guidance for adding new roles.
On Mon, Dec 6, 2021 at 8:37 PM Ilan Ginzburg <ilans...@gmail.com> wrote: > Ishan, > > > > Using a string separate from the role definitions (Ishan) makes it too > easy to have roles for which the default configuration is unknown. > > > > Ilan, can you please elaborate (perhaps with an example) as to what you > mean here? > > If the default string for all roles for nodes with no roles configured > got customized in a specific cluster (say it got changed to "data:on, > overseer:disallowed"), when a new version of Solr with a new role gets > deployed, that new role will not have a default defined in the string, > which might not be the intent (if the new role for example is "ui" and > the default expected to be "on", "ui" not being defined in the string > makes the default likely be "off" - more about that default below). > That new version (which introduces "ui" role) will modify the assumed default value for solr.node.roles from "data:on,overseer:allowed" to " data:on,overseer:allowed,ui:on". That means after upgrade, the nodes will have it turned on since the user is not using any role defined. If the user is already using roles on his/her nodes, then he/she would need to append "ui:on" to those nodes where he/she wants this new functionality to run. I've added a new section to the SIP document (guidance for adding new role to clarify this). > > > As per my proposal, a node that was started with explicit roles, but > without a particular role defined for it will have no functionality > associated with that role running on it at any point in its lifetime. For > example if a node was started with "-Dnodes.roles=data:on" will never have > anything to do with overseer functionality. There is no concept of defaults > in that case. > > That's the point. The code dealing with the overseer role will have to > make different decisions based on the role being "on" or "off", or if > we go with parameters, the role being "allowed", "disallowed", > "preferred". > > When you say "will never have anything to do with overseer > functionality" what does that mean when roles are defined but not the > overseer role? I assume that should mean that for this node, overseer > is "disallowed" (or pick any other value of the 3 possible ones). > Therefore, there is a default when the role is not defined (and other > roles are defined). If "will never have anything to do with overseer > functionality" is an option different from the 3 other ones, then we > end up with 4 different overseer related configuration options (but I > think it's better to be able to explicitly specify all configuration > options). > > So that's my point. A per role default for when a role is not defined. > Ah, I now see. Yes, there will be such a default for all roles that is assumed when no role is applied on that node. For "data" role, it is "off". For "overseer", it is "disallowed". Does that make sense? > And if we have this for all roles, this is the node default roles > config when no roles are defined at all. When introducing role "ui" > with a role default of "on", then all existing nodes that do not > specify a configuration for this role (regardless of if they specify a > configuration for other roles) get the sound default. > > Ilan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
