FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 02-26-2009, 05:06 PM
"Fabio M. Di Nitto"
 
Default unfencing (cman startup)

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.)

hmm.. it might be reasonable to ask cman_tool to do that, but if you
look for example how cmannotifyd works (i know not all daemons can do
that), it can cope with cman going away and coming back (no matter
what's the reason).

>
> > The second thing would be to set a minimal protection mechanism by
> > allowing fence_node -U to be fired only for the node that it is invoking
> > it. So if we run on node A, fence_node -U can only execute unfencing
> > operations for node A. For testing purposes then we could add a manual
> > override such as "--i-understand-this-operation-can-destroy-the-world".
>
> I plan to use "fence_node -U" (no name) to unfence self. I'm inclined to
> just allow any node name after that, but not advertise it.

a bit too late.. we are on a public mailing list

Fabio
 
Old 02-27-2009, 11:54 AM
Chrissie Caulfield
 
Default 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

Chrissie
 
Old 02-27-2009, 02:52 PM
David Teigland
 
Default unfencing (cman startup)

On Fri, Feb 27, 2009 at 12:54:20PM +0000, Chrissie Caulfield wrote:
> >>> 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.

Great, so the constant flogging to add cman_is_active checks everywhere will
end!? Can I remove all my cman_is_active loops?
 
Old 02-27-2009, 03:27 PM
Chrissie Caulfield
 
Default unfencing (cman startup)

David Teigland wrote:
> On Fri, Feb 27, 2009 at 12:54:20PM +0000, Chrissie Caulfield wrote:
>>>>> 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.
>
> Great, so the constant flogging to add cman_is_active checks everywhere will
> end!? Can I remove all my cman_is_active loops?

Yes.

And if it doesn't work, file a bug

Chrissie
 
Old 02-27-2009, 04:46 PM
"Fabio M. Di Nitto"
 
Default unfencing (cman startup)

On Fri, 2009-02-27 at 09:52 -0600, David Teigland wrote:
> On Fri, Feb 27, 2009 at 12:54:20PM +0000, Chrissie Caulfield wrote:
> > >>> 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.
>
> Great, so the constant flogging to add cman_is_active checks everywhere will
> end!? Can I remove all my cman_is_active loops?

This works fine via init script. We could theoretically kill all those
loops but at least for us developers, that start stuff by hand, they
could still be useful.. and maybe a good failsafe if we ask users to run
something manually for debugging.. dunno.. just a thought. I don't have
a strong opinion on this matter.

Fabio
 
Old 03-02-2009, 06:59 AM
Chrissie Caulfield
 
Default unfencing (cman startup)

Fabio M. Di Nitto wrote:
> On Fri, 2009-02-27 at 09:52 -0600, David Teigland wrote:
>> On Fri, Feb 27, 2009 at 12:54:20PM +0000, Chrissie Caulfield wrote:
>>>>>> 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.
>> Great, so the constant flogging to add cman_is_active checks everywhere will
>> end!? Can I remove all my cman_is_active loops?
>
> This works fine via init script. We could theoretically kill all those
> loops but at least for us developers, that start stuff by hand, they
> could still be useful.. and maybe a good failsafe if we ask users to run
> something manually for debugging.. dunno.. just a thought. I don't have
> a strong opinion on this matter.
>

You might as well take them out to be honest. Those loops are mostly
overspill from the RHEL4 cman where cman started up but could take 20-30
seconds to start or join a cluster. With openais/corosync once the
daemon is up then you can talk to it.

It might not be quorate ... but that IS your problem :-)

Chrissie
 

Thread Tools




All times are GMT. The time now is 11:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org