> -----Original Message-----
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: October 21, 2014 15:07
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Automatic evacuate
> On 10/21/2014 06:44 AM, Balázs Gibizer wrote:
> > Hi,
> >
> > Sorry for the top posting but it was hard to fit my complete view inline.
> >
> > I'm also thinking about a possible solution for automatic server
> > evacuation. I see two separate sub problems of this problem:
> > 1)compute node monitoring and fencing, 2)automatic server evacuation
> >
> > Compute node monitoring is currently implemented in servicegroup
> > module of nova. As far as I understand pacemaker is the proposed
> > solution in this thread to solve both monitoring and fencing but we
> > tried and found out that pacemaker_remote on baremetal does not work
> > together with fencing (yet), see [1]. So if we need fencing then
> > either we have to go for normal pacemaker instead of pacemaker_remote
> > but that solution doesn't scale or we configure and call stonith
> > directly when pacemaker detect the compute node failure.
> I didn't get the same conclusion from the link you reference.  It says:
> "That is not to say however that fencing of a baremetal node works any
> differently than that of a normal cluster-node. The Pacemaker policy engine
> understands how to fence baremetal remote-nodes. As long as a fencing
> device exists, the cluster is capable of ensuring baremetal nodes are fenced
> in the exact same way as normal cluster-nodes are fenced."
> So, it sounds like the core pacemaker cluster can fence the node to me.
>  I CC'd David Vossel, a pacemaker developer, to see if he can help clarify.

It seems there is a contradiction between chapter 1.5 and 7.2 in [1] as 7.2 
" There are some complications involved with understanding a bare-metal node's 
state that virtual nodes don't have. Once this logic is complete, pacemaker 
will be able to integrate bare-metal nodes in the same way virtual remote-nodes 
currently are. Some special considerations for fencing will need to be 
addressed. "
Let's wait for David's statement on this. 


> --
> Russell Bryant
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to