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

[Ken Gaillot]

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>