[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] unfencing (cman startup)

Fabio M. Di Nitto wrote:
> On Thu, 2009-02-26 at 08:33 -0600, David Teigland wrote:
>> On Thu, Feb 26, 2009 at 07:51:57AM +0100, Fabio M. Di Nitto wrote:
>>> On Mon, 2009-02-23 at 13:09 -0600, David Teigland wrote:
>>>> On Mon, Feb 23, 2009 at 07:52:55PM +0100, Fabio M. Di Nitto wrote:
>>>>>> A node unfences *itself* when it boots up.  As such, power-unfencing doesn't
>>>>>> make sense; unfencing is only meant to reverse storage fencing.
>>>>> What can stop a user to run fence_node -U from another node to do remote
>>>>> (un)fencing?
>>>> It would work.  Users can do anything they like, that's beside the point.
>>> I was thinking about 2 little points..
>>> Given the time at which fence_node -U will fire, you probably want to
>>> add a cman_init + cman_is_active + cman_finish loop in fence_node to
>>> make sure cman is ready to reply to our ccs queries, otherwise we might
>>> have a race condition at boot time (it might be already there.. didn't
>>> really check the code). All our daemons do that to give cman time to
>>> bootstrap.
>> Yes, good point.  I wonder if we'd be better off having cman_tool join
>> effectively do an is_active wait before exiting?  Then we could probably
>> avoid doing it many other places.  (It's also annoying when corosync crashes
>> after is_active completes, but before I've read what I need from cman/ccs.)

Err, cman_tool already does this with the -w switch, and the init script
uses it.

> hmm.. it might be reasonable to ask cman_tool to do that, b


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]