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

Re: [Cluster-devel] unfencing



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

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


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