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