[openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload
rbryant at redhat.com
Sun Nov 3 03:42:10 UTC 2013
On 10/30/2013 11:35 PM, Daniel P. Berrange wrote:
> On Wed, Oct 30, 2013 at 04:20:34AM -0400, Russell Bryant wrote:
>> 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.
> I'm not sure I agree with this distinction. I think that in cloud
> individual VMs, and even individual virt hosts, are fine to be
> considered disposable assets. I don't think I'd consider the entire
> cloud deployment to be disposable - which is what we're talking about
> if we consider the "DB lost" disaster scenario. Yes, you may loose
> an entire deployment, but I think you'd want todo as much as is
> reasonable possible to avoid that scenario because it could be very
> costly to have a complete outage like that. Perhaps you'd argue that
> they should use cells, and that individual cells should be considered
> to be completely disposable still ? At some point though I think you
> get to a scale where some disaster recovery is needed.
You're right here ... I was just replying at a ridiculous hour and my
mind was stuck on just being completely against the original request.
But yes, the key is invidual VMs, and even compute hosts, are considered
disposable, not the whole deployment. Thanks for clarifying.
> That all said, in the "DB lost" scenario, I think that detecting and
> reconnecting to VMs is the least of the problems, and certainly not
> the first thing you'd need to attack. You need to know who owns what
> assets, otherwise you'll never be able to allow users access to their
> VMs again. If that ownership data was in the DB that was lost, then
> everything else is somewhat academic until that problem is solved.
> This is somewhat digressing though, since the original blueprint
> mentioned in this thread was not about disaster recovery processes.
Yep, it seemed like it was "I want to install OpenStack and then use it
to manage resources in a pre-existing environment".
More information about the OpenStack-dev