[openstack-dev] deliver the vm-level HA to improve the business continuity with openstack

Jay Pipes jaypipes at gmail.com
Mon Apr 14 23:53:19 UTC 2014


On Mon, 2014-04-14 at 18:30 +0000, Tim Bell wrote:
> > -----Original Message-----
> > From: Jay Pipes [mailto:jaypipes at gmail.com]
> > Sent: 14 April 2014 20:05
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] deliver the vm-level HA to improve the business continuity with openstack
> > 
> > On Mon, 2014-04-14 at 10:56 -0700, Steven Dake wrote:
> > > On 04/14/2014 10:46 AM, Tim Bell wrote:
> > > > Can Heat control/monitor a VM which it has not created and restart it (potentially on a different hypervisor with live migration) ?
> > > >
> > > > Tim
> > > Tim,
> > >
> > > No it sure can't.
> > 
> > But a 10-20 line shell script could, calling nova CLI commands.
> > 
> > I think the point here is that we see pushes like this to treat VMs as pets and we've so far been able to successfully push back on
> > these (anti)feature requests, pointing out that this kind of thing generally is antithetical to a utility cloud model and antithetical to
> > the horizontal scale-out architecture that cloud espouses (i.e. don't have a single point of failure that requires this kind of setup).
> > 
> > /me waits for someone to use the word "enterprise".
> > 
> 
> And it is a difficult balance to strike... providing the full v* feature set would have a massive cost. My user community is looking for an on-ramp to cloud. They agree it is the right way to go in the longer term but it has to be a journey, not a 'leap from the lion's head' moment. This has a set of steps from their current service consolidation environment towards a full cloud model. I would find this discussion with my users much easier if we can offer basic VM restart/live migration along the way.

Understood.

For the record, we should improve the (live) migration story in Nova
regardless of any DRS-type feature requests. The migration story right
now is overly complicated for what it needs to be, IMO, and there's lots
of room for simplification and improvement, both on the API and the
implementation level.

Best,
-jay




More information about the OpenStack-dev mailing list