openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

I think that it's too early to think about what should be in these fields, or even whether these are the right fields.  We need to design the conversion service first, and then we'll know what fields we need.  It doesn't make sense to set the database schema before we've decided what the data are for.

Ewan.

-----Original Message-----
From: Jay Pipes [mailto:jaypipes@xxxxxxxxx] 
Sent: 17 January 2011 15:31
To: Ewan Mellor
Cc: Diego Parrilla Santamaría; openstack@xxxxxxxxxxxxxxxxxxx; John Purrier
Subject: Re: [Openstack] Glance x-image-meta-type raw vs machine

2011/1/17 Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>:
> If by "appliance format" you mean "disk image + metadata about the VM" as distinguished from plain disk images, then the combination of a VMDK and a VMX could be considered to be an appliance format.  If you mean something richer (e.g. an "appliance" must be able to describe multiple VMs) then I don't think that it falls into that category.  It really depends upon what you're trying to do with this information (something that I don't understand, yet).

I don't yet know, either. That was the point of most of these
discussions...in other words, what information should be attached to
the image information in Glance that would be useful to people working
with those images. And, further, what more granular breakdown of these
formats would be useful to the user? This is why I asked whether
disk_format and appliance_format and the choices I laid out for those
fields, were appropriate levels of granularity.

> I don't care what we call it.  Whether it's "VMX" or "VMDK" or "VMX+VMDK" or "VMware", it's all going to end up meaning "proprietary goop" at the end of the day.

Sure, but I did not know that those all meant the same thing, which is
why I asked in the first place. :)

> I agree with Diego (elsewhere in this thread) that VMDK subtypes would be useful metadata for Glance to be able to provide.  They may need to be streamed or unpacked differently as they move from Glance to a compute node, so if Glance has that metadata, then we don't need to do autodetection on the way through.

OK, so you think that these VMDK subtypes should be listed in the
choices available for the disk_format field?  Ewan, we're talking
about the database schema behind the scenes in Glance, here, and
trying to determine the values that we validate when adding images to
the Glance registry and the field values for disk_format and
appliance_format...

> It would probably be best if you allowed arbitrary key-value pairs for metadata.  That way, we're free to figure out later which subtype info we need to collect.

We added this ability to Glance a while ago, and it's documented. Any
image can have an unlimited* number of custom key/value pairs attached
to it. Using the glance.client.Client.add_image() call, image_meta can
contain a mapping 'properties' that contains this set of key/value
pairs. The REST API allows x-image-meta-property-<KEY>=<VALUE> headers
to set these attributes as well. See the following documentation
pages:

http://glance.openstack.org/glanceapi.html#adding-a-new-virtual-machine-image
http://glance.openstack.org/client.html#adding-a-new-virtual-machine-image

Cheers!
jay