Re: [ClusterLabs] Corosync quorum vs. pacemaker quorum confusion

2018-01-17 Thread Ken Gaillot 
On Thu, 2017-12-07 at 07:33 +0300, Andrei Borzenkov wrote:
> 07.12.2017 00:28, Klaus Wenninger пишет:
> > On 12/06/2017 08:03 PM, Ken Gaillot wrote:
> > > On Sun, 2017-12-03 at 14:03 +0300, Andrei Borzenkov wrote:
> > > > I assumed that with corosync 2.x quorum is maintained by
> > > > corosync and
> > > > pacemaker simply gets yes/no. Apparently this is more
> > > > complicated.
> > > 
> > > It shouldn't be, but everything in HA-land is complicated :)
> > > 
> > > > Trivial test two node cluster (two_node is intentionally not
> > > > set to
> > > > simulate "normal" behavior).
> > > > 
> 
> ...
> > > > 
> > > > Dec 03 13:52:07 [1633] ha1   crmd:   notice:
> > > > pcmk_quorum_notification:   Quorum acquired |
> > > > membership=240
> > > > members=1
> > > > Dec 03 13:52:07 [1626] ha1 pacemakerd:   notice:
> > > > pcmk_quorum_notification:   Quorum acquired |
> > > > membership=240
> > > > members=1
> > > > 
> 
> ...
> > > > 
> > > > Confused ... is it intentional behavior or a bug?
> > > 
> > > The no-quorum-policy message above shouldn't prevent the cluster
> > > from
> > > either fencing other nodes or starting resources, once quorum is
> > > obtained from corosync. I'm not sure from the information here
> > > why that
> > > didn't happen.
> > 
> > This is obviously a cluster with 2 nodes. Is it configured as 2-
> > node
> > in corosync as well? If yes the wait-for-all-logic might be
> > confused
> > somehow.
> 
> No, as I mentioned initially I explicitly disable wait_for_all.
> 
> ha1:~ # corosync-cmapctl quorum.
> quorum.expected_votes (u32) = 2
> quorum.provider (str) = corosync_votequorum
> ha1:~ # rpm -q
> 
> > Which version of the sbd-daemon are you running?
> 
> ha1:~ # rpm -q sbd
> sbd-1.3.0-3.3.x86_64
> 
> although I do not see how exactly it matters in this case, as
> pacemaker
> never tells sbd to do anything.
> 
> > As of 1.3.1 (actually a few commits before iirc) in case of 2-node-
> > configuration in corosync sbd wouldn't rely on quorum coming from
> > corosync but rather count the nodes seen by itself. Just in case
> > you
> > see nodes suicide on loss of the disk while still being signaled
> > quorate from corosync either due to the 2-node-config or some fake
> > config as you did...
> > 
> 
> I had suicide due to no-quorum-policy=suicide.
> 
> > Regards,
> > Klaus
> > 
> > > 
> > > I'd first check the Pacemaker logs for "Quorum acquired" and
> > > "Quorum
> > > lost" messages. These indicate when Pacemaker received
> > > notifications
> > > from corosync.
> 
> As shown in original post I did have "Quorum acquired" messages.
> 
> 
> > Assuming those were received properly, the DC should
> > > then recalculate what needs to be done, and the logs at that
> > > point
> > > should not have any of the messages about not having quorum.
> 
> So I redid this using default no-quorum-policy=stop and one more
> non-stonith resource.
> 
> ...and just before I hit "send" cluster recovered. So it appears that
> "Quorum acquired" event does not trigger (immediate) re-evaluation of
> policy until some timeout.
> 
> Dec 07 07:05:16 ha1 pacemakerd[1888]:   notice: Quorum acquired
> 
> Nothing happens until the next message
> 
> Dec 07 07:12:58 ha1 crmd[1894]:   notice: State transition S_IDLE ->
> S_POLICY_ENGINE
> Dec 07 07:12:58 ha1 pengine[1893]:   notice: Watchdog will be used
> via
> SBD if fencing is required
> Dec 07 07:12:58 ha1 pengine[1893]:  warning: Scheduling Node ha2 for
> STONITH
> Dec 07 07:12:58 ha1 pengine[1893]:   notice:  * Fence (reboot) ha2
> 'node
> is unclean'
> Dec 07 07:12:58 ha1 pengine[1893]:   notice:  * Start  stonith-
> sbd
>   (   ha1 )
> Dec 07 07:12:58 ha1 pengine[1893]:   notice:  *
> Start  rsc_dummy_1
>   (   ha1 )
> 
> This is apparently 15 minutes cluster-recheck-interval timer (give or
> take):
> 
> Dec 07 06:57:35 [1888] ha1 pacemakerd: info:
> crm_log_init:  Changed
> active directory to /var/lib/pacemaker/cores
> ...
> Dec 07 07:12:58 [1894] ha1   crmd:   notice: do_state_transition:
> State transition S_IDLE -> S_POLICY_ENGINE | input=I_PE_CALC
> cause=C_TIMER_POPPED origin=crm_timer_popped
> 
> OK, at least we know why it happens. Whether this is intentional
> behavior is another question :)

