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

[Klaus Wenninger]

On 01/26/2018 04:37 PM, Ken Gaillot wrote:
> On Fri, 2018-01-26 at 09:07 +0100, Jehan-Guillaume de Rorthais wrote:
>> On Thu, 25 Jan 2018 15:21:30 -0500
>> Digimer <lists at alteeve.ca> wrote:
>>
>>> On 2018-01-25 01:28 PM, Ken Gaillot wrote:
>>>> On Thu, 2018-01-25 at 13:06 -0500, Digimer wrote:  
>>>>> On 2018-01-25 11:11 AM, Ken Gaillot wrote:  
>>>>>> On Wed, 2018-01-24 at 20:58 +0100, Jehan-Guillaume de
>>>>>> Rorthais
>>>>>> wrote:  
>>>>>>> On Wed, 24 Jan 2018 13:28:03 -0600
>>>>>>> Ken Gaillot <kgaillot at redhat.com> wrote:
>>>>>>>  
>>>>>>>> I think there's enough sentiment for "promoted"/"started"
>>>>>>>> as
>>>>>>>> the
>>>>>>>> role
>>>>>>>> names, since it most directly reflects how pacemaker uses
>>>>>>>> them.
> Doh! I forgot that there is a key difference between "started" and
> "slave". If you set target-role="Started" for a multistate clone,
> Pacemaker is allowed to bring it up in master or slave mode, whereas
> specifying "Master" or "Slave" specifically only allows that one role.
>
> So, we can't use "started" to replace "slave".

Question is if it has to be like that.
Intention is obviously to prevent that pacemaker doesn't promote
the resource. Could it be a meta-attribute "inhibit-promotion"
as well. Or any other means to inhibit promotion - you are
getting my idea ...

Regards,
Klaus

