Open Stack

On Wed, Oct 30, 2013 at 10:35:59AM +0000, Joe Gordon wrote:
> On Wed, Oct 30, 2013 at 8:31 AM, Alex Glikson <GLIKSON at il.ibm.com> wrote:
> 
> > Russell Bryant <rbryant at redhat.com> wrote on 30/10/2013 10:20:34 AM:
> >
> > > On 10/30/2013 03:13 AM, Alex Glikson wrote:
> > > > Maybe a more appropriate approach could be to have a tool/script that
> > > > does it, as a one time thing.
> > > > For example, it could make sense in a scenario when Nova DB gets lost
> > or
> > > > corrupted, a new Nova controller is deployed, and the DB needs to be
> > > > recreated. Potentially, since Nova DB is primarily a cache, this could
> > > > be done by 'discovery' (maybe with some manual intervention) - instead
> > > > of dealing with backup/restore of the DB, or similar approaches.
> > >
> > > The need for this sort of thing makes more sense for traditional
> > > datacenter virtualization, but not as much for cloud.  That's the root
> > > of my objection.
> >
> >
> > Not sure I understand why.. Do you assume that the cloud necessarily runs
> > stateless workloads, so that loosing VM instances is not an issue? (what
> > about volumes that could've been attached to them?) Or do you assume that
> > cloud is necessarily deployed in HA configuration that never gets broken?
> >
> >
> 
> 
> 
> I see two pieces here.
> 
> 1) I agree with Russell that Nova should not try to manage VMs it didn't
> create.

Same for me.

As one example of why Nova should *not* try to manage VMs it does not
create, consider libguestfs. It is used by Nova for file injection and
it creates transient VMs for doing its work. Nova should not try to
manage those transient VMs as if they were cloud instances.

Second, Nova has a number of assumptions about the configuration of
VMs that it creates, particularly around storage and network. IMHO
it is not feasible for Nova todo the right thing with 3rd party created
VMs which can have arbitrary storage / network configurations. You might
be able to make start/stop of such VMs work, but when you look at complex
stuff like migration/snapshots, such 3rd party created VMs will cause
a world of hurt and likely data loss / corruption and/or network security
screwups.

>        Also a cloud friendly application, that handles instance failures
> in software, should make this sort of migration fairly easy.  Even if I
> wanted this Blueprint in nova (
> https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor),
> it is very vague and doesn't explain how you would implement it, so if we
> were planning on approving it we would have to say please flesh it out
> further first.  What is the design, what steps are involved, what is the
> DocImpact, what are the risks, how would you can we test and gate on this
> working etc?

Yep, the blueprint has inadequate info for such a complex problem.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|