1.1.17 had an attempted fix (commit 0b68905) for the opposite
situation, where the cluster was not reacting to quorum loss
immediately unless there were resources running.

Looking at that again, I see it was an incomplete fix.

The sequence for either quorum acquisition or loss is:
- cluster regains quorum
- corosync notifies pacemaker's crmd
- crmd updates the quorum attribute of the CIB's cib tag (it will
generally also update the node_state tag of the node that caused the
quorum change)
- cib notifies crmd when CIB write completes

At this point (XML_TAG_CIB handling in te_update_diff()), I believe we
should check the cib tag, and abort the transition if quorum changed,
but we currently don't do anything. I'm guessing it's gone unnoticed

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

2018-01-17 Thread Ken Gaillot 
On Wed, 2018-01-17 at 19:59 +0100, Kristoffer Grönlund wrote:
> Ken Gaillot  writes:
> 
> > 
> > I can see the point, but I do like having  separate.
> > 
> > A clone with a single instance is not identical to a primitive.
> > Think
> > of building a cluster, starting with one node, and configuring a
> > clone
> > -- it has only one instance, but you wouldn't expect it to show up
> > as a
> > primitive in status displays.
> > 
> > Also, there are a large number of clone meta-attributes that aren't
> > applicable to simple primitives. By contrast, master adds only two
> > attributes to clones.
> 
> I'm not convinced by either argument. :)
> 
> The distinction between single-instance clone and primitive is
> certainly
> not clear to me, and there is no problem for status displays to
> display
> a resource with a single replica differently from a resource that
> isn't
> configured to be replicated.

There probably isn't much user-visible difference -- the only one I can
think of is that clones have a default stickiness of 1 instead of 0.
Implementation-wise though, there's a huge difference, and I'm not sure
they would behave the same in all cases. In particular I might expect
different behavior when used in constraints with other clones.

But I was assuming you weren't allowing any syntactical difference
between the two. If the syntax can distinguish them, e.g. , that wouldn't conflict with the
current implementation.

> The number of meta-attributes related to clones seems irrelevant as
> well, pacemaker can reject a configuration that sets clone-related
> attributes for non-clone resources just as well as if they were on a
> different node in the XML.

I was thinking more in terms of user understandability. To me,
isolating the clone properties is easier to follow (and learn), rather
than mixing them in with primitive properties.

> From the XML perspective, I think the current approach is logically
> > structured, a  wrapped around a  or , each
> > with its own meta-attributes.
> 
> Well, I guess it's a matter of opinion. For me, I don't think it is
> very
> logical at all. For example, the result of having the hierarchy of
> nodes
> is that it is possible to configure target-role for both the wrapped
>  and the container:
> 
> 
>  
>   
>  
>  
>   
>    
>   
>  
> 
> 
> Then edit the configuration removing the clone, save, and the
> resource
> starts when it should have been stopped.

There's nothing preventing that, but as a best practice, I would put
only clone properties in the outermost meta-attributes block.

It might be even better to do away with that block and put those
properties in the tag, e.g. . That
would ensure primitive meta-attributes could be set only in the
appropriate spot. It would prevent clone properties from being used in
rules, but they probably shouldn't be anyway.

> It's even worse in the case of a clone wrapping a group holding
> clones of resources, in which case there can be four levels of
> attribute
> inheritance -- and this applies to both meta attributes and instance
> attributes.

Clones can't be members of a group, we did avoid that degree of
insanity. :)

> Add to that the fact that there can be multiple sets of instance
> attributes and meta attributes for each of these with rule
> expressions
> and implicit precedence determining which set actually applies...

That can be confusing, but I think it does offer an important
flexibility for use cases that can't be addressed otherwise, and it's
optional, so anyone who doesn't need it doesn't have to see it.

Combining your suggestion with mine above, I could see putting the
clone tag within the primitive or group, like:

  

 ... 
 ... 
  

