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
