<div dir="ltr">Be forewarned; here's my two cents before I've had my morning coffee. <div><br></div><div>It would seem to me that if we were seeking some level of resiliency against host failures (if a host fails, evacuate the instances that were hosted on it to a host that isn't broken), it would seem that host HA is a good approach. The ultimate goal of course is instance HA but the task of monitoring individual instances and determining what constitutes "down" seems like a much more complex task than detecting when a compute node is down. I know that requiring the presence of agents should probably need some more brain-cycles since we can't expect additional bytes consuming memory on each individual VM.<div><br></div><div>Additionally, I'm not really hung up on the 'how' as we all realize there several ways to skin that cat, so long as that 'how' is leveraged via tools over which we have control and direct influence. Reason being, we may not want to leverage features as important as this on tools that change outside our control and subsequently shifts the foundation of the feature we implemented that was based on how the product USED to work. Basically if Pacemaker does what we need then cool but it seems that implementing a feature should be built upon a bedrock of programs over which we have a direct influence. This is why Nagios may be able to do it but it's a hack at best. I'm not saying Nagios isn't good or ythe hack doesn't work but in the context of an Openstack solution, we can't require a single external tool for a feature like host or VM HA. Are we suggesting that we tell people who want HA - "go use Nagios"? Call me a purist but if we're going to implement a feature, it should be our community implementing it because we have some of the best minds on staff. ; )</div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: +1 302-387-4660</div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: +1 916-246-2072</div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div>
<br><div class="gmail_quote">On Thu, Oct 16, 2014 at 7:53 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/16/2014 09:00 AM, Florian Haas wrote:<br>
> On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>> On 10/16/2014 04:29 AM, Florian Haas wrote:<br>
>>>>>>> (5) Let monitoring and orchestration services deal with these use<br>
>>>>>>> cases and<br>
>>>>>>> have Nova simply provide the primitive API calls that it already does<br>
>>>>>>> (i.e.<br>
>>>>>>> host evacuate).<br>
>>>>>><br>
>>>>>> That would arguably lead to an incredible amount of wheel reinvention<br>
>>>>>> for node failure detection, service failure detection, etc. etc.<br>
>>>>><br>
>>>>> How so? (5) would use existing wheels for monitoring and orchestration<br>
>>>>> instead of writing all new code paths inside Nova to do the same thing.<br>
>>>><br>
>>>> Right, there may be some confusion here ... I thought you were both<br>
>>>> agreeing that the use of an external toolset was a good approach for the<br>
>>>> problem, but Florian's last message makes that not so clear ...<br>
>>><br>
>>> While one of us (Jay or me) speaking for the other and saying we agree<br>
>>> is a distributed consensus problem that dwarfs the complexity of<br>
>>> Paxos, *I* for my part do think that an "external" toolset (i.e. one<br>
>>> that lives outside the Nova codebase) is the better approach versus<br>
>>> duplicating the functionality of said toolset in Nova.<br>
>>><br>
>>> I just believe that the toolset that should be used here is<br>
>>> Corosync/Pacemaker and not Ceilometer/Heat. And I believe the former<br>
>>> approach leads to *much* fewer necessary code changes *in* Nova than<br>
>>> the latter.<br>
>><br>
>> Have you tried pacemaker_remote yet?  It seems like a better choice for<br>
>> this particular case, as opposed to using corosync, due to the potential<br>
>> number of compute nodes.<br>
><br>
> I'll assume that you are *not* referring to running Corosync/Pacemaker<br>
> on the compute nodes plus pacemaker_remote in the VMs, because doing<br>
> so would blow up the separation between the cloud operator and tenant<br>
> space.<br>
<br>
</div></div>Correct.<br>
<span class=""><br>
> Running compute nodes as baremetal extensions of a different<br>
> Corosync/Pacemaker cluster (presumably the one that manages the other<br>
> Nova services)  would potentially be an option, although vendors would<br>
> need to buy into this. Ubuntu, for example, currently only ships<br>
> pacemaker-remote in universe.<br>
<br>
</span>Yes, this is what I had in mind.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>