2011/1/16 Diego Parrilla Santamaría <[email protected]>: > 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
