Open Stack

On 10/16/2014 04:29 AM, Florian Haas wrote:
>>>>> (5) Let monitoring and orchestration services deal with these use
>>>>> cases and
>>>>> have Nova simply provide the primitive API calls that it already does
>>>>> (i.e.
>>>>> host evacuate).
>>>>
>>>> That would arguably lead to an incredible amount of wheel reinvention
>>>> for node failure detection, service failure detection, etc. etc.
>>>
>>> How so? (5) would use existing wheels for monitoring and orchestration
>>> instead of writing all new code paths inside Nova to do the same thing.
>>
>> Right, there may be some confusion here ... I thought you were both
>> agreeing that the use of an external toolset was a good approach for the
>> problem, but Florian's last message makes that not so clear ...
> 
> While one of us (Jay or me) speaking for the other and saying we agree
> is a distributed consensus problem that dwarfs the complexity of
> Paxos, *I* for my part do think that an "external" toolset (i.e. one
> that lives outside the Nova codebase) is the better approach versus
> duplicating the functionality of said toolset in Nova.
> 
> I just believe that the toolset that should be used here is
> Corosync/Pacemaker and not Ceilometer/Heat. And I believe the former
> approach leads to *much* fewer necessary code changes *in* Nova than
> the latter.

Have you tried pacemaker_remote yet?  It seems like a better choice for
this particular case, as opposed to using corosync, due to the potential
number of compute nodes.

-- 
Russell Bryant