Hi Dejan, On Mon, 2011-03-21 at 16:11 +0100, Dejan Muhamedagic wrote: > Hi Holger, > > On Sat, Mar 19, 2011 at 11:55:57AM +0100, Holger Teutsch 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 > > > > crm_resource --move --resource myresource --master --node mynode > > -> master: create prefer constraint for master role > > -> others: refused > > > > They should work (witch foreseeable outcome!) regardless of the setting of > > clone-max. > > This seems quite complicated to me. Took me a while to figure > out what's what and where :) Why bother doing the thinking for
I'm afraid the matter *is* complicated. The current implementation of crm_resource --move --resource myResource (without node name) is moving off the resource from the node it is currently active on by creating a standby constraint. For clones and masters there is no such *single* active node the constraint can be constructed for. Consider this use case: I have 2 nodes and a clone or master and would like to safely get rid of one instance on a particular node (e.g. with agents 1.0.5 the slave of a DB2 HADR pair 8-) ). No idea how that should be done without a move-off functionality. > users? The only case which seems to me worth considering is > refusing setting role for non-ms resources. Otherwise, let's let > the user move things around and enjoy the consequences. Definitely not true for production clusters. The tools should produce least surprise consequences. > > Cheers, > Over the weekend I implemented the above mentioned functionality. Drop me note if you want to play with an early snapshot 8-) Regards 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