but neither that nor your suggestion would allow us to (easily) prevent
a clone from being inside a group or bundle. The relationship that
needs to be expressed is:

  primitives can be grouped, cloned, or bundled
  groups can be cloned but not grouped or bundled
  clones and bundles cannot be grouped, cloned, or bundled

A lesser concern would be that we would have to continue to support the
 old syntax in order not to break rolling upgrades, since it probably
wouldn't be possible to automatically transform it to the new syntax.

Then there's the goal of releasing 2.0.0-rc1 this month, which is
doable with  ->  but not with a major
new project like this :)
-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

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

2018-01-17 Thread Kristoffer Grönlund 
Ken Gaillot  writes:

>
> I can see the point, but I do like having  separate.
>
> A clone with a single instance is not identical to a primitive. Think
> of building a cluster, starting with one node, and configuring a clone
> -- it has only one instance, but you wouldn't expect it to show up as a
> primitive in status displays.
>
> Also, there are a large number of clone meta-attributes that aren't
> applicable to simple primitives. By contrast, master adds only two
> attributes to clones.

I'm not convinced by either argument. :)

The distinction between single-instance clone and primitive is certainly
not clear to me, and there is no problem for status displays to display
a resource with a single replica differently from a resource that isn't
configured to be replicated.

The number of meta-attributes related to clones seems irrelevant as
well, pacemaker can reject a configuration that sets clone-related
attributes for non-clone resources just as well as if they were on a
different node in the XML.

>
> From the XML perspective, I think the current approach is logically
> structured, a  wrapped around a  or , each
> with its own meta-attributes.

Well, I guess it's a matter of opinion. For me, I don't think it is very
logical at all. For example, the result of having the hierarchy of nodes
is that it is possible to configure target-role for both the wrapped
 and the container:


 
  
 
 
  
   
  
 


Then edit the configuration removing the clone, save, and the resource
starts when it should have been stopped.

It's even worse in the case of a clone wrapping a group holding
clones of resources, in which case there can be four levels of attribute
inheritance -- and this applies to both meta attributes and instance
attributes.

Add to that the fact that there can be multiple sets of instance
attributes and meta attributes for each of these with rule expressions
and implicit precedence determining which set actually applies...

-- 
// Kristoffer Grönlund
// kgronl...@suse.com

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

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

2018-01-17 Thread Ken Gaillot 
On Wed, 2018-01-17 at 11:19 +0100, Kristoffer Grönlund wrote:
> Ken Gaillot  writes:
> 
> > 
> > For Pacemaker 2, I'd like to replace the  resource type
> > with
> > . (The old syntax would be transparently
> > upgraded to the new one.) The role names themselves are not likely
> > to
> > be changed in that time frame, as they are used in more external
> > pieces
> > such as notification variables. But it would be the first step.
> > 
> > I hope that this will be an uncontroversial change in the
> > ClusterLabs
> > community, but because such changes have been heated elsewhere,
> > here is
> > why this change is desirable:
> > 
> 
> I agree 100% about this change. In Hawk, we've already tried to hide
> the
> Master/Slave terms as much as possible and replace them with
> primary/secondary and "Multi-state", but I'm happy to converge on
> common
> terms.
> 
> I'm partial to "Promoted" and "Started" since it makes it clearer
> that
> the secondary state is a base state and that it's the promoted state
> which is different / special.
> 
> However, can I throw a wrench in the machinery? When replacing the
>  resource type with , why not go a
> step
> further and merge both  and  with the basic
> ?
> 
>  => clone
>  => master
> 
> or for groups,
> 
> 
> 
> I have never understood the usefulness of separate meta-attribute
> sets
> for the  and  nodes.

I can see the point, but I do like having  separate.

A clone with a single instance is not identical to a primitive. Think
of building a cluster, starting with one node, and configuring a clone
-- it has only one instance, but you wouldn't expect it to show up as a
primitive in status displays.

Also, there are a large number of clone meta-attributes that aren't
applicable to simple primitives. By contrast, master adds only two
attributes to clones.

From the XML perspective, I think the current approach is logically
structured, a  wrapped around a  or , each
with its own meta-attributes.
-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Proper procedure for pacemaker RPM upgrades in active cluster

