openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Sat, Apr 7, 2012 at 6:13 PM, Justin Santa Barbara <justin@xxxxxxxxxxxx>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 would never have guessed that from the context. Why OpenStack instead of
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.
>

Are the major and minor numbers going to be sufficient versioning
information? See for example PEP 386 for more detailed version strings (
http://www.python.org/dev/peps/pep-0386/).


>
> 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" ?
>
> The package names may vary depending on the platform, so the names
probably shouldn't be tied to the names of the packages themselves but to
the projects. Or maybe that's just a taxonomy problem that should be left
up to the taggers.


>
>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>