[ClusterLabs] Feedback wanted: changing "master/slave" terminology

[Ken Gaillot]

I think there's enough sentiment for "promoted"/"started" as the role
names, since it most directly reflects how pacemaker uses them.

For the resources themselves, how about "binary clones"?

On Thu, 2018-01-18 at 10:48 -0600, Ken Gaillot wrote:
> On Thu, 2018-01-18 at 08:22 +0100, Ulrich Windl wrote:
> > > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 17.01.2018 um
> > > > > 17:04 in Nachricht
> > 
> > <1516205099.5103.3.camel at redhat.com>:
> > > On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:
> > > > > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 16.01.2018
> > > > > > > um
> > > > > > > 23:33 in Nachricht
> > > > 
> > > > <1516142036.5604.3.camel at redhat.com>:
> > > > > As we look to release Pacemaker 2.0 and (separately) update
> > > > > the
> > > > > OCF
> > > > > standard, this is a good time to revisit the terminology and
> > > > > syntax
> > > > > we
> > > > > use for master/slave resources.
> > > > > 
> > > > > I think the term "stateful resource" is a better substitute
> > > > > for
> > > > > "master/slave resource". That would mainly be a documentation
> > > > > change.
> > > > 
> > > > If there will be exactly two states, it'll be bi-state
> > > > resource,
> > > > and
> > > > when abandoning the name, you should also abandon names like
> > > > promote
> > > > and demote, because they stick to master/slave.
> > > > So maybe start with describing what a stateful resource is,
> > > > then
> > > > talk
> > > > about names.
> > > > BTW: All resoiucres we have are "stateful", because they can be
> > > > in
> > > > started and stopped states at least ;-)
> > > 
> > > Good points.
> > > 
> > > A clone is a resource with a configurable number of instances
> > > using
> > > the
> > > same resource configuration. When a clone is stateful, each
> > > active
> > 
> > s/the same/a common/ # if they were the same, there could be no
> > differences
> 
> Nope, it's identical ... a single <clone>+<primitive> configuration
> in
> Pacemaker is used to generate all instances. The service's own
> configuration doesn't change, either. Each instance is either
> completely identical, and simply running on different nodes, or
> handles
> a subset of requests determined by information available at run-time.
> 
> > > instance is in one of two roles at any given time, and Pacemaker
> > 
> > two: just two or at least two?
> 
> Exactly two.
> 
> While it is easy to imagine more than two, or even more complex
> scenarios (e.g. database server instances can serve as master for
> certain tables and replicant for other tables), we don't see any
> demand
> for managing that via pacemaker, and it would require a complete re-
> implementation (and someone with the resources to do that).
>
> > > manages instances' roles via promote and demote actions.
> > 
> > NOw try to define what promote and demote do ;-)
> 
> A successful call to the resource agent's "start" action must leave
> the
> resource in a particular one of the roles (the default role, from the
> cluster's point of view). A successful "promote" action must move an
> instance from the default role to the non-default role, and a
> successful "demote" action must move an instance from the non-default
> role to the default role.
> 
> So, it's very generic from the cluster's point of view.
> 
> > > Too bad "roleful" isn't a word ;-)
> > > 
> > > As you mentioned, "state" can more broadly refer to started,
> > > stopped,
> > > etc., but pacemaker does consider "started in slave role" and
> > > "started
> > > in master role" as extensions of this, so I don't think
> > > "stateful"
> > > is
> > > too far off the mark.
> > 
> > Maybe also state the purpose of having different roles here, and
> > define what a role as opposed to a state is.
> 
> That's part of the problem -- the purpose is entirely up to the
> specific application.
> 
> Some use it for a master copy of data vs a replicated copy of data, a
> read/write instance vs a read-only instance, a coordinating function
> vs
> an executing function, an active instance vs a hot-spare instance,
> etc.
> 
> That's why I like "promoted"/"started" -- it most directly implies
> "whatever role you get after promote" vs "whatever role you get after
> start".
> 
> It would even be easy to think of the pacemaker daemons themselves as
> clones. The crmd would be a stateful clone whose non-default role is
> the DC. The attrd would be a stateful clone whose non-default role is
> the writer. (It might be "fun" to represent the daemons as resources
> one day ...)
> 
> > > Separately, clones (whether stateful or not) may be anonymous or
> > > unique
> > > (i.e. whether it makes sense to start more than one instance on
> > > the
> > > same node), which confuses things further.
> > 
> > "anonymous clone" should be defined also, just as unique: Aren't
> > all
> > configured resources "unique" (i.e. being different from each
> > other)?
> > 
> > I'm curious about more than two roles, multiple "masters" and
> > multiple "slaves".
> 
> It's a common model to have one database master and a bunch of
> replicants, and with most databases having good active/active support
> these says, it's becoming more common to have multiple masters, with
> or
> without separate replicants. It's also common for one coordinator
> with
> multiple workers.
> 
> > 
> > Regards,
> > Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>