On Mon, Nov 1, 2021 at 12:53 PM Ishan Chattopadhyaya < [email protected]> wrote:
> I've removed the concept of "!data" from the SIP proposal. A node that > doesn't have -Dnode.roles parameter will be assumed to have > -Dnode.roles=data. If a node is started with a node.roles param, it must > include "data" for all nodes hosting data. > A node not having node.roles defined should be assumed to have all roles. Not only data. I don't see a reason to special case this one or any role. As for OVERSEER role today, it can be documented as a role that marks a > node to be a "preferred" overseer (or eligible/capable etc.), and > "currently providing" can be determined by the OVERSEERSTATUS api call or > the overseer leader election queue. > If node roles are used on all nodes, nodes having OVERSEER role should not be "preferred" overseer, but should be *the only nodes* where Overseer can run. Otherwise things are not clear. Nodes not defining roles for themselves are assumed to have all roles (as per comment above) and can run Overseer. If we want the notion of "preferred overseer", then let's call a role PREFERRED_OVERSEER, and understand that overseer can run anywhere. Same goes with other roles such as ZK etc. If we want a seamless transition from the existing Overseer role (that is a preferred overseer) we should consider an ad hoc transition or a rename. > (+Ilan, +Gus) Making collections role aware > > Seems to me that this is something that can be introduced as a follow up, > and we don't want to complicate the proposed design early on. > It does impact the design from early on: the set of roles need to be expandable by a user by creating a collection with new roles for example (consumed by placement plugins) and be able to start nodes with new (arbitrary) roles. Should such roles follow some naming syntax to differentiate them from built in roles? To be able to fail on typos on roles - that otherwise can be crippling and hard to debug. This implies in any case that the current design can't assume all roles are known at compile time or define them in a Java enum. Ilan >
