[ClusterLabs] Feedback wanted: changing "master/slave" terminology
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. A bigger question is what to call the two roles. "Master" and "Slave" would be continue to be accepted for backward compatibility for a long time. Some suggestions: * master/worker, master/replicant, primary/backup: I'd like to avoid terms like these. OCF and Pacemaker are application-agnostic, whereas these terms imply particular functionality and are often associated with particular software. * primary/secondary: Widely used, but sometimes associated with particular software. * promoted with either unpromoted, demoted, default, or started: All OCF and Pacemaker actually care about is whether the resource agent has been called with the promote action. "Promoted" is good, but the other role is less obvious. * anything else anyone can think of 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: * It is *not about anyone being offended*. It is about making everyone feel *welcome* by avoiding emotionally charged language. * It is *not about victimhood, guilt, blame, or punishment* of any particular group. It is about striving for excellence, both in accuracy of terminology and in community development. * 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. * Slavery is an inaccurate metaphor. The initial intent apparently was "a master tells a slave what to do". This is a naive view of slavery. Slavery is not an apt comparison to a system harmoniously designed to execute tasks efficiently for a common goal. In software, it would be a more apt comparison to botnets: something illegally taken from its rightful ownership and being forced to perform tasks for its captor. * In Pacemaker's particular case, we have long said that master/slave resources are simply for resources that can operate in two modes, and we don't care what those two modes do or what they are called natively by the application. While some applications use master/slave, many have moved away from those terms, and others have always used other terms, so it makes sense for us to adopt something more generic. -- 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
On 2018-01-16 05:33 PM, Ken Gaillot wrote: > 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. > > A bigger question is what to call the two roles. "Master" and "Slave" > would be continue to be accepted for backward compatibility for a long > time. Some suggestions: > > * master/worker, master/replicant, primary/backup: I'd like to avoid > terms like these. OCF and Pacemaker are application-agnostic, whereas > these terms imply particular functionality and are often associated > with particular software. > > * primary/secondary: Widely used, but sometimes associated with > particular software. This has been used by DRBD for some time and it works well. People are used to it, and it adds consistency with other open source HA projects / Clusterlabs people. This is my top choice. > * promoted with either unpromoted, demoted, default, or started: All > OCF and Pacemaker actually care about is whether the resource agent has > been called with the promote action. "Promoted" is good, but the other > role is less obvious. > > * anything else anyone can think of For the sake of options; Active / Standby? > 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: > > * It is *not about anyone being offended*. It is about making everyone > feel *welcome* by avoiding emotionally charged language. The terms are antiquated and loaded. I _strongly_ support changing them. > * It is *not about victimhood, guilt, blame, or punishment* of any > particular group. It is about striving for excellence, both in accuracy > of terminology and in community development. Recognizing that, though certain words may not have weight for us, but do for others, is a sign of maturity in the community. > * 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. > > * Slavery is an inaccurate metaphor. The initial intent apparently was > "a master tells a slave what to do". This is a naive view of slavery. > Slavery is not an apt comparison to a system harmoniously designed to > execute tasks efficiently for a common goal. In software, it would be a > more apt comparison to botnets: something illegally taken from its > rightful ownership and being forced to perform tasks for its captor. > > * In Pacemaker's particular case, we have long said that master/slave > resources are simply for resources that can operate in two modes, and > we don't care what those two modes do or what they are called natively > by the application. While some applications use master/slave, many have > moved away from those terms, and others have always used other terms, > so it makes sense for us to adopt something more generic. Pacemaker, and HA in general, is/are projects with international reach used in all parts of the world. It is minor, technically, to change terminology with the transition to a new major version. If people have concern about compatibility, there can be support for the old terms with a deprecation warning, similar to other things being deprecated as was discussed at the last summit. Thank you for taking the lead on this. I can speak for Alteeve in saying we back this 100%. -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
Digimer wrote: On 2018-01-16 05:33 PM, Ken Gaillot wrote: 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. A bigger question is what to call the two roles. "Master" and "Slave" would be continue to be accepted for backward compatibility for a long time. Some suggestions: * master/worker, master/replicant, primary/backup: I'd like to avoid terms like these. OCF and Pacemaker are application-agnostic, whereas these terms imply particular functionality and are often associated with particular software. * primary/secondary: Widely used, but sometimes associated with particular software. This has been used by DRBD for some time and it works well. People are used to it, and it adds consistency with other open source HA projects / Clusterlabs people. This is my top choice. Mine too based on a first reaction. * promoted with either unpromoted, demoted, default, or started: All OCF and Pacemaker actually care about is whether the resource agent has been called with the promote action. "Promoted" is good, but the other role is less obvious. * anything else anyone can think of For the sake of options; Active / Standby? "Standby" tends to imply that it's doing nothing, which isn't really the case. But yeah, good to consider as many options as possible before making a decision :-) 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: * It is *not about anyone being offended*. It is about making everyone feel *welcome* by avoiding emotionally charged language. The terms are antiquated and loaded. I _strongly_ support changing them. * It is *not about victimhood, guilt, blame, or punishment* of any particular group. It is about striving for excellence, both in accuracy of terminology and in community development. Recognizing that, though certain words may not have weight for us, but do for others, is a sign of maturity in the community. Amen. ___ 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
FWIW, bellow my opinion about this On Tue, 16 Jan 2018 16:33:56 -0600 Ken Gaillot wrote: [...] > I think the term "stateful resource" is a better substitute for > "master/slave resource". That would mainly be a documentation change. +1 > A bigger question is what to call the two roles. "Master" and "Slave" > would be continue to be accepted for backward compatibility for a long > time. Some suggestions: > * master/worker, master/replicant, primary/backup: I'd like to avoid > terms like these. OCF and Pacemaker are application-agnostic, whereas > these terms imply particular functionality and are often associated > with particular software. -1 for them as well. > * primary/secondary: Widely used, but sometimes associated with > particular software. +1 > * promoted with either unpromoted, demoted, default, or started: All > OCF and Pacemaker actually care about is whether the resource agent has > been called with the promote action. "Promoted" is good, but the other > role is less obvious. Started and Promoted might do the job, and sounds agnostic in regard with application terminology. I don't have strong argument to pick one between primary/secondary and started/promoted. The first might be more convenient to understand to most people without further explanation about Pacemaker internal mechanism though. [...] I suppose, this should be reflected on pcs/crmsh as well at some point. ++ ___ 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
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] Feedback wanted: changing "master/slave" terminology
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] Feedback wanted: changing "master/slave" terminology
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
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
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 schrieb am 17.01.2018 um > > > > > 17:04 in Nachricht > > > > <1516205099.5103.3.ca...@redhat.com>: > > > 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 > > > > s/the same/a common/ # if they were the same, there could be no > > differences > > Nope, it's identical ... a single + 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 bun
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
On Wed, 24 Jan 2018 13:28:03 -0600 Ken Gaillot wrote: > 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"? 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. My 2¢ > 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 schrieb am 17.01.2018 um > > > > > > 17:04 in Nachricht > > > > > > <1516205099.5103.3.ca...@redhat.com>: > > > > 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 > > > > > > s/the same/a common/ # if they were the same, there could be no > > > differences > > > > Nope, it's identical ... a single + 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. > > > > T
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
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 schrieb am 17.01.2018 um 17:04 in Nachricht <1516205099.5103.3.ca...@redhat.com>: 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 s/the same/a common/ # if they were the same, there could be no differences Nope, it's identical ... a single + 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 ___ Users mailing list:
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
On Thu, 25 Jan 2018 10:03:34 +0100 Ivan Devát wrote: > > 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"? This has been discussed on this list, not sure when... "Started" has the exact same meaning than "Slave" (and the other way around). If I remember correctly, a patch fixed some output about this some versions ago. ___ 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
On Thu, 25 Jan 2018 11:28:16 +0100 Jehan-Guillaume de Rorthais wrote: > On Thu, 25 Jan 2018 10:03:34 +0100 > Ivan Devát wrote: > > > > 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"? > > This has been discussed on this list, not sure when... > > "Started" has the exact same meaning than "Slave" (and the other way around). > If I remember correctly, a patch fixed some output about this some versions > ago. See commits: ab44df4b6b2f2af6cf94a50833b4e3acc3718c72 4acd6327a949a3836fa7bb1851f758d4474cd05d ___ 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
On Thu, 2018-01-25 at 11:31 +0100, Jehan-Guillaume de Rorthais wrote: > On Thu, 25 Jan 2018 11:28:16 +0100 > Jehan-Guillaume de Rorthais wrote: > > > On Thu, 25 Jan 2018 10:03:34 +0100 > > Ivan Devát wrote: > > > > > > 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"? > > > > This has been discussed on this list, not sure when... > > > > "Started" has the exact same meaning than "Slave" (and the other > > way around). Correct, "Started" is just the term used with non-master/slave resources. "Slave" is almost but not 100% identical to "Started" internally, but those details can be completely hidden from the user, so we can use "Started" as a replacement for "Slave" in the configuration and documentation. > > If I remember correctly, a patch fixed some output about this some > > versions > > ago. > > See commits: > > ab44df4b6b2f2af6cf94a50833b4e3acc3718c72 > 4acd6327a949a3836fa7bb1851f758d4474cd05d -- 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
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 wrote: > > > 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"? > > 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) -- 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
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 wrote: >> >>> 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"? >> >> 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. -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
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 wrote: > > > > > > > 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"? > > > > > > 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. -- 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
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 wrote: > 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"? 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. "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? -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
On Thu, 25 Jan 2018 15:21:30 -0500
Digimer 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 wrote:
>
> > 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"?
>
> 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. 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?
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?
"Promotab
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
On 01/25/2018 09:21 PM, Digimer 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 wrote: > >> 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"? > 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. > > "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? I would probably fall under this category and "Promotable" makes makes sense to me. But unfortunately I'm probably already tainted by long-time-exposure to pacemaker ;-) Regards, Klaus > > ___ 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
25.01.2018 21:28, Ken Gaillot wrote: [...] 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". Btw, is the word 'tri-state' or 'tristate' usable in contemporary English? Some online translators accept it, but google isn't. 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. ___ 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
On Fri, 26 Jan 2018 12:41:51 +0300 Vladislav Bogdanov wrote: > 25.01.2018 21:28, Ken Gaillot wrote: > > [...] > > >> 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". > > Btw, is the word 'tri-state' or 'tristate' usable in contemporary English? > Some online translators accept it, but google isn't. Exact, I was thinking about this one as well but forgot to suggest it. What about "binary-state" and "ternary-state" ? Or "binary-role" and "ternary-role" ? ___ 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
On Fri, 2018-01-26 at 09:07 +0100, Jehan-Guillaume de Rorthais wrote: > On Thu, 25 Jan 2018 15:21:30 -0500 > Digimer 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 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". > > > > > > > > > > > > > > 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 t
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
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 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 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,
Re: [ClusterLabs] Feedback wanted: changing "master/slave" terminology
On 2018-01-26 03:52 AM, Klaus Wenninger wrote: >> "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? > I would probably fall under this category and "Promotable" makes > makes sense to me. > But unfortunately I'm probably already tainted by > long-time-exposure to pacemaker ;-) > > Regards, > Klaus That's two non-native English speakers who have said that "promotable" is OK. Perhaps it will work just fine then. :) -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
On 2018-01-26 05:02 AM, Jehan-Guillaume de Rorthais wrote: > On Fri, 26 Jan 2018 12:41:51 +0300 > Vladislav Bogdanov wrote: > >> 25.01.2018 21:28, Ken Gaillot wrote: >> >> [...] >> 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". >> >> Btw, is the word 'tri-state' or 'tristate' usable in contemporary English? >> Some online translators accept it, but google isn't. > > Exact, I was thinking about this one as well but forgot to suggest it. > > What about "binary-state" and "ternary-state" ? > > Or "binary-role" and "ternary-role" ? I think, personally, "dual-state" and/or "tri-state" are easier to understand. -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ 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
On Fri, 26 Jan 2018 17:10:14 +0100 Klaus Wenninger wrote: > 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 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 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 ... Or maybe introduce something more intuitive like "active"? target-role would have: stopped, started, promoted or active(started or promoted). ___ 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
On Fri, 26 Jan 2018 09:37:39 -0600
Ken Gaillot wrote:
...
> > 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 ... or whatever. (We can't
> simply go by what's in the RA metadata for technical reasons not worth
> going into here.)
That makes me wonder how pcs and crm syntax should evolve as well from the
user point of view... :/
> > > "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".
What about my previous suggestion to use "active" to match either "Started" or
"Promoted" state?
___
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
On Fri, 2018-01-26 at 23:30 +0100, Jehan-Guillaume de Rorthais wrote:
> On Fri, 26 Jan 2018 09:37:39 -0600
> Ken Gaillot wrote:
> ...
>
> > > 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 ... or whatever. (We
> > can't
> > simply go by what's in the RA metadata for technical reasons not
> > worth
> > going into here.)
>
> That makes me wonder how pcs and crm syntax should evolve as well
> from the
> user point of view... :/
I'm sure they'll adapt similarly, allowing the old names for backward
compatibility.
> > > > "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".
>
> What about my previous suggestion to use "active" to match either
> "Started" or
> "Promoted" state?
I like it. My only concern is how difficult it might be to work with
old configurations. (Pacemaker 2.0 will guarantee rolling upgrades from
1.1.11 and later, and full-stop upgrades from 1.0.0 and later.)
In other words, if someone has an older configuration with target-
role="Started", we'd want to automatically remap that (via XSLT) to
"active", but if it's a newer configuration, we wouldn't want to touch
that. It's feasible but confusing, even more so when considering
pcs/crm/etc., which would need to figure out the user's intent (the
user likely doesn't know which CIB schema version they're using) and
map it one way or the other depending on the CIB schema, or upgrade the
CIB schema first.
Using one-to-one new terms for master and slave would be a lot easier
to implement.
I think we're at least converging on "promotable" to describe the
resources and "promoted" for the master role. For 2.0.0, the only
change will likely be the tag and some documentation, so we
can proceed on that basis.
--
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
