Open Stack

Steve, agreed.  Your description I believe is the conclusion that the community came to when this was perviously discussed, and we managed to get the implementation of parameter grouping and ordering [1] that you mentioned which has been very helpful.  I don't think we landed the keywords blueprint [2], which may be controversial because it is essentially unstructured. I wanted to make sure Mike had the links for historical context, but certainly understand and appreciate your point of view here.  I wasn't able to find the email threads to point Mike to, but assume they exist in the list archives somewhere.

We proposed another specific piece of template data [3] which I can't remember whether it was met with resistance or we just didn't get to implementing it since we knew we would have to store other data specific to our uses cases in other files anyway.   We decided to go with storing our extra information in a catalog (really just a Git repo with a README.MD [4]) for now  until we can implement acceptable catalog functionality somewhere like Glance, hopefully in the Juno cycle.  When we want to share the template, we share all the files in the repo (inclusive of the README.MD).  It would be more ideal if we could share a single file (package) inclusive of the template and corresponding help text and any other UI hint info that would helpful.  I expect service providers to have differing views of the extra data they want to store with a template... So it'd just be nice to have a way to account for service providers to store their unique data along with a template that is easy to share and is part of the template package.  We bring up portability and structured data often, but I'm starting to realize that portability of a template breaks down unless every service provider runs exactly the same Heat resources, same image IDs, flavor types, etc.). I'd like to drive more standardization of data for image and template data into Glance so that in HOT we can just declare things like "Linux, Flavor Ubuntu, latest LTS, minimum 1Gig" and automatically discover and choose the right image to provision, or error if a suitable match can not be found.  The Murano team has been hinting at wanting to solve a similar problem, but with a broader vision from a complex-multi application declaration perspective that crosses multiple templates or is a layer above just matching to what capabilities Heat resources provide and matching against capabilities that a catalog of templates provide (and mix that with capabilities the cloud API services provide).  I'm not yet convinced that can't be done with a parent Heat template since we already have the declarative constructs and language well defined, but I appreciate the use case and perspective those folks are bringing to the conversation.

[1] https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
 https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering

[2] https://blueprints.launchpad.net/heat/+spec/stack-keywords
https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords

[3] https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
https://wiki.openstack.org/wiki/Heat/UI#Help_Text

[4] Ex. Help Text accompanying a template in README.MD format:
https://github.com/rackspace-orchestration-templates/docker

-Keith

From: Steven Dake <sdake at redhat.com<mailto:sdake at redhat.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, April 3, 2014 10:30 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] metadata for a HOT

On 04/02/2014 08:41 PM, Keith Bray wrote:
https://wiki.openstack.org/wiki/Heat/StackMetadata

https://wiki.openstack.org/wiki/Heat/UI

-Keith

Keith,

Taking a look at the UI specification, I thought I'd take a look at adding parameter grouping and ordering to the hot_spec.rst file.  That seems like a really nice constrained use case with a clear way to validate that folks aren't adding magic to the template for their custom environments.  During that, I noticed it is is already implemented.

What is nice about this specific use case is it is something that can be validated by the parser.  For example, the parser could enforce that parameters in the parameter-groups section actually exist as parameters in the parameters section.  Essentially this particular use case *enforces* good heat template implementation without an opportunity for HOT template developers to jam customized data blobs into the template.

Stack keywords on the other hand doesn't necessarily follow this model.  I understand the use case, but it would be possible to jam unstructured metadata into the template.  That said, the limitations on the jamming custom metadata are one deep and it has a clear use case (categorization of templates for support/UI rendering purposes).

I could be wrong, but I think the aversion to a general metadata section is centered around the problem of different people doing different things in a non-standardized way.

I think if we were to revisit the metadata proposal, one thing that might lead to a more successful outcome is actually defining what goes in the metadata, rather then allowing the metadata to be completely free-form as the HOT developer sees fit to implement it.

For example just taking the keywords proposal:
metadata:
  composed_of:
  - wordpress
  - mysql
  architecture:
  - lamp

Even though this metadata can't necessarily be validated, it can be documented.  I definitely have a -2 aversion to free-form metadata structuring, and am +0 on allowing the information to be declared in a non-validated way.

I don't believe the idea of structured metadata based upon real use cases has really been explored or -2'ed.

Regards,
-steve

From: Lingxian Kong <anlin.kong at gmail.com<mailto:anlin.kong at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, April 2, 2014 9:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] metadata for a HOT

Is there any relevant wiki or specification doc?


2014-04-03 4:45 GMT+08:00 Mike Spreitzer <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>>:
I would like to suggest that a metadata section be allowed at the top level of a HOT.  Note that while resources in a stack can have metadata, there is no way to put metadata on a stack itself.  What do you think?

Thanks,
Mike
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
---------------------------------------
Lingxian Kong
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingxian at huawei.com<mailto:konglingxian at huawei.com>; anlin.kong at gmail.com<mailto:anlin.kong at gmail.com>



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/59cc32c3/attachment.html>