Graffiti/Architecture
< Graffiti
Revision as of 17:50, 18 April 2014 by Travis Tripp (talk | contribs) (→End to End Component Diagram)
Contents
Graffiti Architecture
Base Concepts
- OpenStack services are great at providing somewhere to use metadata in terms of key-value pairs, but collaborating on metadata is largely a disconnected and difficult process that often involves searching outdated wikis and opening the source code. It becomes more difficult as a cloud's scale grows in terms of the number of resources being managed and services being integrated. Graffiti makes this easier by creating the following concepts:
- Capabilities and Requirements: Graffiti embraces the idea that cloud resources may be described using capabilities and requirements, a concept influenced by some parts of OpenStack today as well as by industry specifications like OASIS TOSCA (Please note, Graffiti is NOT an orchestration engine, but potentially it could be used by an orchestration engine).
- Dictionary: A common place for services, admins, and users to expose their metadata vocabulary. This is the basis for creating an agreement on how to describe the various capabilities the cloud provides. It supports both unstructured and structured / hierarchical metadata in the form of "capability types".
- Directory: A common API to tag and search across existing and new services for cloud content based on the metadata vocabulary, ad-hoc properties, or freeform text.
- Resource Capability Directory: A persistent shared repository for services to publish information about cloud resources. This can optionally be used by services instead of or in addition to having their own local native storage to describe resources.
- OpenStack services are great at providing somewhere to use metadata in terms of key-value pairs, but collaborating on metadata is largely a disconnected and difficult process that often involves searching outdated wikis and opening the source code. It becomes more difficult as a cloud's scale grows in terms of the number of resources being managed and services being integrated. Graffiti makes this easier by creating the following concepts:
Component Diagrams
Top Level Component Diagram
End to End Horizon Architecture
