TLDR summary of what I'm advocating. I want node roles to be: - Positive - They denote the existence of a capability - Absolute - Absence/Presence binary identification of a capability; no implications, no assumptions - Focused - Do one thing per role - Accessible - It should be dead simple to determine the members of a role, avoid parsing blobs of json, avoid calculating implications, avoid consulting other resources after listing nodes with the role - Independent - One role should not require other roles to be present - Persistent - roles should not be lost across reboot - Immutable - roles should not change while the node is running - Lively - A node with a capability may not be presently providing that capability.
-Gus On Mon, Nov 1, 2021 at 10:51 AM Gus Heck <[email protected]> wrote: > > > 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) > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
