Difference between revisions of "CommonImageProperties"
m |
|||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | {{ImplementedFeature}} | |
+ | 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 = | = Common Image Properties = | ||
Line 5: | Line 8: | ||
The blueprint: https://blueprints.launchpad.net/nova/+spec/common-image-properties | The blueprint: https://blueprints.launchpad.net/nova/+spec/common-image-properties | ||
+ | |||
The etherpad from the summit: http://etherpad.openstack.org/FolsomCommonImageProperties | The etherpad from the summit: http://etherpad.openstack.org/FolsomCommonImageProperties | ||
Line 14: | Line 18: | ||
This blueprint addresses: | This blueprint addresses: | ||
− | + | # Agreeing a set of common image properties | |
− | + | # Agreeing a convention for shared system properties | |
== The convention == | == The convention == | ||
Line 37: | Line 41: | ||
Organizations defining properties that may be useful generally are encouraged to post to the mailing list, | 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. | 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 == | == Common Image Properties == | ||
− | The goal is to choose between images, | + | 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 security; we assume that the image and the metadata is already trusted. | + | A non-goal is to support any verification or security; we assume that the image and the metadata is already trusted. |
+ | '''The properties''' | ||
<pre><nowiki> | <pre><nowiki> | ||
Line 54: | Line 61: | ||
− | === org.openstack<u>1</u>os_distro === | + | ---- |
+ | |||
+ | === org.openstack<u>1</u>os_distro === | ||
'''The distro''' | '''The distro''' | ||
Line 69: | Line 78: | ||
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! | 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! | ||
+ | |||
+ | |||
+ | <pre><nowiki> | ||
+ | e.g. org.openstack__1__distro=org.debian | ||
+ | </nowiki></pre> | ||
+ | |||
+ | |||
+ | ---- | ||
=== org.openstack<u>1</u>os_version === | === org.openstack<u>1</u>os_version === | ||
Line 83: | Line 100: | ||
For Ubuntu, this might look like: 10.04, 10.10, 11.04, 11.10, 12.04 | 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. | + | For a betas, follow the Python convention, e.g. 7.0beta1, 7.0rc2, 7.0beta20120401 |
+ | |||
+ | |||
+ | <pre><nowiki> | ||
+ | e.g. org.openstack__1__distro=6.0.4 | ||
+ | </nowiki></pre> | ||
+ | |||
+ | |||
+ | ---- | ||
=== org.openstack<u>1</u>updated_at === | === org.openstack<u>1</u>updated_at === | ||
Line 91: | Line 116: | ||
If clouds respin images with updates e.g. weekly, this property would differentiate between each week's image. | 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. | + | 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. | If the image does not contain updates, simply omit this property. | ||
Line 103: | Line 128: | ||
</nowiki></pre> | </nowiki></pre> | ||
+ | |||
+ | ---- | ||
=== org.openstack<u>1</u>packages === | === org.openstack<u>1</u>packages === | ||
Line 114: | Line 141: | ||
The exact meaning here will really depend on the cloud; we are simply trying to differentiate images. | 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 | + | 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. | telling the 'bare' image from the 'LAMP' image. | ||
Line 120: | Line 147: | ||
This property is only needed if you're exposing multiple images that are otherwise identical, with different packages. | This property is only needed if you're exposing multiple images that are otherwise identical, with different packages. | ||
+ | |||
+ | |||
+ | <pre><nowiki> | ||
+ | e.g. org.openstack__1__packages=apache2,mysql,python | ||
+ | </nowiki></pre> | ||
+ | |||
+ | |||
+ | ---- | ||
=== org.openstack<u>1</u>architecture === | === org.openstack<u>1</u>architecture === | ||
Line 132: | Line 167: | ||
This property is only needed if you're exposing multiple images with different architectures. | This property is only needed if you're exposing multiple images with different architectures. | ||
+ | |||
+ | |||
+ | <pre><nowiki> | ||
+ | e.g. org.openstack__1__architecture=x64 | ||
+ | </nowiki></pre> |
Latest revision as of 14:16, 12 December 2013
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.
Contents
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:
- Agreeing a set of common image properties
- 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.
- 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.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