On Mon, Dec 6, 2021 at 6:38 PM Jan Høydahl <[email protected]> wrote:
> > > Also, we should not put so much emhasis on "nodes without roles > defined" as if that should be a common way of starting nodes in a huge > cluster. > > > > Jan, the need to tackle "nodes without roles defined" separately is to > cater to those users who do not use the roles functionality; we need to > provide a logical way for such users to opt into the roles feature. Hence, > it is important to assume implicit defaults of roles for such nodes. > > I disagree. I'm having a hard time understanding what you disagree with. > If I'm an 8.x user with a 5-node cluster, with no roles, then all my nodes > are eligible to take on any role, such as index, search, aggregate, > streaming, sql, embedded zk, oversser etc (although roles are not a concept > in 8.x). > When that user upgrades to 9.0, without considering roles, they start all > five nodes without roles, and every node will be ALLOWed to assume all > roles, so there are no surprises with overseers not starting or anything. > This scenario is going to be supported exactly as you describe in my proposed design. Keep in mind, I propose the default roles for nodes that don't have an explicitly specified roles is "data:on, overseer:allowed". Hence, all nodes will get those functionality by default for a user who never even bothered to fiddle with roles (in 8x or 9x). > > Another user with a 100 node cluster who today have three overseer nodes > that they have shielded from having data by specifying createNodeSet > manually or by other means, can choose to adopt rhe role system, and define > tree dedicated nodes with the overseer role but without the data role, and > they will get exactly what they tried to achieve originally. Should they > later wish to start using role XYZ releast in 9.x, then they wil prepare > for that during the upgrade by starting a few nodes with role=XYZ and > everything is explicit and no magic. > My proposal will work exactly how you describe here. > > Jan > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
