Open Stack

I'd like to expand on this at an upcoming meetup with some glance and cinder people.  Come out of it with blueprints to focus on or create. Thoughts?
sean
roberts

infrastructure strategy

seanrob at yahoo-inc.com<applewebdata://2E35986A-DC2A-436F-BB4A-C451982006C2/seanrob@yahoo-inc.com>
direct 408-349-5234    mobile 925-980-4729

701 first avenue, sunnyvale, ca, 94089-0703, us
phone (408) 349 3300    fax (408) 349 3301
[cid:5CC2DB27-C6D2-429A-BDB9-0BDB1177E6E0]

On 11/28/12 4:53 PM, "Vishvananda Ishaya" <vishvananda at gmail.com<mailto:vishvananda at gmail.com>> wrote:


On Nov 28, 2012, at 1:50 PM, Eoghan Glynn <eglynn at redhat.com<mailto:eglynn at redhat.com>> wrote:

You could be right there, but in any case good to air the
discussion, and hopefully scare up a couple more view-points.


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.

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!

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

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.

Vish



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121129/3ab274ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 692777FE-D8B6-45A3-9766-10CF9F9A8C42[41].png
Type: image/png
Size: 6257 bytes
Desc: 692777FE-D8B6-45A3-9766-10CF9F9A8C42[41].png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121129/3ab274ec/attachment.png>