On Mon, Dec 6, 2021 at 9:18 PM Ishan Chattopadhyaya < [email protected]> wrote:
> 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 <[email protected]> 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? > Ilan, I've updated the SIP document to reflect this with a concept called "defaultIfAbsent". Please review the SIP and let me know if it accurately reflects your intention. > > > >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >>
