Open Stack

On 29/11/12 01:53, Vishvananda Ishaya wrote:
> I'm going to summarize the discussion at the summit just so it is included here.
> 
> There are two things you really need to be able to specify for each of the drives in your instance:
> 
> 1) What is the source of the bits?
> 
>  * image in glance
>  * volume in cinder
>  * snapshot in cinder
>  * local file
>  * empty
>  * formatted ext4
> 
> 2) What is the destination of the volume (location and size):
>  
>  * permanent local disk
>  * ephemeral local disk
>  * remote volume
> 
> The confusion about boot-from-volume arises because the destination is interpreted
> from the source (and sometimes the source is interpreted from the instance type)
> 
> Examples:
>   If source is a snapshot in cinder, then the destination will be a remote volume
>   If source is an image in glance, then the destination will be permanent local disk
>   If it is the second drive of an instance, then the source will be formatted ext4
> 
> We had a goal at the summit of making these things explicit, but this thread shows that there
> is one aspect we did not consider: where does the metadata about the boot source come from?
> 
> We store various metadata that we currently can store in glance, such as image format. The
> metadata is used in scheduling for example. It may also in the future be used to determine
> different emulation modes for hardware (as in images that don't support virtio networking).
> The metadata needs to come from somewhere.
> 
> There are three options here:
> 
> 1) metadata is stored in glance
> 2) metadata is passed in at boot time
> 3) metadata is stored along with the bits somewhere (metadata in cinder)
> 
> It bears mentioning that we already support 1) you can create a metadata-only image today.
> We already have limited support for 2), you can set the bdm data at boot time.
> 

Thanks for this summary. It is indeed useful to have it put in complete
sentences rather than simple bullet points like in the summit Etherpad [1].

> I think overriding metadata at boot time is valuable, so i see no need to remove that ability.
> 
> So the question boils down to whether we REQUIRE metadata in glance. It definitely makes
> things simpler but it also makes the user experience quite painful. If I want to boot with a
> source of a glance image and have a persistant volume. I have to go to cinder to create a volume
> from the image, then go to glance to create a new image backing to the volume, then go
> to nova to boot the new image. Yuck!
> 
> To boot a vm, we need source bits. our image_id represents both the metadata and (sometimes)
> the source bits. If a user sends us sufficient metadata for us to find the source bits, I
> don't think we need to require putting metadata in glance. It seems like it might be a useful
> default however.

Turning the discussion back to my patch [2] - based on the above - I see
no reason it shouldn't land. The only thing it really does is make it
possible to boot an instance without image supplied if there is bdm's
supplied.

Granted it does not offer any safeguards against starting an instance
with incorrect mapping that won't be able to boot, but as I said - this
is meant to be the first in a series of patches that will lead us to
having booting from volume done right, and not provide the whole solution.

Also I tried to make it as unobtrusive and review-friendly as possible.
Basically only long-term impact of the patch is that from this point on
- it is possible to have instances with an empty image_ref.

> It also adds extra round trips to glance that wouldn't be necessary if we omit the image_id.

This is as well already included in [2]


Having said all that, I would like to ask Vish, Eoghan and other
reviewers to revisit the patch [2], and re-evaluate it with this
discussion in mind, and maybe point out some more subtle technical
issues with it, because I feel the patch does not clash with the
direction discussed on the summit and summarized here (actually, I think
it doesn't even push us in any direction yet, when it comes to 'booting
from volume').

Either way - thanks a lot for looking into this.

All the best,

Nikola

[1] https://etherpad.openstack.org/grizzly-boot-from-volumes.
[2] https://review.openstack.org/#/c/16099/