----- Original Message ----- > From: "Florian Haas" <flor...@hastexo.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > > On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant <rbry...@redhat.com> wrote: > > 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. > > I'll assume that you are *not* referring to running Corosync/Pacemaker > on the compute nodes plus pacemaker_remote in the VMs, because doing > so would blow up the separation between the cloud operator and tenant > space. > > Running compute nodes as baremetal extensions of a different > Corosync/Pacemaker cluster (presumably the one that manages the other > Nova services) would potentially be an option, although vendors would > need to buy into this. Ubuntu, for example, currently only ships > pacemaker-remote in universe.
This is something we'd be doing *too* OpenStack rather than *in* the OpenStack projects (at least those that deliver code), in fact that's a large part of the appeal. As such I don't know that there necessarily has to be one true solution to rule them all, a distribution could deviate as needed, but we would have some - ideally very small - number of "known good" configurations which achieve the stated goal and are well documented. Thanks, Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev