Open Stack

> From: Keith Bray <keith.bray at RACKSPACE.COM>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 03/04/2014 19:51
> Subject: Re: [openstack-dev] [heat] metadata for a HOT
>
> 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

I agree that packaging all stuff that makes up a template (which will in
many cases not be a single template file, but nested templates,
environments, scripts, ...) in one archive. We have this concept in TOSCA
and I am sure we will have to implement a solution for this as part of the
TOSCA YAML to HOT converter work that we started. If several people see
this requirement, let's see if we can join forces on a common solution.

> 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

Sahdev from our team recently created a BP for exactly that scenario.
Please have a look and see if that is in line with your thinking and
provide comments as necessary:

https://blueprints.launchpad.net/heat/+spec/constraint-based-flavors-and-images

> 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>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<
> 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>
> 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>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<
> 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>
> 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>:
> 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
> 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; anlin.kong at gmail.com
>

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