Heat/StackMetadata

This page outlines use cases for in-template Stack Metadata, as described by blueprint: https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata

Use Case 1 -- Categorization:

Allow template authors to categorize the template as a specific "type". e.g.

   template_metadata:
       short_description: Wordpress

As a UX developer of Horizon or any other client intended to help cloud users deploy best-practice community developed orchestration templates, we would like to present a list of templates organized by categories (e.g. likeness to other templates, amount of infrastructure resources required to deploy [e.g. single node server vs. multi-tier application], estimated cost [proprietary to cloud operator],

If this metadata were stored/organized solely at the API (or a secondary side service or API wrapper around Heat) it would have to be maintained as a 1-to-1 mapping to a template (in which case there is an implicit and explicit association).

Use Case 2:

As an Openstack Service Provider operator of a public cloud, we would like template author and template creation date portable so that this information goes wherever the template goes in a portable format that consumers (any client) of the Heat service can understand and make use of. We would also like this information to be available for a deployed stack in Heat, so it is more general metadata and need not be catalog specific. If author/creation-date information were only available in the catalog, then we would have to entirely wrap the Heat API in another service or risk drift in the data between Heat and the separate non-wrapping catalog service. Instead of raising a blueprint for every piece of data that may be useful to deploying the Heat service (some of which certain Heat operators may not care about, the in-template metadata is an approach allow experimentation. We could then drive back experiential use-cases into future improvements (e.g. in-language schema changes or catalog changes). As a specific example from running a nearly identical service, the data outlined in this use case in-template has proven to be a valid use case for consumers of an Orchestration service. Specific Example:

1. Cloud customer of service operator deploys a template (may or may not

have come from the catalog)

1. Customer encounters problem with the stack and calls support
2. Support specialist [not the service operator/developer] is trying to

figure out who to contact for additional help given failures seen with the stack. The dev team of the service is not the expert in application foo and did not develop the template. It's not a Heat issue, it's a template/application foo issue which requires the template (application/infrastructure architect) to get involved. Knowing who to contact for that template is paramount.

Use Case 3 -- Portability:

For the information in use cases 1 and 2, portability of the template from one Heat service to another, or from a template author to a cloud customer, is paramount, inclusive of the metadata. This allows devops, customer support specialists, customers, and other OpenStack developers to create and share Heat templates without having to have a centralized catalog or repository where metadata would be centralized across disparate organizations. In experience, authors of templates and consumers of templates often do not share access to a common repository where both parties have read/write permissions. Instead, templates are shared via read-only access to a repo. In order for someone to take a template for use in a differing Heat system, the template must be copied, in text/file form. This is common practice. A shared metadata service is not utilized and all that is exchanged is the template file(s). Therefore, it would be beneficial if all necessary metadata information for a template were embedded directly with the file(s). Sharing a single file is easier than sharing multiples, hence the use of formats like .zip. Template portability, in a simplistic form, will drive the largest adoption of Heat through ease of template creation with appropriate transport of associated metadata for cloud service operators.