Open Stack

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.

Regards,
Alex




From:   Russell Bryant <rbryant at redhat.com>
To:     openstack-dev at lists.openstack.org, 
Date:   30/10/2013 08:52 AM
Subject:        Re: [openstack-dev] 
[OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in 
OpenStack for existing workload



On 10/30/2013 02:36 AM, Swapnil Kulkarni wrote:
> I had a discussion with russellb regarding this for yesterday, I would
> like to discuss this with the team regarding the blueprint mentioned in
> subject.
> 
> 
https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor

> 
> Description: Organizations opting to use openstack can have varied
> amount of workload that they would like to be available directly with
> the use of some discovery workflows. One common usage of this would be
> exising virtual machines present on the hypervisors. If this instances
> can be disovered by the compute agent during discovery, it would help to
> use Openstack to manage the existing workload directly. Auto VM
> Discovery will enable this functionality initially for KVM guests, the
> widely used hypervisor configuration in OpenStack deployments and
> enhance it further for other hypervisors.

I feel that Nova managing VMs that it didn't create is not an
appropriate use case to support.

-- 
Russell Bryant

_______________________________________________
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/65f40419/attachment.html>