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:[email protected]] Sent: 17 January 2011 15:31 To: Ewan Mellor Cc: Diego Parrilla Santamaría; [email protected]; John Purrier Subject: Re: [Openstack] Glance x-image-meta-type raw vs machine 2011/1/17 Ewan Mellor <[email protected]>: > 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
