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