2018-01-17 Thread Ken Gaillot 
On Wed, 2018-01-17 at 11:20 -0500, Doug Cahill wrote:
> Thank you Ken for the feedback on this.  That doc was exactly what I
> was looking for but missed it in my searches.  I did some testing
> with
> using "crm configure property maintenance-mode=true" and my upgrade
> from 1.1.17 to 1.1.18 worked in my test environment.
> 
> Good info on the 1.1.18 regression fix, thanks.  Will the fixes for
> the regression eventually be put into a specific release under the
> 1.1.x version or will I need to wait for a 2.0 release?  I'm hesitant
> to release a build of the 1.1 upstream into my production.

There will be another 1.1 release eventually. However, there is no more
active development in the 1.1 branch. The only things that will go in
there now are backports of selected bugfixes from the active branches,
so it's at least as safe to use as an official 1.1 release.

> On Mon, Jan 15, 2018 at 6:10 PM, Ken Gaillot 
> wrote:
> > On Mon, 2018-01-15 at 15:42 -0500, Doug Cahill wrote:
> > > Hello,
> > > 
> > > I'm looking for some guidance on pacemaker RPM upgrades in a
> > > running
> > > cluster environment.  I'm looking to automate the process of
> > > upgrading
> > > the RPMs when we decide to plan an upgrade cycle for our
> > > clusters.
> > > 
> > > What I found is that during the RPM upgrade process the
> > > pacemaker.x86_64 RPM will shutdown the pacemaker service.  My
> > > question
> > > regarding this is...is it possible to upgrade the RPM component
> > > but
> > > delay the restart part of the pacemaker service to a later
> > > time?  If
> > > delaying the restart isn't possible, what is the preferred
> > > process
> > > for
> > > people with existing clusters that require package
> > > upgrades?  Should
> > > I
> > > upgrade the passive side first and then fail over to it and then
> > > upgrade the other node which is now passive?  Does pacemaker
> > > support
> > > running two nodes at different version levels during the upgrade
> > > process?  Would enabling maintenance mode be appropriate/ideal
> > > for
> > > this?
> > 
> > Yes to most of those :)
> > 
> > Detailed information about upgrade techniques:
> > 
> > http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-singl
> > e/Pa
> > cemaker_Explained/index.html#_upgrading
> > 
> > Basically, the failover scenario you mentioned is the "rolling
> > upgrade"
> > technique, and the maintenance mode scenario you mentioned is the
> > "detach and reattach" technique.
> > 
> > Each has advantages and disadvantages. A rolling upgrade lets you
> > keep
> > on node on a known working setup as long as possible, while a
> > detach-
> > and-reattach gives you zero downtime (as long the upgrade has no
> > problems ...).
> > 
> > > 
> > > I last experienced this situation when I upgraded from 1.1.15 to
> > > 1.1.17.  Now that pacemaker 1.1.18 is available I'm looking to
> > > plan
> > > this process a little better and would like to know what others
> > > use
> > > as
> > > a procedure.
> > > 
> > > Basic software config:
> > > CentOS 6.x (2.6.32-696.13.2.el6.x86_64)
> > > pacemaker.x86_64   1.1.17-1.el6
> > > corosync.x86_642.4.2-1.el6
> > > crmsh.noarch   3.0.1_283-0
> > > Two-node Cluster resources are configured for active/passive
> > > operation.
> > > 
> > > Thanks,
> > > -Doug
> > 
> > On a side note, if you're building 1.1.18 packages yourself, it's a
> > good idea to use the latest upstream 1.1 branch, because it fixes
> > an
> > important regression in 1.1.18.
> > --
> > Ken Gaillot 

-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Proper procedure for pacemaker RPM upgrades in active cluster

2018-01-17 Thread Doug Cahill 
Thank you Ken for the feedback on this.  That doc was exactly what I
was looking for but missed it in my searches.  I did some testing with
using "crm configure property maintenance-mode=true" and my upgrade
from 1.1.17 to 1.1.18 worked in my test environment.

Good info on the 1.1.18 regression fix, thanks.  Will the fixes for
the regression eventually be put into a specific release under the
1.1.x version or will I need to wait for a 2.0 release?  I'm hesitant
to release a build of the 1.1 upstream into my production.

