CIM Namespace Metadata¶
The OpenStack Kilo release introduced support for defining metadata definitions and associating the same with different resource types. To make workloads interoperable across OpenStack clouds, it is necessary to adopt a common set of metadata, particularly for hardware architecture, instruction sets, and their extensions. The Common Information Model(CIM)[A] and the Distributed Management Task Force (DMTF) have defined a pretty exhaustive list. We propose including the same into OpenStack.
A standard well known set of metadata tags are useful in describing cloud resources such as images, flavors, compute nodes and more in the interest of making orchestration across clouds interoperable. This is yet another step in our cloud federation story.
I have a workload running on OpenStack cloud-A and would like it to run no differently on OpenStack cloud-B. Flavors that specify the properties using a common standard set of descriptors will enable this.
A Network Virtual Function vendor would like to provide an appliance with metadata that different clouds can be expected to provide the same level of performance, to meet its typically stringent latency needs. Several vendors use the Open Virtualization Format (OVF) to package their appliances, which uses the CIM format, a DMTF standard.
We would like to introduce the CIM namespace for metadata in OpenStack to foster cloud interoperability.
The CIM schema files for processor, resources, virtualization, and storage [C - F] shall be parsed and json files added to the Glance etc/metadefs directory. The tool to parse shall also be added in the glance code base to facilitate gathering updates to the schema files in future OpenStack releases should there be any, though this is expected to be few and far between.
The Instruction set extensions shall ignore the enabled/disabled item. The reasoning here is that other than virtualization related instructions, namely VT-d, VT-x, few instruction extensions are disabled after the cloud provider expended money on buying the latest platforms.
In this incarnation of the solution, we shall not introduce semantics such as relationships between the various metadata tags. For instance, while describing hardware, a compute host that belongs to a certain processor architecture can only manifest instructions available in the same.
In this release we shall ignore the version of the CIM schema files. The expectation is that they will add elements, not remove elements, nor change the type of element values. We already have support in Glance to upload, overwrite, and merge metadata definitions [K]. This shall come in handy when a new CIM version of tags is introduced. We could add an API call that indicates the CIM version number supported for each of the CIM metadata definition files.
Manually create in each cloud the CIM namespace metadata using the metadata add API, a tedious error prone task that must be replicated in each and every OpenStack cloud instance.
Data model impact¶
The introduction of additional json files in the Glance etc/metadefs directories generated from parsing the CIM schema files for [C], [D], [E], and [F].
Other end user impact¶
Ease of use. The Horizon metadata for CIM namespace would look like the images captured in [G], [H], [I], and [J] for processor related CIM namespace elements. Goodness of elastic search is available via Searchlight APIs.
Other deployer impact¶
- Primary assignee:
Lin Yang (lin-a-yang)
- Other contributors:
Core reviewer(s): * Flavio Percoco * Ian Cordasco * Nikhil Komawar
Zhi Yan Liu
CIM schema to json file
Tests to confirm our parsing is valid
Tests to confirm the metadata has been uploaded correctly in OpenStack
Need to add documentation stating that the CIM namespace is being introduced.