Open Stack

> I was looking into the following summit etherpad
> https://etherpad.openstack.org/grizzly-boot-from-volumes
> and how to improve launching instances from volumes only and thought
> the lowest hanging fruit would be to make nova capable of launching
> instances without an image supplied, so here are two patches that I
> would like to get thoughts on:
> 
> https://review.openstack.org/#/c/16099/
> https://review.openstack.org/#/c/16101/
> 
> I do not necessarily expect them to be merged as-is, but I think they
> can be a nice introduction to a discussion of what can be done. I
> deliberately tried to make them as unobtrusive as possible.
> 
> There are of course some issues that these changes will cause, and of
> course I may have missed some problems, however, it felt like a
> reasonable first step towards improved support for booting from
> volumes.
> 
> Looking forward to everyone's feedback,

Hi Nikola,

Thanks for the patches, and sincere apologies for the delay in responding
to the request for feedback.

As discussed on IRC earlier, I had an idea for an alternative approach
that I just wanted to throw out there so that anyone with an interest
can chime in.

TL;DR: maintain the invariant that instances are always booted from images

So the idea is motivated by the fact that we already have a convenience
mechanism for booting from volume under limited circumstances. This is
relevant when a snapshot of a running volume-backed instance is created,
whereby nova registers a content-free placeholder image in glance that just
acts as a bucket for the properties needed to boot the instance (kernel
& ramdisk IDs, and more importantly the block device mapping property).

Essentially this snapshot image allows instances to be spun up with
just an image ID, without directly specifying the block device mapping
(as this is taken from the image properties). 

The new more general approach you've proposed is to get away from needing
an image ID at all, and instead to allow an instance be booted with only
the block device mapping specified. 

Now what I like about the placeholder image is that the idiom of booting
an instance from an image is maintained consistently. It also fits in
nicely with the EC2 concept of an EBS-based AMI, and how the RunInstances
API requires an ImageId parameter (as opposed to allowing a volume or
snapshot ID to be directly provided). There are further nice side-effects,
such as the fact that EC2 instances can always report metrics to CloudWatch
with the ImageId dimension set, as there's an always an image involved
(this allows aggregation of metrics from all instances booted from the
same image). 

So the alternative that came to mind is that we extend the usage of
the placeholder image to the general case, e.g. by extending novaclient
or by providing an API extension that allows such an image to be
created, given a volume or snapshot ID.

Then the image so created can be used to boot any number of instances
in the traditional way, while maintaining the instance<-->image_id
invariant.

This link between instance and image ID would be less tenuous than is
currently the case for volume-backed instances created in the traditional
way (where the image really only provides the kernel and ramdisk ID).

This suggestion would involve a shift in course from what was discussed
at summit[1], so I just wanted to throw it out there for feedback (esp.
from the participants in that discussion).

Cheers,
Eoghan

[1] https://etherpad.openstack.org/grizzly-boot-from-volumes