On Thu, Apr 3, 2014 at 10:50 AM, Keith Bray <[email protected]>wrote:
> 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. > Yes, this is exactly the use case that has been driving our consideration of the artifacts resource in Glance. You mentioned discovery of compatible resources. I think its an important use case, but I think the export and import approach can also be very useful and I'd like to believe it is the general solution to cloud portability. > 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 <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Thursday, April 3, 2014 10:30 AM > > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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 <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Wednesday, April 2, 2014 9:31 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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 <[email protected]>: > >> 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 >> [email protected] >> 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: [email protected]; [email protected] > > > > _______________________________________________ > OpenStack-dev mailing > [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
