Difference between revisions of "Graffiti"
Travis Tripp (talk | contribs) m (→Initial use case) |
Travis Tripp (talk | contribs) |
||
| Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
| − | |||
| − | + | The intent of Graffiti is for OpenStack users to be able to declare the capabilities they require at a higher, more portable level than they do today. Graffiti helps guide or automate the selection of lower level cloud resources that match the desired capabilities. | |
| − | + | Many OpenStack services are great at providing somewhere to use metadata in terms of key-value pairs. However, collaborating on metadata is largely a disconnected and difficult process. This often involves searching outdated wikis and opening the source code. It becomes more difficult as a cloud's scale grows. | |
At its most basic concept Graffiti is a metadata collaboration tool. Many OpenStack services are great at providing various mechanisms to use metadata in terms of key-value pairs, but collaborating on the actual metadata between developers, admins, services, UI, and end users is largely a disconnected and difficult process that often involves searching outdated wikis, opening source code, and in the best cases making a lot of command line calls. This makes things hard on everybody. We want to make things easier. | At its most basic concept Graffiti is a metadata collaboration tool. Many OpenStack services are great at providing various mechanisms to use metadata in terms of key-value pairs, but collaborating on the actual metadata between developers, admins, services, UI, and end users is largely a disconnected and difficult process that often involves searching outdated wikis, opening source code, and in the best cases making a lot of command line calls. This makes things hard on everybody. We want to make things easier. | ||
=== Initial use case === | === Initial use case === | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==== Demo ==== | ==== Demo ==== | ||
| Line 25: | Line 15: | ||
Coming soon... | Coming soon... | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Get Involved == | == Get Involved == | ||
| − | |||
| − | |||
* [https://bugs.launchpad.net/graffiti Bug tracker] | * [https://bugs.launchpad.net/graffiti Bug tracker] | ||
* [https://blueprints.launchpad.net/graffiti Feature Tracker] | * [https://blueprints.launchpad.net/graffiti Feature Tracker] | ||
* [https://github.com/stackforge/graffiti Code Repository] | * [https://github.com/stackforge/graffiti Code Repository] | ||
Revision as of 01:04, 10 April 2014
Overview
The intent of Graffiti is for OpenStack users to be able to declare the capabilities they require at a higher, more portable level than they do today. Graffiti helps guide or automate the selection of lower level cloud resources that match the desired capabilities.
Many OpenStack services are great at providing somewhere to use metadata in terms of key-value pairs. However, collaborating on metadata is largely a disconnected and difficult process. This often involves searching outdated wikis and opening the source code. It becomes more difficult as a cloud's scale grows.
At its most basic concept Graffiti is a metadata collaboration tool. Many OpenStack services are great at providing various mechanisms to use metadata in terms of key-value pairs, but collaborating on the actual metadata between developers, admins, services, UI, and end users is largely a disconnected and difficult process that often involves searching outdated wikis, opening source code, and in the best cases making a lot of command line calls. This makes things hard on everybody. We want to make things easier.
Initial use case
Demo
Architecture
Coming soon...
