> -----Original Message----- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: October 21, 2014 15:07 > To: email@example.com > 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 . 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  as 7.2 states: " 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. Cheers, Gibi > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev