Jump to: navigation, search

Difference between revisions of "Graffiti/Architecture"

(Graffiti Architecture)
(Proposed Horizon Component Architecture)
Line 26: Line 26:
  
 
==== Proposed Horizon Component Architecture ====
 
==== Proposed Horizon Component Architecture ====
 +
 +
In our architecture, we will support Horizon gaining the value of Graffiti concepts through a thin API plugin layer without the Graffiti service.  This will provide benefits now, without requiring Graffiti to either be incubated or be adopted into other projects (which we are actively seeking input and advice).
 +
 +
The entire concept can be run in a lightweight way through a thin filesystem provider on the Horizon server that allows reading dictionary definition files directly from the filesystem. This would suffice for single node deployments or deployments that are managed through configuration management provider to ensure consistency of the definitions across Horizon nodes.
 +
 +
When the full Graffiti API service is available, the widgets don't change.  They still go to the Graffiti Horizon API, which then swaps the plugin to talk to the Graffiti service.  When the Graffiti service in integrated into the ecosystem the following additional benefits will be available:
 +
* Command line and REST API for cross service tagging / searching
 +
* External Persistence for multi-node / HA deployments
 +
* Resource look-up optimizations
 +
* Authoring - We will provide an authoring and administration UI for creating and managing namespaces, capability types, etc
  
 
[[File:Graffiti-Widgets.png]]
 
[[File:Graffiti-Widgets.png]]

Revision as of 01:06, 19 April 2014

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, it only assists in describing and locating existing resources in the cloud.).
      • 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.

Worklow / Component Concepts

  1. Load your capability vocabulary into the Graffiti dictionary or a supported dictionary provider
  2. "Tag" the resources in your cloud with your capabilities
  3. Let end users and admins find the resources with your capabilities


Graffiti-Architecture-ConceptOverlay.png

Proposed Horizon Widgets

In Graffiti, we are proposing reusable widgets that we will plug into Horizon. The widgets will provide the ability to "tag" capabilities and requirements on various resources. They will also be able to generate filter criteria that a Graffiti plugin service can use to filter resources.

CapabilitiesRequirementsWidget-Screenshot.PNG

Proposed Horizon Component Architecture

In our architecture, we will support Horizon gaining the value of Graffiti concepts through a thin API plugin layer without the Graffiti service. This will provide benefits now, without requiring Graffiti to either be incubated or be adopted into other projects (which we are actively seeking input and advice).

The entire concept can be run in a lightweight way through a thin filesystem provider on the Horizon server that allows reading dictionary definition files directly from the filesystem. This would suffice for single node deployments or deployments that are managed through configuration management provider to ensure consistency of the definitions across Horizon nodes.

When the full Graffiti API service is available, the widgets don't change. They still go to the Graffiti Horizon API, which then swaps the plugin to talk to the Graffiti service. When the Graffiti service in integrated into the ecosystem the following additional benefits will be available:

  • Command line and REST API for cross service tagging / searching
  • External Persistence for multi-node / HA deployments
  • Resource look-up optimizations
  • Authoring - We will provide an authoring and administration UI for creating and managing namespaces, capability types, etc

Graffiti-Widgets.png