openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

2011/1/16 Diego Parrilla Santamaría <diego.parrilla.santamaria@xxxxxxxxx>:
> I think VMDK subtypes are very relevant information and has to be indicated
> before a deployment. Just an example: if you try to deploy a streamOptimized
> or even some sparse formats directly to VMware ESXi they won't work, and
> troubleshooting for newbies can be complicated.
> I'm not very famliar with Glance yet. So may be some of my asumptions can
> sound stupid...

Hi again! Sorry for the delay in getting back to you and for the
somewhat interleaved responses to similar questions with Ewan Melllor
:)

The above is exactly the kind of information that we'll need in
developing Glance in Cactus. See more below... :)

> I guess that one of the main purpose of Glance is to deal with Object
> Storage Services (Swift or S3 for example) because they are the best
> candidates to store virtual images. I think this is a 'necessary evil': such
> a big images must be stored somewhere.

Yes, Glance is responsible for delivering and caching images that are
stored elsewhere. Glance has a registry of information about images.
Currently, the information stored about each image is as follows:

id - unique identifier of an image within a registry
name - user-defined name for the image (ex: "Stock Ubuntu 10.10 5G
with LAMP stack")
is_public - whether or not the image is shown when a user does GET
/images or GET /images/detail
status - choice between 'queued', 'saving', 'active', or 'killed'
type - choice between 'kernel','machine','ramdisk', and 'raw'. This
field is what is proposed to go away and be replaced with the
disk_format and appliance_format fields we've been discussing on this
thread.
created_at, deleted_at - timestamps for creation and deletion, pretty
self-explanatory...
modified_at - timestamps for when image *metadata* has changed (since
an image itself is read-only once stored in Glance)

In addition to the above, there is a set of custom key/value pairs
that can be associated with an image. We call these the image's
"properties", and they are returned from Glance in the
x-image-meta-property-<KEY> headers.

> What I don't really get is how Glance is going to deal with all the
> different virtual images formats supported for the different hypervisors. I
> mean, who is going to convert from virtual image format X to the virtual
> image format needed by hypervisor Y? Is Glance responsible for this or the
> Compute Node? May be if you explain me a little bit how it will work I can
> be more helpful. I'm still with Austin and I will start to work on the Bexar
> branch very soon.

Image conversion is planned for Cactus:
https://blueprints.launchpad.net/glance/+spec/image-conversion.

We still need to decide which formats we want to focus on initially.
My inclination is to ask folks what are the most popular formats and
start from there, leaving rarely-used formats for later...

Hope this helps, Diego!

-jay