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 <kgail...@redhat.com> 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 <kgail...@redhat.com> 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 <clone>+<primitive> configuration > in > Pacemaker is used to generate all instances. The service's own > configuration doesn't change, either. Each instance is either > completely identical, and simply running on different nodes, or > handles > a subset of requests determined by information available at run-time. > > > > instance is in one of two roles at any given time, and Pacemaker > > > > two: just two or at least two? > > Exactly two. > > While it is easy to imagine more than two, or even more complex > scenarios (e.g. database server instances can serve as master for > certain tables and replicant for other tables), we don't see any > demand > for managing that via pacemaker, and it would require a complete re- > implementation (and someone with the resources to do that). > > > > manages instances' roles via promote and demote actions. > > > > NOw try to define what promote and demote do ;-) > > A successful call to the resource agent's "start" action must leave > the > resource in a particular one of the roles (the default role, from the > cluster's point of view). A successful "promote" action must move an > instance from the default role to the non-default role, and a > successful "demote" action must move an instance from the non-default > role to the default role. > > So, it's very generic from the cluster's point of view. > > > > Too bad "roleful" isn't a word ;-) > > > > > > As you mentioned, "state" can more broadly refer to started, > > > stopped, > > > etc., but pacemaker does consider "started in slave role" and > > > "started > > > in master role" as extensions of this, so I don't think > > > "stateful" > > > is > > > too far off the mark. > > > > Maybe also state the purpose of having different roles here, and > > define what a role as opposed to a state is. > > That's part of the problem -- the purpose is entirely up to the > specific application. > > Some use it for a master copy of data vs a replicated copy of data, a > read/write instance vs a read-only instance, a coordinating function > vs > an executing function, an active instance vs a hot-spare instance, > etc. > > That's why I like "promoted"/"started" -- it most directly implies > "whatever role you get after promote" vs "whatever role you get after > start". > > It would even be easy to think of the pacemaker daemons themselves as > clones. The crmd would be a stateful clone whose non-default role is > the DC. The attrd would be a stateful clone whose non-default role is > the writer. (It might be "fun" to represent the daemons as resources > one day ...) > > > > Separately, clones (whether stateful or not) may be anonymous or > > > unique > > > (i.e. whether it makes sense to start more than one instance on > > > the > > > same node), which confuses things further. > > > > "anonymous clone" should be defined also, just as unique: Aren't > > all > > configured resources "unique" (i.e. being different from each > > other)? > > > > I'm curious about more than two roles, multiple "masters" and > > multiple "slaves". > > It's a common model to have one database master and a bunch of > replicants, and with most databases having good active/active support > these says, it's becoming more common to have multiple masters, with > or > without separate replicants. It's also common for one coordinator > with > multiple workers. > > > > > Regards, > > Ulrich -- Ken Gaillot <kgail...@redhat.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