> From: Keith Bray <keith.b...@rackspace.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <sd...@redhat.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, April 3, 2014 10:30 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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.k...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Wednesday, April 2, 2014 9:31 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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 <mspre...@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@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: konglingx...@huawei.com; anlin.k...@gmail.com > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/ > mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev