[Pacemaker] Removing resource from group without disturbing remaining resources in group

[Dejan Muhamedagic]

Hi,

On Fri, Jun 07, 2013 at 04:45:34PM +0200, Andreas Mock wrote:
> Hi Dejan,
> 
> we need colocation and order constraints.

If you need both, then groups are fine.

> IMHO it's an use case for sets, but I have to admit
> that I don't really understand how to configure them
> with crm. A group gives a group resource id which I
> can use as reference in the contraints. It makes the
> config simple.

If the configuration is simple, then you're OK. If the resource
sets wouldn't make the configuration any better/simpler, best not
to use them. Otherwise, the syntax is simple and should be
available with the help (crm configure help order/colocation).

Thanks,

Dejan

> 
> IP1-|
> IP2---> service
> IP3-|
> 
> IP1 .. IP40
> 
> Advices welcome.
> 
> Best regards
> Andreas
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Dejan Muhamedagic [mailto:dejanmm at fastmail.fm] 
> Gesendet: Freitag, 7. Juni 2013 15:55
> An: 'The Pacemaker cluster resource manager'
> Betreff: Re: [Pacemaker] Removing resource from group without disturbing
> remaining resources in group
> 
> On Thu, Jun 06, 2013 at 06:15:26PM +0200, Andreas Mock wrote:
> > Hi Florian,
> > 
> > thank you very much for that method description.
> > It seems that it does exactly what we want. By the way.
> > It's the same use case as yours. Many IP for which we
> > want a constraint handle (group).
> 
> But wouldn't just a collocation constraint do if the order is not
> important?
> 
> Thanks,
> 
> Dejan
> 
> > Thank you!
> > 
> > Best regards
> > Andreas Mock
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Florian Crouzat [mailto:gentoo at floriancrouzat.net] 
> > Gesendet: Donnerstag, 6. Juni 2013 16:50
> > An: pacemaker at oss.clusterlabs.org
> > Betreff: Re: [Pacemaker] Removing resource from group without disturbing
> > remaining resources in group
> > 
> > Le 06/06/2013 16:35, Andreas Mock a écrit :
> > > Hi all,
> > >
> > > is there a way to remove a resource from a group without
> > > disturbing the other resources in the group.
> > >
> > > The following example:
> > > - G1 has R1 R2 R3
> > > - All resources are started
> > > - Stopping R1 would cause a stop of R2 R3
> > > - So, the idea was:
> > > * crm configure edit => remove R1 from the group while running
> > > * stop resource
> > > * delete resource
> > >
> > > BUT: At some point (which we couldn't find out at
> > > the moment) all remaining resources of the group are
> > > restarted. It seems that the change of the implicit
> > > dependency tree of the initial group forces a rebuild
> > > of that tree including a restart of that group.
> > > (Andrew: Is this assumption right?)
> > >
> > > So, is there are way to add/remove resources from
> > > group without disturbing the other resources.
> > > It's clear to me that the resources would restart
> > > when the node assignment after removing would change.
> > >
> > > Hints welcome.
> > >
> > 
> > Approximative syntax, do not blame me !
> > 
> > * crm configure property maintenance-mode=true
> > * crm resource stop R1 # it won't stop as it's in maintenance-mode
> > * crm configure delete R1
> > * crm configure show # very that all references to R1 are gone
> > * crm resource reprobe # the cluster double check the status of declared 
> > resources and sees that everything is fine and R1 doesn't exists anymore
> > * crm_mon -Arf1 # double check that everything is "started (unmanaged)" 
> > and R1 is gone
> > * crm_simulate -S -L -VVV # optional, to check what would happen when 
> > leaving maintenance-mode
> > * crm configure property maintenance-mode=false
> > 
> > If something goes wrong while in maintenance-mode, crm resource cleanup 
> > foo might be handy. Nothing should move, start or stop until you leave 
> > maintenance-mode anyway. I use this scenario very often, to add or 
> > remove IPaddr2 resources to a group of 30+ IPaddr2.
> > 
> > 
> > -- 
> > Cheers,
> > Florian Crouzat
> > 
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker at 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://bugs.clusterlabs.org
> > 
> > 
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker at 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://bugs.clusterlabs.org
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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://bugs.clusterlabs.org
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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://bugs.clusterlabs.org