Difference between revisions of "Graffiti/Directory"
< Graffiti
Travis Tripp (talk | contribs) (→Graffiti Directory) |
Travis Tripp (talk | contribs) (→Graffiti Directory) |
||
| Line 1: | Line 1: | ||
| − | == | + | == Resource Directory API == |
A common API to "tag" and search across existing and new services for cloud content based on the metadata vocabulary, ad-hoc properties, names, and descriptions. | A common API to "tag" and search across existing and new services for cloud content based on the metadata vocabulary, ad-hoc properties, names, and descriptions. | ||
| Line 14: | Line 14: | ||
=== Resources === | === Resources === | ||
| − | + | Basically, resources are a common way to represent a type of resource from a given provider. They have the following: | |
* Name | * Name | ||
* Description | * Description | ||
| Line 24: | Line 24: | ||
* Requirements (references to required capability types as well as the constraints) | * Requirements (references to required capability types as well as the constraints) | ||
| − | For example, a resource may be of type ''volume''. It may come from a specific Cinder endpoint registered in Keystone. It may have the capability of a certain kind of OS and may also have MySQL on it. | + | For example, a resource may be of resource type ''volume''. It may come from a specific Cinder endpoint registered in Keystone. It may have the capability of a certain kind of OS and may also have MySQL on it. |
Revision as of 04:53, 5 May 2014
Resource Directory API
A common API to "tag" and search across existing and new services for cloud content based on the metadata vocabulary, ad-hoc properties, names, and descriptions.
Expanded Contextual Overlay
Below is an overlay of Graffiti concepts with Graffiti components.
Resources
Basically, resources are a common way to represent a type of resource from a given provider. They have the following:
- Name
- Description
- Resource Type
- Resource Endpoint
- Freeform properties (those not associated with a known namespace in the dictionary)
- Flat properties (those associated with a namespace, but not a capability type in the namespace)
- Capabilities (instances of capability types)
- Requirements (references to required capability types as well as the constraints)
For example, a resource may be of resource type volume. It may come from a specific Cinder endpoint registered in Keystone. It may have the capability of a certain kind of OS and may also have MySQL on it.
