implemented in:
http://hg.clusterlabs.org/pacemaker/dev/rev/4ea3d9b3fb51
:-)
On Sep 10, 2008, at 12:06 PM, Xinwei Hu wrote:
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
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
