openstack team mailing list archive

[Pádraig Brady <P@xxxxxxxxxxxxxx>]

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.