Graffiti/Dictionary

< Graffiti/Architecture

Dictionary API
A common API for services, admins, and users to discover and share their metadata vocabulary. This is the basis for creating an agreement on how to describe the various capabilities the cloud provides. The base idea is that it could support both unstructured properties and structured / hierarchical metadata in the form of "capability types". All definitions in the Dictionary would be "namespaced".

Expanded Contextual Overlay
This provides an overlay of Graffiti concepts with Graffiti components.



Challenges
We have found some interesting challenges with exposing metadata used by OpenStack today.


 * A property key is often set to a single generic term. It only makes sense within the context of services that collaborate on that property.  The generic term can collide when used in the context of other services.  The definition of what it means and the allowable values may be very different in different contexts.
 * For example, the property "architecture" is used to describe the CPU architecture that the compute host hypervisor must support. Nova compute scheduling is the service most concerned with handling this property, but the property is something that can be placed on images or bootable volumes (via the volume_image_metadata). If this property were applied to different types of resources, the term may not apply or may have a different meaning.


 * Different organizations or service providers may want to:
 * Restrict visibility to the property in the UI
 * Group similar properties
 * Provide alternative representations to their users.
 * Including localization strings to describe the property

Solution Concepts: Namespaces and Capability Types
A namespace:
 * Contains property definitions
 * Contains Capability Type Definitions (more later)
 * Is associated with the types of resources that it can be applied to
 * Can be made visible to different projects
 * Defines how its properties are translated to flat properties
 * E.g. Just put the property name or include additional qualifying information (like the namespace and capability type)



Properties
Individual properties definitions should be based on JSON Schema.

Capability Types
We think the term "metadata" is a somewhat unapproachable term, so we have been exploring with the concept of a "capability". A capability can simply be thought of as a named "tag" which may or may not have properties. The idea is that a user can simply "tag" a capability onto various cloud resources such as images, volumes, host aggregates, flavors, and so on. To the end user, the exact mechanism for how the data is stored is handled for them.

Sometimes the capability is used to describe something that a resource provides (for example, an image can provide "Apache" while resources like flavors or host aggregates can provide capabilities like GPU acceleration or a certain level of trust attestation). Similarly, a resource can specify capabilities that are required to use it, such as an image or bootable volume that requires a host capable of providing hardware level AES encryption support.

A Capability Type is the following:
 * A metadata schema that describes a type of capability a cloud resource may provide
 * e.g. “CENTOS” may be a type of capability


 * Defines the structure of observable properties
 * The names, data types and allowed values of properties (using JSON schema format)
 * e.g. The os_distro property is set to "centos"


 * Hierarchical
 * Can inherit properties from parent Capability Types
 * e.g. CENTOS is an Operating System and all operating systems have a property called os_version


 * Include properties
 * Define properties separately and reference them in 1 to many capability types
 * Graffiti will resolve the referenced properties and "flatten" them across multiple definition providers for easy consumption


 * Referenced by requirements
 * e.g. My application requires CENTOS


 * Scoped by a namespace
 * Uniquely named within a namespace
 * Your definition of "Classified" is not the same as mine, so we'll agree to disagree
 * RBAC is done on the namespace, not on individual types
 * Capability Types may derive from Types in other namespaces