Open Stack

Looks like Pádraig and I were thinking alike.
On Apr 7, 2012 8:49 PM, "Pádraig Brady" <P at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120407/77e8e7fb/attachment.html>