Difference between revisions of "Heat/TemplateCatalog"
< Heat
Tim Schnell (talk | contribs) (initial catalog bones) |
Tim Schnell (talk | contribs) (→Use Cases) |
||
| Line 6: | Line 6: | ||
= Use Cases = | = Use Cases = | ||
# The Template Catalog is defined as a service that would allow for a consistent interface to both store and retrieve templates in a controlled way with a configurable backend. | # The Template Catalog is defined as a service that would allow for a consistent interface to both store and retrieve templates in a controlled way with a configurable backend. | ||
| − | # Planned Deployment: The Heat engine should be able to parse a template with inputs, and produce a response with the quantity and types of resources/entities that would be spun up if the deployment were created, but not actually create the deployment as part of the planning call. This allows upstream callers of the service to make a determination of what resources will be spun up for a given template without having to actually implement template parsing logic. An example use case for this would be for Horizon to show, for any given template + user selected inputs, how much compute, loadbalancer, trove, etc. resources would need to be consumed (good for (1) determining if capacity exists in those systems before spinning up the deployment; (2) a control panel could calculate customer pricing for a deployment). | + | # Planned Deployment: The Heat engine should be able to parse a template with inputs, and produce a response with the quantity and types of resources/entities that would be spun up if the deployment were created, but not actually create the deployment as part of the planning call. This allows upstream callers of the service to make a determination of what resources will be spun up for a given template without having to actually implement template parsing logic. An example use case for this would be for Horizon to show, for any given template + user selected inputs, how much compute, loadbalancer, trove, etc. resources would need to be consumed (good for (1) determining if capacity exists in those systems before spinning up the deployment; (2) a control panel could calculate customer pricing for a deployment). |
| − | + | # Along with the template, the catalog should return an optional absolute url to an icon that represents the purpose of the template (Wordpress icon). | |
| + | # The catalog should have a REST API endpoint to retrieve the version information about the template, (i.e. template version, authors, git SHA). | ||
| + | # The catalog should allow template tags to be created and queried via the REST API about each template, (i.e. tags: [wordpress, linux, mysql]). | ||
= Catalog API = | = Catalog API = | ||
Revision as of 22:07, 2 December 2013
Summary
This is a proposal for a service that manages Heat Templates in a user-friendly, portable Catalog. This proposal is tied to the following Heat blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
Use Cases
- The Template Catalog is defined as a service that would allow for a consistent interface to both store and retrieve templates in a controlled way with a configurable backend.
- Planned Deployment: The Heat engine should be able to parse a template with inputs, and produce a response with the quantity and types of resources/entities that would be spun up if the deployment were created, but not actually create the deployment as part of the planning call. This allows upstream callers of the service to make a determination of what resources will be spun up for a given template without having to actually implement template parsing logic. An example use case for this would be for Horizon to show, for any given template + user selected inputs, how much compute, loadbalancer, trove, etc. resources would need to be consumed (good for (1) determining if capacity exists in those systems before spinning up the deployment; (2) a control panel could calculate customer pricing for a deployment).
- Along with the template, the catalog should return an optional absolute url to an icon that represents the purpose of the template (Wordpress icon).
- The catalog should have a REST API endpoint to retrieve the version information about the template, (i.e. template version, authors, git SHA).
- The catalog should allow template tags to be created and queried via the REST API about each template, (i.e. tags: [wordpress, linux, mysql]).
