Metadefs API

[josephineSei]

In Glance there exists the Metadef API, that can be used as a catalog to define definitions in metadata, that are not defined by OpenStack itself. It should be investigate, how standards may benefit from this, whether SCS want to use it at all or if we should not enforce it to be there at all due to:

https://wiki.openstack.org/wiki/OSSN/OSSN-0088

What metadefs are can be looked up here:
https://docs.openstack.org/glance/latest/user/metadefs-concepts.html

Definition of Done:

Please refer to scs-0001-v1 for details.

• Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• Proposal has the fields status, type, track set
• Proposal has been voted upon in the corresponding team
• Status has been changed into Draft, file renamed: xxxx replaced by document number
• If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[markus-hentsch]

Some research notes regarding the Metadefs API of Glance:

The Metadefs API is hosted by Glance yet it is not documented in Image Service API v2¹. Instead there is a dedicated "Metadata Definitions Service API v2"².

Purpose

The Metadefs API of Glance seems to act similar to XML Schema (XSD) definitions for the existing metadata functionalities of other APIs. Quote from the API reference² (highlights by me):

The Metadata Definitions Service (“metadefs”, for short) provides a common API for vendors, operators, administrators, services, and users to meaningfully define available key:value pairs that can be used on different types of cloud resources (for example, images, artifacts, volumes, flavors, aggregates, and other resources). […]
Note that this service stores only the catalog, because metadefs are meta-metadata. Metadefs provide information about resource metadata, but do not themselves serve as actual metadata.
Actual key:value pairs are stored on the resources to which they apply using the metadata facilities provided by the appropriate API. (For example, the Images API would be used to put specific key:value pairs on a virtual machine image.)

So essentially this API seems to allow to specify descriptions and constraints for keys/values of the existing (?) metadata functionalities of the other APIs (instance metadata in Nova API, volume metadata in Cinder API etc.).
As such it acts as a central catalog for interpreting arbitrary metadata of the other APIs.

(Im)mutability

The API reference² also includes an important note:

By default, only admins can manipulate the data exposed by this API, but all users may list and show public resources. This changed from a default of “open to all” in the Wallaby release.

(... which is most likely a result of OSSN-0088)

This means that only a CSP of an SCS cloud would actually be able to create and maintain such metadata definitions.
Should we decide to create a standard here, this is especially important because users will have no further influence and it would be entirely up to the standard to establish a baseline for reliability and quality of the information provided by the API.

Implications

Based on the above, I deduce the following:

• a CSP would have high responsibility for providing adequate metadata definitons since users cannot edit them, a standard could help here
• purely user-facing: the Metadefs API is just a lookup catalog for users, neither Glance nor the referenced service APIs seem to actually validate or process any of the information
  • it falls into a "nice to have" category but does not seem to serve any technical purpose in a normal OpenStack environment
  • for SCS it could be more on the relevant side though since some standards use metadata extensively
• should we decide to incorporate the Metadefs API in SCS: for any SCS standard that makes use of resource metadata to store SCS-related information this could be reflected in a Metadefs entry

We should discuss whether this is something useful/desired in relation to SCS standards which make use of metadata or if we should restrict/ignore it.

Resources

• OpenStack User Guide on how to use the Metadefs API
• Glance Documentation on the concepts of the Metadefs API

Footnotes

1. https://docs.openstack.org/api-ref/image/v2/ ↩

2. https://docs.openstack.org/api-ref/image/v2/metadefs-index.html ↩ ↩² ↩³

[berendt]

I think it could make sense if, for example, we add meta definitions of the additional meta information of images and flavors, which we have already standardized and use, here. Then, from an SCS perspective, the service would only be used for this purpose and the definitions themselves would not have to be standardized. Then we would already have a few good examples that could be used later for standardization.