On Mon, Nov 1, 2021 at 9:47 AM Ilan Ginzburg <[email protected]> wrote:
> 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. > See my comment above, but maybe preference is something handled as a feature of the role rather than via role designation? > 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. > We need to be careful not to speak of collection roles. That would be a separate thing from "Node Roles" I think. I don't think we should allow arbitrary role names for end-users to hinge client functionality on. Then when we want to add a new role with a name we break some unknown set of users that used that name for something else. If we want fre-rorm selectors we should have "tags" or "selectors" as a separate feature. I agree however we need to code to assume an unbounded set of future roles (features that we add in the future) > Ilan > > > >> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