>
>>>>>>>> For the resources themselves, how about "binary
>>>>>>>> clones"?  
>>>>>>> I'm not sure to understand what your question is about.
>>>>>>>
>>>>>>> If it is related to how the RA are designated between the
>>>>>>> ones
>>>>>>> able
>>>>>>> to
>>>>>>> promote/demote and the other ones, this does not reflect to
>>>>>>> me
>>>>>>> the
>>>>>>> resource can
>>>>>>> be either started or promoted. Moreover, I suppose this
>>>>>>> kind of
>>>>>>> resources are
>>>>>>> not always binary clones. The states might be purely
>>>>>>> logical.
>>>>>>>
>>>>>>> Multistate sounds the best option to me. Simple.
>>>>>>>
>>>>>>> If you need some more options, I would pick: clustered
>>>>>>> resource.
>>>>>>>
>>>>>>> We could argue simple clones might be "clustered resource"
>>>>>>> as
>>>>>>> well,
>>>>>>> but they
>>>>>>> are not supposed to be related to each other as a
>>>>>>> primary/promoted
>>>>>>> resource and
>>>>>>> a secondary/standby resource are.  
>>>>>> Zeroing in on this question, which does everyone prefer:
>>>>>>
>>>>>> * "Binary clones" (in the sense of "one of two roles", but
>>>>>> not very
>>>>>> obvious)
>>>>>>
>>>>>> * "Stateful clones" (potentially confusing with anonymous vs
>>>>>> unique
>>>>>> clones, and all resources have state)
>>>>>>
>>>>>> * "Multistate clones" (less confusing with anonymous vs
>>>>>> unique, and
>>>>>> already in current use in documentation, but still all
>>>>>> resources
>>>>>> have
>>>>>> multiple possible states)
>>>>>>
>>>>>> * "Promotable clones" (consistent with "promote" theme, but
>>>>>> the
>>>>>> word
>>>>>> looks odd, and confusing with whether an individual instance
>>>>>> is
>>>>>> eligible to be promoted)
>>>>>>
>>>>>> * "Promotion clones" (also consistent, but sounds odd and not
>>>>>> particularly obvious)  
>>>>> I don't want to push my preferences here, but I wanted to
>>>>> suggest
>>>>> that
>>>>> something that sounds a bit on now will sound normal over time.
>>>>>
>>>>> I will point out, though, that spell check doesn't complain
>>>>> about
>>>>> 'Binary' and 'Promotion'.
>>>>>
>>>>> If I can throw another suggestion in (without offering
>>>>> preference for
>>>>> it
>>>>> myself), 'dual-state clones'? The reasoning is that, though
>>>>> three
>>>>> words
>>>>> instead of two, spell-check likes it, it sounds OK on day one
>>>>> (from a
>>>>> language perspective) and it reflects that the clone has only
>>>>> one of
>>>>> two
>>>>> states.  
>>>> Or "dual-role".
>>>>
>>>> Binary/dual/multi all have the issue that all resources have
>>>> multiple
>>>> states (stopped, started, etc.). Not a deal-breaker, but a factor
>>>> to
>>>> consider.
>>>>
>>>> What we're trying to represent is: clone resources that have an
>>>> additional possible role that pacemaker manages via the
>>>> promote/demote
>>>> actions.
>>>>
>>>> I go back and forth between options. "Multistate" would be OK,
>>>> especially since it's already used in some places. "Promotable"
>>>> is
>>>> probably most accurate.  
>>> If the thing only has two states; "dual-role" is perfect. If the
>>> thing
>>> can have 3+ states, "multistate" is perfect.
>> In 1.1.x, there is exactly three states: stopped, started, promoted.
>> In 1.1.x, there is exactly two roles: slave and master.
>>
>> Using this terminology, "dual-role" would make sense. However, note
>> that
>> "target-role" could be set to "Stopped", which is actually a state :/
>>
>> If we pick "stopped", "started" and "promoted" as new terminology,
>> there's no
>> more distinction between states and role. We only have three states. 
> "State" is not really a specific technical term in Pacemaker. Depending
> on the context, "state" could also be stopping, starting, failed, etc.
>
> "Role" is used more consistently, as in "target-role" or "role" in
> constraints. It can only be "Started", "Stopped", "Slave", "Master".
>
>> All RA
>> must implement the first two states "stopped" and "started". The
>> cases where RA
>> is promotable should then be called..."promotable" I suppose.
>>
>> However, why exactly should we find a terminology for RA implementing
>> the
>> "promote" action? Should we find some new terminology for RA
>> implementing
>> optional actions like "notify" ("notifiable") or "validate-all"
>> ("validatable")
>> action as well? (ok, these are not roles, but I try to explain my
>> point :))
>>
>> Now the terminology is common using "stopped, started, promoted",
>> should we stop considering "multistate RA" as special cases? We could
>> simply
>> explain RAs are implementing all or a subset of the actions/roles
>> Pacemaker
>> offers and give documentation details related to roles properties,
>> variables
>> and transitions, isn't it?
> We will need some way of specifying it in the syntax, and that will
> become its name ... <clone promotable="true"> or whatever. (We can't
> simply go by what's in the RA metadata for technical reasons not worth
> going into here.)
>
>> Considering the following documentation page, this would means
>> merging chapters
>> 10.2 and 10.3 inside chapter 5.
>>
>>
>>> "Promotable" is certainly accurate, but I have a (very mild)
>>> concern
>>> about how easily it is understood by non-native English speakers.
>>> Perhaps someone who speaks English as a second language could chime
>>> in
>>> on that?
>> "Promotable" sounds accurate to me (native french speaker).
> That's good to know. I think we have at least narrowed it down to
> "multistate" or "promotable" :-)
>
> Unfortunately the role names are now back in play as well. "Promoted"
> and "unpromoted"?
>
> E.g.:
>
> Instead of a single "started" role, a promotable clone resource must be
> in one of two roles when active: "promoted" or "unpromoted".