Open Stack

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. 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?

2) I have always assumed a cloud is deployed in an HA Configuration, but
really like the idea of treating the nova DB as a cache and being able to
rebuild it, but that implies we are only collecting information for VMs
that nova originally was managing (At the very least as the first step). If
we try to auto-discover / rebuild a DB using existing VMs that nova didn't
originally manage, I think we will open a big can of worms in the form of
edge cases we would need to handle.  I think this is feature is a seperate
discussion. And until nova supports this model, I don't think we should try
to use it as as stepping stone to implement another feature.



>
> Alex
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/ed239625/attachment.html>