CommonImageProperties

This feature has been implemented in Grizzly by: https://blueprints.launchpad.net/glance/+spec/glance-common-image-properties The feature as implemented differs from the proposal here.

= 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
 * 2) 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:

Formally:

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.

The version number allows for evolution of the definitions of these properties.

Common Image Properties
The goal is to choose between images, but not to have a totally strict definition of what an image contains.

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

The properties

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

org.openstack 1 os_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!

e.g. org.openstack__1__distro=org.debian

org.openstack 1 os_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.0rc2, 7.0beta20120401

e.g. org.openstack__1__distro=6.0.4

org.openstack 1 updated_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 package 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.openstack 1 packages
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.

e.g. org.openstack__1__packages=apache2,mysql,python

org.openstack 1 architecture
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.

e.g. org.openstack__1__architecture=x64