>>>> (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.


OpenStack-dev mailing list

Reply via email to