[Pacemaker] Temporarily disabling the cluster
Andrew Beekhof
beekhof at gmail.com
Wed Sep 10 11:38:34 UTC 2008
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 <lmb at suse.de>:
>> On 2008-09-09T23:09:30, Xinwei Hu <hxinwei at gmail.com> 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
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
More information about the Pacemaker
mailing list