← Back to team overview

openstack team mailing list archive

Re: Glance x-image-meta-type raw vs machine


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
created_at, deleted_at - timestamps for creation and deletion, pretty
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:

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!


Follow ups