| 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
The etherpad from the summit: http://etherpad.openstack.org/FolsomCommonImageProperties
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:
- Agreeing a set of common image properties
- Agreeing a convention for shared system properties
Per discussion at the summit, a 'well known' image property should have a key that looks like this:
<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.
org.openstack__1__os_distro org.openstack__1__os_version org.openstack__1__updated_at org.openstack__1__packages org.openstack__1__architecture
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!
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.
- original email announcement: http://email@example.com/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
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
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.
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.