Open Stack

----- Original Message -----
> Steve,
> The problem with the support of live-migrate would still exist even if we
> decide to manage only one cluster from a compute node, unless one is ok with
> only live-migrate functionality between clusters.  The main debate started
> with supporting the live-migrate between the ESX Hosts in the same cluster.
> 
> Thanks,
> Divakar

We actually originally started off with ~7 migration scenarios in this thread [1], I'm speaking to what I consider the most problematic one (scenario 1) which is migration between clusters managed by the same nova-compute. I think it's if you wish to address both this *and* migration between ESX hosts within a cluster that we run into problems whereby it's going to require significant changes to Nova because you need not one but two additional levels of introspection. That is on top of the concerns I noted regarding fault tolerance and high availability when you have a single nova-compute managing multiple (or even all) ESX clusters in the environment.

-Steve

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030768.html

> -----Original Message-----
> From: Steve Gordon [mailto:sgordon at redhat.com]
> Sent: Wednesday, April 09, 2014 8:38 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live
> migration with one nova compute
> Importance: High
> 
> ----- Original Message -----
> > I'm not writing off vCenter or its capabilities. I am arguing that the
> > bar for modifying a fundamental design decision in Nova -- that of
> > being horizontally scalable by having a single nova-compute worker
> > responsible for managing a single provider of compute resources -- was
> > WAY too low, and that this decision should be revisited in the future
> > (and possibly as part of the vmware driver refactoring efforts
> > currently underway by the good folks at RH and VMWare).
> 
> +1, This is my main concern about having more than one ESX cluster under a
> single nova-compute agent as well. Currently it works, but it doesn't seem
> particularly advisable as on face value as such an architecture seems to
> break a number of the Nova design guidelines around high availability and
> fault tolerance. To me it seems like such an architecture effectively
> elevates nova-compute into being part of the control plane where it needs to
> have high availability (when discussing on IRC yesterday it seemed like this
> *may* be possible today but more testing is required to shake out any bugs).
> 
> Now may well be the right approach *is* to make some changes to these
> expectations about Nova, but I think it's disingenuous to suggest that what
> is being suggested here isn't a significant re-architecting to resolve
> issues resulting from earlier hacks that allowed this functionality to work
> in the first place. Should be an interesting summit session.
> 
> -Steve
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)