On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote: > On Mon, Apr 4, 2011 at 2:43 PM, Holger Teutsch <holger.teut...@web.de> wrote: > > On Mon, 2011-04-04 at 11:05 +0200, Andrew Beekhof wrote: > >> On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch <holger.teut...@web.de> > >> wrote: > >> > Hi Dejan, > >> > > >> > On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote: > >> >> Hi, > >> >> > >> >> On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote: > >> >> > Hi, > >> >> > I would like to submit 2 patches of an initial implementation for > >> >> > discussion. > >> > .. > >> >> > To recall: > >> >> > > >> >> > crm_resource --move resource > >> >> > creates a "standby" rule that moves the resource off the currently > >> >> > active node > >> >> > > >> >> > while > >> >> > > >> >> > crm_resource --move resource --node newnode > >> >> > creates a "prefer" rule that moves the resource to the new node. > >> >> > > >> >> > When dealing with clones and masters the behavior was random as the > >> >> > code > >> >> > only considers the node where the first instance of the clone was > >> >> > started. > >> >> > > >> >> > The new code behaves consistently for the master role of an m/s > >> >> > resource. The options "--master" and "rsc:master" are somewhat > >> >> > redundant > >> >> > as a "slave" move is not supported. Currently it's more an > >> >> > acknowledgement of the user. > >> >> > > >> >> > On the other hand it is desirable (and was requested several times on > >> >> > the ML) to stop a single resource instance of a clone or master on a > >> >> > specific node. > >> >> > > >> >> > Should that be implemented by something like > >> >> > > >> >> > "crm_resource --move-off --resource myresource --node devel2" ? > >> >> > > >> >> > or should > >> >> > > >> >> > crm_resource refuse to work on clones > >> >> > > >> >> > and/or should moving the master role be the default for m/s resources > >> >> > and the "--master" option discarded ? > >> >> > >> >> I think that we also need to consider the case when clone-max is > >> >> less than the number of nodes. If I understood correctly what you > >> >> were saying. So, all of move slave and move master and move clone > >> >> should be possible. > >> >> > >> > > >> > I think the following use cases cover what can be done with such kind of > >> > interface: > >> > > >> > crm_resource --moveoff --resource myresource --node mynode > >> > -> all resource variants: check whether active on mynode, then create > >> > standby constraint > >> > > >> > crm_resource --move --resource myresource > >> > -> primitive/group: convert to --moveoff --node `current_node` > >> > -> clone/master: refused > >> > > >> > crm_resource --move --resource myresource --node mynode > >> > -> primitive/group: create prefer constraint > >> > -> clone/master: refused > >> > >> Not sure this needs to be refused. > > > > I see the problem that the node where the resource instance should be > > moved off had to be specified as well to get predictable behavior. > > > > Consider a a 2 way clone on a 3 node cluster. > > If the clone is active on A and B what should > > > > crm_resource --move --resource myClone --node C > > > > do ? > > I would expect it to create the +inf constraint for C but no > contraint(s) for the current location(s)
You are right. These are different and valid use cases. crm_resource --move --resource myClone --node C -> I want an instance on C, regardless where it is moved off crm_resource --move-off --resource myClone --node C -> I want the instance moved off C, regardless where it is moved on I tried them out with a reimplementation of the patch on a 3 node cluster with a resource with clone-max=2. The behavior appears logical (at least to me 8-) ). > > > This would require an additional --from-node or similar. > > > >> Other than that the proposal looks sane. > >> > >> My first thought was to make --move behave like --move-off if the > >> resource is a clone or /ms, but since the semantics are the exact > >> opposite, that might introduce introduce more problems than it solves. > > > > That was my perception as well. > > > >> > >> Does the original crm_resource patch implement this? > > > > No, I will submit an updated version later this week. > > > > - holger > > > > > > _______________________________________________ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: > > http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker > > _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
