> > > My proposal is that ALL roles are always ALLOW if not specified explicitly. > > As explained several times before, this is a problem for new roles introduced > in future. > Those roles will get turned on on all nodes after an upgrade, whether a user > wants or not.
But you're not hearing me. This is a constructed problem assuming that we recommend users with huge clusters to start without explicitly specifying roles. Small custers with limited load will run happily without specifying roles. Thus a 3-node cluster will have ALL features available on ANY node without doing anything. Exactly like in 8.x And large clusters with the need for specialized nodes will specify roles on EVERY node. > A user explicitly mentions which roles his nodes want to assume, but after an > upgrade he/she sees that node performing a new role. This is confusing. You are misunderstanding. The premise for the roles feature from the beginning was to embrace a transparent and super simple notion that once you start specifying solr.node.roles=foo,bar explicitly, then the nodes will ALLOW exactly that set of roles, nothing more, nothing less. So imagine a cluster running 9.0 with each node specifying roles explicitly. And you upgrade to 9.1 which introduces a new role 'sql'. Then, when planning the upgrade to 9.1 the user asks himself whether they need the SQL feature or not. They can then go about the upgrade along three paths A) No need for SQL, do nothing B) Using SQL, but want all existing nodes to run sql: Add the 'sql' role to all nodes during upgrade C) Using SQL, wish 3 dedicated nodes for it: Add the 'sql' role to three dedicated nodes during upgrade I think the extra complexity of "data:on", "data:off", "overseer:allow" etc comes from your assumption that large clusters will run without explicitly specifying roles, or that some of the nodes will not specify roles. Or that newly added roles somehow should become active on a new version even if you have explicitly specified roles on all nodes. I agree that some roles may need additional configuration, but I'm not sure that forcing that configuration into something you have to parse from the role-property itself is the best way to go. Perhpas each role can decide its mode of operation depending on whatever factors and configuration that that role needs. For the overseer, it may in the first phase work as today, that it interprets solr.node.role=overseer as a preference. And in some future version it may read an additional property solr.overseer.priority=3 to give some priority to it, or it could read some solr.overseer.strict=true to refuse to place overseer strictly on nodes with the role. I think it is premature to tackle any future role needs in the first version of the framework. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
