Jump to: navigation, search


< Graffiti
Revision as of 23:56, 24 March 2014 by Travis Tripp (talk | contribs) (Initial Draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

What is Graffiti?

  • Graffiti allow users and services to better collaborate on metadata.
    • 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. Graffiti makes this easier by creating three concepts:
      • The Dictionary: A common place for for services and users to expose their metadata vocabulary. Metadata definitions can be flat or hierarchical.
      • The Directory: A common API to tag and search across existing and new services for cloud content based on the metadata vocabulary.
      • The Resource Metadata Repository: A shared metadata repository for services to publish information about cloud resources. Can optionally be used by services instead of or in addition to their local native storage.

Can you give me some examples of how Graffiti may be used?

  • You can easily create a marketplace like experience for images and launching instances using Graffiti.
    • For example, with Amazon you can categorize images into a hierarchy of application categories like Business Software or Developer Tools. Each of those can have sub categories. With Graffiti, an admin can create this kind of hierarchy. So, when the images are uploaded, users can simply tag the image with the appropriate categories from Graffiti (Graffiti flattens the tag to match the name / value pair format in Glance). Later, when an instance is launched or images are browsed, the Graffiti API can be used to display / filter the available application category hierarchy. When a user selects a category, the Graffiti API automatically searches Glance for the correct images.
    • In addition, with Graffiti, you can differentiate whether the image requires something or provides something. So, when you tag an image in Glance, you can specify that it requires a certain amount of CPU or a certain host capability (like a GPU) and then Graffiti can be used to automatically find flavors that provide the desired capabilities.

  • Similar to images, you could use the Graffiti dictionary to supplement application catalogs that do more than just images.
    • Since the definitions of the application categories is a set of common metadata stored in the dictionary, the process of defining application categories can be leveraged / reused to tag applications in a catalog of Heat templates or any other kind of advanced application orchestration catalog.

  • OpenStack provisioning tools like Fuel can be enhanced to store host information in the Graffiti resource reposotory so that other services can leverage the information.
    • Today, Fuel captures OpenStack host information that could be shared in a central repository, making it available to other services. The discovered information about the hosts could be stored as metadata about the hosts. Other services, such as Intel's Trust Execution Technology or Intel's Service Assurance Administrator could leverage this repository and publish additional static and runtime metadata about the hosts. For example, a compute host could be published into the repository. It then could be tagged with having TXT capabilities. The actual status of being trusted could be updated directly in the resource repository. Then downstream scheduling activities and filters could directly use the metadata in the shared repository to help make decisions.

  • Create redistributable application packages without relying on manual mappings.
    • Graffiti's central notion is that when you create metadata, it is a type of capability. You then tag those capabilities on different resources and specify either whether the resource provides the capability or if it requires the capability. For example, an orchestration template may provide a software configuration that configures Wordpress to connect to a MySQL 5.6 host and a software configuration that opens up the permissions for a MySQL 5.6 host to allow the wordpress server to connect to it. Both of these templates could "require" the software (Wordpress and MySQL) to pre-exist (rather than deploy it live). If when the orchestration template was loaded into the system, it could be queried to see what it requires and then provide the list of images that provide the desired "baked in software".
    • The key is giving users, admins, and template designers a vocabulary to describe their resources so they can connect them using the concepts of requirements and capabilities.

Do we all have to agree on the same metadata vocabulary?

  • No, since it is difficult, if not impossible, to achieve a single agreed upon vocabulary, Graffiti supports a separation of vocabularies using namespaces and RBAC.
    • Effectively, you can load a vocabulary into a namespace. Any terms / hierarchy / etc in that namespace is treated distinctly from the same terms / hierarchy / etc in other namespaces. We then allow specifying role permissions on visbility and modification of the namespace. We support user, project, and cloud level namespace visibility and editting privileges. So, a single user can have their own namespace that is distinct from a namespace visible to the world. We have created various suggested namespaces with capabilities for people to get started. We also think it makes sense to start formalizing some of them so that every OpenStack deployment will have a standard set of namespaces. And finally, we intend to provide a mapping of existing standards into Graffiti dictionary namespaces.