Open Stack

On 27/11/12 21:43, Eoghan Glynn wrote:
> 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
> 

Eoghan,

I agree with most of the things you point out here, however I feel a bit
differently about the invariant itself.

Even though currently every instance has an image associated and it is
needed for 'boot' command, it does not make sense in all scenarios.
For example, if we create a volume using a builder instance as outlined
in (for example) [1] this image ref is quite useless (and would
therefore be noise in any reports that would consider it as a basic
dimension). To make matters worse (at least in case of libvirt as a
driver), current libvirt.driver code tries to create a libvirt image out
of a totally useless image on the compute node - quite wasteful in terms
of resources, although we could put checks in place for that, but that
leads to my point.

All of the above tells me that the invariant is actually held artificially.

If we will want to do booting from volume right - even using "your" way
- we will likely have code checking weather it is indeed an instance
booted from volume or not. Among other things - that does not seem very
elegant from this perspective (this probably deserves a much deeper
technical discussion).

Further to that I believe that having --volume as a parameter when
booting an instance using the nova client fits better with the current
UI. This is of course not an exact science, but the bug report in the
referenced in my patch [2] tells me that there is at least one other
person that assumed you would not need an image when booting from
volume. Technically we could probably accomplish that by using a
'placeholder' image, but this is not what you had in mind.

It is good that we are having this discussion now, because if my patch
lands, the invariant is definitely defeated, however I honestly feel
that this ship has sailed already (even if not officially).

All the best,

Nikola

[1]
http://docs.openstack.org/trunk/openstack-compute/admin/content/boot-from-volume.html
[2] https://bugs.launchpad.net/nova/+bug/1008622