Heat Template Respository (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.
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
- Started by
- Completed by
- Angus Salkeld
Related branches
Related bugs
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:/
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:/
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.
