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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
