<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 8:31 AM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><tt><font>Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>> wrote on 30/10/2013
10:20:34 AM:<div class="im"><br>
> On 10/30/2013 03:13 AM, Alex Glikson wrote:<br>
> > Maybe a more appropriate approach could be to have a tool/script
that<br>
> > does it, as a one time thing.<br>
> > For example, it could make sense in a scenario when Nova DB gets
lost or<br>
> > corrupted, a new Nova controller is deployed, and the DB needs
to be<br>
> > recreated. Potentially, since Nova DB is primarily a cache, this
could<br>
> > be done by 'discovery' (maybe with some manual intervention)
- instead<br>
> > of dealing with backup/restore of the DB, or similar approaches.<br>
> <br>
> The need for this sort of thing makes more sense for traditional<br>
> datacenter virtualization, but not as much for cloud.  That's
the root<br>
> of my objection.</div></font></tt>
<br>
<br><tt><font>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? </font></tt> <br></blockquote><div><br></div><div><br></div><div><br></div><div>I see two pieces here.</div><div><br></div><div>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 (<a href="https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor">https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor</a>), 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?</div>

<div><br></div><div>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.</div>

<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888">
<br><tt><font>Alex</font></tt>
<br></font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>