Jump to: navigation, search

CommonImageProperties

Warning.svg Old Design Page

This page was used to help design a feature that has been implemented. As a result, this page is unlikely to be updated and could contain outdated information. It was last updated on 2013-12-12

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:

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.

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.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!


e.g. org.openstack__1__distro=org.debian



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.

(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.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 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.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.


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



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.


e.g. org.openstack__1__architecture=x64