Heat Template Respository (Heater)

Registered by Randall Burt on 2013-04-17

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.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Angus Salkeld on 2015-02-03

Related branches

Sprints

Whiteboard

shardy: IMO we don't need to reinvent revision control as a heat-provided service. I propose that we just create a heat-templates stackforge repo, where we can maintain a repository of example/shared templates, then users can just use git

randall: The goal isn't revision control per-se and this is supposed to have a pluggable back-end that can/would certainly be git-based. This came out of the Horizon integration discussions and a need to have a catalog service to list available templates (think Glance for HOT). This could certainly be done with git calls in the short term, but the need for a more robust and storage agnostic service was discussed as a possibility. Since we've done some internal work on a similar service, we decided to codify the proposal here.

aotto: See also: https://blueprints.launchpad.net/heat/+spec/hot-repo

sbaker: swift supports versioned objects, it might make the best default backend
    kfox1111: an application may be made of a set of templates. swift versioning may
    be a problem in that case.

edmund (30OCT2013): Something new that may tie into this work: https://wiki.openstack.org/wiki/Murano/ApplicationCatalog.

randall: @edmund correct me if I'm wrong, but that bp looks more like SaaS on Openstack rather than a general template catalog. If that's the case, these may be complimentary, but not necessarily congruent.

paulnelson: from the internal project Randall mentioned, the primary use case was to allow a template revision to be tagged as "stable" so that continued improvements could be made and rolled out when the author felt it was ready by moving the "stable" tag to a newer revision. I think of this as a collection of curated and continually improved templates.

kfox1111: having yum repo.d like, multiple sources in the catalog would be important.

(?)

Work Items