Looks like Pádraig and I were thinking alike. On Apr 7, 2012 8:49 PM, "Pádraig Brady" <p...@draigbrady.com> wrote:
> On 04/07/2012 11:13 PM, 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'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 <http://redhat.com>, ubuntu.com <http://ubuntu.com>, debian.org< > http://debian.org>, centos.org <http://centos.org> etc > > > > os:version_major would be the major version of the release: > > debian.org <http://debian.org>: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0 > > ubuntu.com <http://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 <http://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! > > > > This overlaps a lot with the output from the virt-inspector component of > libguestfs, > which might help solidify ideas: > > $ virt-inspector /var/lib/libvirt/images/rh63.img > > <operatingsystems> > <operatingsystem> > <root>/dev/VolGroup/lv_root</root> > <name>linux</name> > <arch>x86_64</arch> > <distro>rhel</distro> > <product_name>Red Hat Enterprise Linux Workstation release 6.3 Beta > (Santiago)</product_name> > <major_version>6</major_version> > <minor_version>3</minor_version> > <package_format>rpm</package_format> > <package_management>yum</package_management> > <hostname>localhost.localdomain</hostname> > <format>installed</format> > ... > <applications> > ... > <application> > <name>coreutils</name> > <version>8.4</version> > <release>18</release> > </application> > ... > > Note that it doesn't have an "updated_through" element, but that would be > fairly > amorphous anyway given the combinations possible through updates. > > cheers, > Pádraig. > > _______________________________________________ > 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
