Open Stack

Definitely +1.

This change will allow us to get rid of the of the ugly special cases where we use the instance name instead of the uuid and will make the code cleaner.  Let's go for it!

Thanks,
Rado

----- Original Message -----
> Currently we create a rescue instance by creating a new VM with the
> original instance's image, then adding the original instance's first
> disk to it, and booting. This means we have 2 VMs, which we need to be
> careful of when cleaning up. Also when suspending, and probably other
> edge cases. We also don't support:
> 
> * Rescue images other than the instance's creation image
> * Rescue of an instance which wasn't created from an image
> * Access to cinder volumes from a rescue instance
> 
> I've created a dirty hack which, instead of creating a new VM, attaches
> the given rescue image to the VM and boots from it:
> 
> https://review.openstack.org/#/c/106078/
> 
> It works for me. It supports all of the above, doesn't require special
> handling on destroy, and works with suspend[1]. It also doesn't trigger
> the spurious warning message about unknown VMs on the cluster which,
> while unimportant in itself, is an example of an edge case caused by
> having 2 VMs.
> 
> Does this seem a reasonable way to go? It would be dependent on a
> refactoring of the image cache code so we could cache the rescue image.
> 
> Matt
> 
> [1] If suspend of a rescued image wasn't broken at the api level,
> anyway. I have a patch for that: https://review.openstack.org/#/c/106082/
> --
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
> 
> Phone: +442070094448 (UK)
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>