Revision as of 19:56, 25 April 2012

Common Image Properties

Links

The blueprint: https://blueprints.launchpad.net/nova/+spec/common-image-properties The etherpad from the summit: http://etherpad.openstack.org/FolsomCommonImageProperties

Summary

When an image is uploaded into glance, it is important to API callers such as PlatformLayer to know what an image contains. e.g. This is a Debian Squeeze image.

This blueprint addresses:

1. Agreeing a set of common image properties 1. Agreeing a convention for shared system properties

The convention

Per discussion at the summit, a 'well known' image property should have a key that looks like this:

org.openstack<u>1</u>myproperty

Formally:

<Registered domain name of defining body, "reversed"><u><spec version></u><key name>

We use double underscores to try to avoid any possible collision with user properties. (Note that we can't currently use colons with glance properties)

These properties are stored as 'extension' properties in glance.

Organizations are free to define their own sub-names, as long as they control the top-level name.

Thus, as Canonical controls ubuntu.com, they can use: com.ubuntu.private, com.ubuntu.public and com.ubuntu

Organizations defining properties that may be useful generally are encouraged to post to the mailing list, so that these properties can be agreed and live under org.openstack where possible.

Common Image Properties

The goal is to choose between images, rather than to have a totally strict definition of what an image is.

A non-goal is to support any verification security; we assume that the image and the metadata is already trusted.

org.openstack__1__os_distro
org.openstack__1__os_version
org.openstack__1__updated_at
org.openstack__1__packages
org.openstack__1__architecture

org.openstack1os_distro

The distro

Example values: org.debian | com.ubuntu | com.redhat | org.centos

Again, the domain name in reversed order. If an organization produces multiple distros, they may use child domain names (e.g. com.ubuntu.daily vs com.ubuntu.releases, or com.redhat.enterprise vs com.redhat.consumer).

Note that everything is scoped from here; so the 'meaning' of os_version depends on the value of os_distro; same with packages etc.

For Windows, use com.microsoft.server and com.microsoft.desktop

For virtual appliances that are intended to be black boxes and the OS is irrelevant, use the domain name of the appliance (com.riverbed.fastwan). Or simply do not specify this metadata!

org.openstack1os_version

The version of the operating system

We should follow the convention coming out of the python packaging group. That puts the whole version in one property.

• http://www.python.org/dev/peps/pep-0386/
• original email announcement: http://www.mail-archive.com/distutils-sig@python.org/msg10435.html

(This is a change from my earlier suggestion, where major and minor were split)

For Debian, this might look like 6.0.4, 6.0.3 etc For Ubuntu, this might look like: 10.04, 10.10, 11.04, 11.10, 12.04

For a betas, follow the Python convention, e.g. 7.0beta1, 7.00rc2, 7.0beta20120401

org.openstack1updated_at

Date of update with fresh packages

If clouds respin images with updates e.g. weekly, this property would differentiate between each week's image.

This does not specify exactly which versions are present (although we can have a pretty good guess), but it instead serves to differentiate between images.

If the image does not contain updates, simply omit this property.

Use ISO 8601 format.

e.g. org.openstack__1__updated_at=20120411
e.g. org.openstack__1__updated_at=20120411T14:30Z

org.openstack1packages

Extra packages installed

If there are multiple packages, one "bare" and one on which you've installed LAMP, this is how you can differentiate the two images.

Again, this is scoped by distro (we are not trying to solve the cross-distro package naming issues)

The exact meaning here will really depend on the cloud; we are simply trying to differentiate images.

As a recommendation, if you run "apt-get install apache2 mysql python" to add the extra packages, then this should be "apache2, mysql, python". Although, there are more packages installed, but this is good enough for telling the 'bare' image from the 'LAMP' image.

If the image does not contain extra packages, simply omit this property.

This property is only needed if you're exposing multiple images that are otherwise identical, with different packages.

org.openstack1architecture

The architecture, as defined by the distro

If the same distro is available for more than one architecture (say, x86, AMD64, Power and ARM) this would differentiate the images.

Suggested values: x86, x64, arm, powerpc

By using the suggested values, we can compare across distros.

This property is only needed if you're exposing multiple images with different architectures.