OK. I did it with http://developerbugs.linux-foundation.org/show_bug.cgi?id=1963. ;)
2008/9/9 Lars Marowsky-Bree <[EMAIL PROTECTED]>: > On 2008-09-09T23:09:30, Xinwei Hu <[EMAIL PROTECTED]> wrote: > >> But. If there are 2 completely irrelevant resources, Ra & Rb. It'll be >> very reasonable that the customer want to upgrade Rb while letting >> pacemaker still monitoring Ra. What's best practice to do so then ? > > The problem is that all resources which are linked to the one resource > in maintenance mode (assuming that this was possible) are implicitly > also frozen. > > This extends to all rsc_colocation and order constraints, but also > possibly a stop failure (which would cause the node to be fenced). > > So yes, a per-resource approach would be better and more fine-grained, > but a global mode is also needed - that would also be needed for the > rolling upgrades of the cluster stack. > > So, the global option is a first step, solving 80% of the problem. We > can consider the last 20% later, which are also quite a bit harder ;-) > > > Regards, > Lars > > -- > Teamlead Kernel, SuSE Labs, Research and Development > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > > _______________________________________________ > Pacemaker mailing list > [email protected] > http://list.clusterlabs.org/mailman/listinfo/pacemaker >
_______________________________________________ Pacemaker mailing list [email protected] http://list.clusterlabs.org/mailman/listinfo/pacemaker
