Tim Schnell: /* Use Case 1 -- Catagorization: */

2013-11-26T15:08:24Z

‎Use Case 1 -- Catagorization:

Kebray: Created page with "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 -- ..."

2013-11-26T06:26:03Z

Created page with "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 -- ..."

New page

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 -- Catagorization: ==
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:
# Cloud customer of service operator deploys a template (may or may not
have come from the catalog)
# Customer encounters problem with the stack and calls support
# 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.

@@ Line 2: / Line 2: @@
 https://blueprints.launchpad.net/heat/+spec/namespace-stack-metadata
-== Use Case 1 -- Catagorization: ==
+== Use Case 1 -- Categorization: ==
 Allow template authors to categorize
 the template as a specific "type".  e.g.

Heat/StackMetadata - Revision history

Tim Schnell: /* Use Case 1 -- Catagorization: */

Kebray: Created page with "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 -- ..."