THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Every role also has a list of modes under which a node can be. For certain roles (e.g. overseer) it is useful for potentially finer grained control of how strictly or loosely that role applies for that node.
- Most roles would just have two modes (on, off)
- In special cases a role might have more modes, e.g. "overseer" role to have (allowed, disallowed, preferred) modes.
- For every role, one of the modes is assumed to be a defaultIfAbsent (see below in roles API section, supported GET call), i.e. on a node that doesn't specify that role, the mode for that role that is assumed for the functionality for that role.
- For example, if a node starts with "-Dsolr.node.roles=data:on", then it will be assumed that the node has overseer has mode "disallowed" (i.e. the defaultIfAbsent mode of the overseer role).
- Note: Users don't need to bother about this concept much. This is for tighter representation of the roles and modes in our system for implementation purposes, and for developers implementing new roles.
The following roles are proposed (based on existing functionality):
...
- Do you have a new functionality or existing functionality that you want the users to be able to turn on/off on certain nodes, esp from the point of view of functional (role based) isolation of nodes? Yes: good candidate, No: you might not need a separate role
- Do you want the functionality associated with the role to be turned on for any user upgrading to this new Solr version (without having to explicitly turn it on)?
- Yes: Change the current default value for "solr.node.roles" from "data:on,overseer:allowed" to "data:on,overseer:allowed,myrole:on"
- No: Either don't change the default of "solr.node.roles" or change it from "data:on,overseer:allowed" to "data:on,overseer:allowed,myrole:off"
- How to tell users who are already using some roles on their nodes on how to turn on this functionality?
- In upgrade notes and/or in ref guide, instruct the users with language similar to this: "If you're already explicitly using roles (i.e. you are using "solr.node.roles" for your nodes), then you should append ",myrole:on" to all nodes where you wish to enable this functionality (introduced by myrole)"
- Designate one of the modes as a defaultIfAbsent. Most likely that's going to be "off" or "disallowed" etc.. This affects only those nodes where some roles are explicitly or implicitly configured, but this new role is not present.
Other notes
- Every time a node starts up with specified roles, the node assumes it is the correct role for that node and publishes those roles in ZK after successful startup.
- If a node is started with a -Dsolr.node.roles parameter that doesn't have a data role (or with data:off), but it already has data hosting replicas on it, the startup fails with an error (and a hint indicating how to move replicas away from this replica).
...