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

You've always had a way with words, Florian :)

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

I agree with you that Corosync/Pacemaker is the tool of choice for 
monitoring/heartbeat functionality, and is my choice for 
compute-node-level HA monitoring. For guest-level HA monitoring, I would 
say use Heat/Ceilometer. For container-level HA monitoring, it looks 
like fleet or something like Kubernetes would be a good option.

I'm curious to see how the combination of compute-node-level HA and 
container-level HA tools will work together in some of the proposed 
deployment architectures (bare metal + docker containers w/ OpenStack 
and infrastructure services run in a Kubernetes pod or CoreOS fleet).

Best,
-jay