Revision as of 19:53, 17 April 2013

Heat Template Repository (Heater)

Heat Template Repository (Heater) is a service for the storage, management, and versioning of "known good" templates. Its goal is to allow an organization to encode and then easily share architectural knowledge via a library of templates.. Envisioned features include indexing, tagging and search, versioning, configurable back-end storage, and extended metadata composition.

Heater's primary function is as a centralized template library. It should be installable and manageable outside of any particular OpenStack enclave and have no affinity for any one installation of Heat. Many different organizations should be able to easily stand up Heater and define their own policies around publishing and storage.

Authentication/Access control

Handled via Keystone as usual

API

(Spec forthcoming - just a basic overview of the possible endpoints/operations)

• Submit a template and optional metadata and tags

POST /templates
{
    template: { ... raw template here ...},
    meta: {
        documentation: "A compelling, accurate and enlightening explanation",
        horizon: {
                layout: { ... very complex layout format understood only by horizon ... },
                catagory: "Cool stuff",
                icons: {
                     small: ... some remote reference or embedded binary data ...
                }
        }
    },
    tags: ["foo", "bar", "baz"]
}

• Retrieve a version of a template (Published version by default, with/without metadata)

GET /templates/:id?meta=horizon&meta=documentation&version=b6059

• View a template version history

GET /teplates/:id/history
{
    current: b6059,
    b6059: {
        version: b6059,
        submitted: ... a date ...
        ref: ... resource uri to the actual version details ....,
    },
    985a4: {
        version: 985a4,
        submitted: ... a date ....
        ref: ...resource uri to the actual version details ....
    }
}

GET /templates/:id/history/:rev
{
    version: ref,
    submitted: .. a date ..
    comment: "A description of the change/difference"
    published: Not present if not published, otherwise the publish date
   
}

• Publish a template version version as LKG (admin)
• Reject a template version (admin)
• Add metadata to an existing template version
• Promote metadata to the LKG version of the template (admin)
• add/remove tags from a template

Associated metadata

Users should be able to associate metadata with a template to facilitate integration with other tooling like Horizon. This metadata will be kept separate from the raw template so as to ensure that a templates usefulness isn't deluded by the requirements of any given tool. The user should always be able to retrieve a template without the associated metadata. This service should, however, allow the user to retrieve a template "package" that includes the template as well as its metadata (or sub-set thereof). Examples of some types of metadata include:

• Hints for displaying template resources in a GUI (positioning, size, etc)
• Associative icons
• Documentation extensions
• Alternative versions
• Changelogs

Versioning and Publishing

Heater should support a very simple (and optional) publishing model in which designated users may review revisions of a template as well as metadata and publish it as the "official" or Last Known Good (LKG) version of the template. It is desired that this publishing model be kept very simple and avoid complex review workflow. When a template is requested, it is this published version that is returned unless a specific version is requested.

Storage Backend

The storage backend for Heater should be configurable, but support basic CRUD as well as versioning. Possible reference implementations would include Git and Swift.

Initial Implementation

Some work on a similar service has already been done at Rackspace as a POC. While the general storage, versioning, publishing, and metadata concepts are there, the current software needs to be brought up to OpenStack standards WRT api implementation, code formatting, and authentication. It also lacks configurability of the data store and tagging, however, the existing code can be brought in line with this spec with very little effort.

Heater is NOT:

• a proxy to Heat
• a complete CMS for templates
• a template design tool
• designed for one and only one consumer use case