On Mon, Jan 15, 2018 at 6:10 PM, Ken Gaillot  wrote:
> On Mon, 2018-01-15 at 15:42 -0500, Doug Cahill wrote:
>> Hello,
>>
>> I'm looking for some guidance on pacemaker RPM upgrades in a running
>> cluster environment.  I'm looking to automate the process of
>> upgrading
>> the RPMs when we decide to plan an upgrade cycle for our clusters.
>>
>> What I found is that during the RPM upgrade process the
>> pacemaker.x86_64 RPM will shutdown the pacemaker service.  My
>> question
>> regarding this is...is it possible to upgrade the RPM component but
>> delay the restart part of the pacemaker service to a later time?  If
>> delaying the restart isn't possible, what is the preferred process
>> for
>> people with existing clusters that require package upgrades?  Should
>> I
>> upgrade the passive side first and then fail over to it and then
>> upgrade the other node which is now passive?  Does pacemaker support
>> running two nodes at different version levels during the upgrade
>> process?  Would enabling maintenance mode be appropriate/ideal for
>> this?
>
> Yes to most of those :)
>
> Detailed information about upgrade techniques:
>
> http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pa
> cemaker_Explained/index.html#_upgrading
>
> Basically, the failover scenario you mentioned is the "rolling upgrade"
> technique, and the maintenance mode scenario you mentioned is the
> "detach and reattach" technique.
>
> Each has advantages and disadvantages. A rolling upgrade lets you keep
> on node on a known working setup as long as possible, while a detach-
> and-reattach gives you zero downtime (as long the upgrade has no
> problems ...).
>
>>
>> I last experienced this situation when I upgraded from 1.1.15 to
>> 1.1.17.  Now that pacemaker 1.1.18 is available I'm looking to plan
>> this process a little better and would like to know what others use
>> as
>> a procedure.
>>
>> Basic software config:
>> CentOS 6.x (2.6.32-696.13.2.el6.x86_64)
>> pacemaker.x86_64   1.1.17-1.el6
>> corosync.x86_642.4.2-1.el6
>> crmsh.noarch   3.0.1_283-0
>> Two-node Cluster resources are configured for active/passive
>> operation.
>>
>> Thanks,
>> -Doug
>
> On a side note, if you're building 1.1.18 packages yourself, it's a
> good idea to use the latest upstream 1.1 branch, because it fixes an
> important regression in 1.1.18.
> --
> Ken Gaillot 
>
> ___
> Users mailing list: Users@clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

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

2018-01-17 Thread Ken Gaillot 
On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:
> > > > Ken Gaillot  schrieb am 16.01.2018 um
> > > > 23:33 in Nachricht
> 
> <1516142036.5604.3.ca...@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
instance is in one of two roles at any given time, and Pacemaker
manages instances' roles via promote and demote actions.

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.

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.
-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

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

2018-01-17 Thread Kristoffer Grönlund 
Ken Gaillot  writes:

>
> For Pacemaker 2, I'd like to replace the  resource type with
> . (The old syntax would be transparently
> upgraded to the new one.) The role names themselves are not likely to
> be changed in that time frame, as they are used in more external pieces
> such as notification variables. But it would be the first step.
>
> I hope that this will be an uncontroversial change in the ClusterLabs
> community, but because such changes have been heated elsewhere, here is
> why this change is desirable:
>

I agree 100% about this change. In Hawk, we've already tried to hide the
Master/Slave terms as much as possible and replace them with
primary/secondary and "Multi-state", but I'm happy to converge on common
terms.

I'm partial to "Promoted" and "Started" since it makes it clearer that
the secondary state is a base state and that it's the promoted state
which is different / special.

However, can I throw a wrench in the machinery? When replacing the
 resource type with , why not go a step
further and merge both  and  with the basic ?

 => clone
 => master

or for groups,



I have never understood the usefulness of separate meta-attribute sets
for the  and  nodes.

-- 
// Kristoffer Grönlund
// kgronl...@suse.com

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

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

2018-01-17 Thread Adam Spiers 

Ulrich Windl  wrote:

Ken Gaillot  schrieb am 16.01.2018 um 23:33 in Nachricht

<1516142036.5604.3.ca...@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.


That's not true; the concepts of promotion/demotion apply in entirely
different contexts to master/slave (e.g. careers), and in fact there
is a strong argument that outside a computing context they never
applied to master/slave in the first place.


So maybe start with describing what a stateful resource is, then talk about 
names.


Good idea.


BTW: All resoiucres we have are "stateful", because they can be in started and 
stopped states at least ;-)


Yes, good point :-)

[snipped]


* The long history of the terms master/slave being used in an
emotionally neutral context in engineering fields is not a reason to
continue using them. The concept of slavery *should not* be emotionally
neutral; it should evoke strong feelings.


To change anything because of the _word_ "slave" is absolute nonsense
IMHO. Next would be "servant", I guess, and then "server".


That's a gigantic leap from "slave" to "servant", and another big one
to "server".  It would be great if we didn't have to dive into the
history of human oppression in this discussion; the differences should
be obvious to everyone.

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org