On Sat, 7 Apr 2012, Justin Santa Barbara wrote: > Is there a (de-facto) standard for image metadata/properties? I'd like to > be able to able to launch e.g. the Debian Squeeze image provided by the > cloud. This is particularly important for clouds that don't allow image > upload, but likely this will remain useful because different clouds will > have different tweaks needed (e.g installing the right drivers based on the > hypervisor). > > I could try "smart"-parsing the names, but it seems like metadata is the > right way to do this, and I see no reason why any cloud would gain any > advantage from not adopting a common convention. I know some clouds have > started implementing their own approaches, but I don't believe anyone is > locked into anything. > > In the interest of efficiency, I'm going to make a proposal for people to > attack: > > 3 main pieces of metadata: os:distro, os:version_major, os:version_minor
I generally disagree that these are the 3 main pieces of meta-data. It might seems strange that someone with a @distro.com address would say this, but I believe that "distro" is largely irrelevant. If I'm looking for a image to run, the thing that is most important to me is the provider of the image. In some clouds, with no public images, the owner of the image is quite likely the cloud provider, and I have little option other than to trust them on the contents of an image (I already trust them almost completely by launching an instance there). However, in a large public cloud (amazon for example) there are literally thousands of providers, and thousands that claim "Ubuntu", and "10.04", and would (justifiably) also upload package lists that contained a list like you suggested later in this thread. The problem is that I don't trust those image providers, I know nothing about them, and any metadata provided by them other than GPG signed data or well-known IDS is not going to change my lack of trust (ie, Canonical images on EC2 are owned by id 099720109477, redhat publishes under 432018295444 and 309956199498). The data you're after might be useful to you, and might scratch an itch. I will not discount that, but I would much prefer a bit of metadata associated with an image that was signed by an entity I trusted that identified the image as good. The ubuntu name strings look like this: ubuntu-oneiric-11.10-i386-server-20120401 If I see that string, and content signed by a key that I trust, then I can be assured that it is what I think it is. I may well trust 'cloud-provider-foowhiz's signature on that string, and not require it to be signed by an Ubuntu key. I may not. I may accept centos-6.04-i386-server-20120401 signed by centos.org key to be a replacement for rhel-6.04-i386-server-20120401 What i'm getting at, is that I think vendor is more important than os in the long run (and even the short run). OS distro, version_major, version_minor are even less important where you don't care (or know) that your OS came from Canonical or RedHat, what you were really interested in is running "WhizBang! Fooberator" version 2.0. One feature thing I think glance could (and probably does provide me with) is md5/sha1 sums of the images that were uploaded. If I know that an image I'm about to run has md5sum that matches that of a published image on http://cloud-images.ubuntu.com then I'm more willing to trust it (given that I already trust the cloud provider). I guess if Canonical provided a signed sum of: ubuntu-oneiric-11.10-i386-server-20120401:md5sum Then the cloud uploader could just upload the existing Canonical sum as a tag on that image, and then my signature checking would work also. I trust the cloud provider out of necessity, and I trust Canonical, so the 2 things work out. So, I guess in summary, * I don't think os:version and the like are encompassing or particularly useful by themselves. * I can't trust tagged data by itself * I wouldn't trust any scraping of package contents by libguestfs, as it can most certainly be fooled or broken. I can see that some tagged info on the contents of the image would be useful for certain things, but specifically OS specific information is just not that important. The vast, *vast* majority of us don't care that e2fsprogs is in the Ubuntu image, or that it is version 1.4.1-0ubuntu1. I personally hope that I've done a good job of making them more interested in the fact that it is an Ubuntu cloud image. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
