My 2 cents... We need to define a transport-neutral specification that allows us to encapsulate and copy/move a variety of virtual image formats, this should be based on OVF. The envelope can contain both the actual image as well as any required meta-data.
The image elements specified are very AMI specific, we should generalize to be able to indicate the type of virtual image (i.e. AMI, VHD, etc.). A test for POC can be a service that takes the data in the OVF or what is stored in Glance to convert between formats. If we do this correctly all of the required data will be available at the correct point in the flow. Don't know if this is directly applicable to the discussion point below, but it is important that we get the fundamental design/architecture concepts in place moving forward. John -----Original Message----- From: openstack-bounces+john=openstack....@lists.launchpad.net [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Monday, January 10, 2011 9:44 AM To: Ewan Mellor Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Glance x-image-meta-type raw vs machine On Sat, Jan 1, 2011 at 7:30 PM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote: > What is the intended semantics of the Glance x-image-meta-type header values > “raw” vs “machine”? When we pulled the Image model from Nova into Glance, there was a field "image_type" that was limited to the strings "raw", "machine", "kernel", and "ramdisk". I'm open to changing this or using something like a "format" field (AMI vs OVF, etc..) Thoughts? -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
