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

[Ivan Devát]

Hi,


> I think there's enough sentiment for "promoted"/"started" as the role
> names, since it most directly reflects how pacemaker uses them.
> 
Just a question.
The property "role" of a resource operation can have values: "Stopped", 
"Started" and in the case of multi-state resources, "Slave" and "Master".

What does it mean when the value is "Started"? Does it mean either 
"Slave" or "Master" or does it mean just "Slave"?

Ivan

> 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