Better yet why not add support in Glance for automatically determining those things (distro, versions, etc)[1]. That way you don't have to rely on people doing the right thing.
Nate References: [1] - http://libguestfs.org/virt-inspector.1.html#getting_inspection_data_from_the_libguestfs_api On Apr 7, 2012 8:19 PM, "Justin Santa Barbara" <jus...@fathomdb.com> wrote: > I'm talking here about publicly accessible attributes of images, that the > image owner would set, so that API callers could select the right image > with which to launch their instances. > > e.g. I'm trying to launch a Zookeeper cluster made up of 5 instances on 5 > different clouds; how can I figure out which image is "Debian Squeeze" on > each of AT&T, Rackspace, HP, IBM, Internap, Dreamhost etc. I could code > image ids or logic for each of the clouds, but that's already annoying with > a handful of clouds and impractical with 100. Now imagine also that the > images are being re-spun each week! > > There's no protection against the image uploader setting the wrong values, > so the API user would definitely only want images from trusted providers. > Is there an easy way to differentiate publicly shared images from > 'official' cloud images? > > I don't believe these attributes would be suitable for billing purposes. > You could make it so that certain attributes can't be changed by the user > (e.g. billing codes), or that some values are system assigned (e.g. "this > is an official image"), but I think that's a future conversation / future > Glance feature. > > I'm just thinking this set of attributes would be a win for everyone vs. > each cloud rolling their own, so we can just agree them without any need > for code! > > Justin > > > On Sat, Apr 7, 2012 at 3:43 PM, Jamey Meredith < > jamey.mered...@rackspace.com> wrote: > >> So would these accessible via a system admin API only? The problem we >> face as a >> Public cloud is that we need to know things about an image for billing >> purposes. If a user can snapshot one of my windows images and change the >> distro field to Debian to avoid license fees, that wont work for us. I >> need to know the distro that this image was originally based upon. >> >> I also need to denote things like managed service level for an image >> that might be the same base distro as an unmanaged image. >> >> Sent from my iPhone >> >> On Apr 7, 2012, at 5:14 PM, "Justin Santa Barbara" <jus...@fathomdb.com> >> 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'm thinking of the os prefix as standing for OpenStack, not Operating >> System. I'd like to 'reserve' the os prefix for 'agreed' prefixes. Maybe >> this should be openstack.org:distro ? >> >> os:distro would be the primary domain name of the distro, i.e. redhat.com, >> ubuntu.com, debian.org, centos.org etc >> >> os:version_major would be the major version of the release: >> debian.org: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0 >> ubuntu.com: 10.04, 10.10, 11.04, 11.10, 12.04 >> >> Numbers seem more machine-friendly than codenames - 6.0, not squeeze - >> humans will probably use the image names. >> >> os:version_minor would be the minor version of the release (because it's >> a minor revision, hopefully we shouldn't normally have to check this, >> although we might want to select the latest always). >> >> So os:distro="debian.org" os:version_major "6.0" os:version_minor "3" >> would be an image of debian 6.0.3. >> >> Questions / ideas for other properties: >> >> - Some clouds will automatically respin images e.g. weekly with the >> latest updates. This could also be exposed through metadata. >> os:updated_through= "20120301" ? >> - Some clouds will offer only bare images, some will provide a >> variety e.g. bare, LAMP, Hadoop, etc. Should we use the native package >> names to indicate additional packages? e.g. >> os:packages="apache2,mysql,php5" ? >> >> As a (programmatic) consumer of these images, my wishlist: >> >> - A cloud will have to put on whatever drivers / agents they need to, >> but ideally these should otherwise be clean images, with minimal deviation >> from the stock install. (Or 'clean' images should be available alongside >> other images) It would be great if I could be launch a 'clean' image on >> any OpenStack cloud and have it behave more or less the same; I shouldn't >> have to second guess any additional tweaks. >> - I would like to be able to launch the clean image and install >> updates myself, in case I don't want a particular update. Providing a >> fast >> apt cache is much better than providing respun images, for my use-case. I >> would be great if old images stuck around, therefore! >> >> >> Justin >> >> --- >> >> Justin Santa Barbara >> Founder, FathomDB >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
