<div dir="ltr"><div class="gmail_extra"><font face="Calibri, sans-serif"><span style="font-size:14px"><br></span></font><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 10:50 AM, Keith Bray <span dir="ltr"><<a href="mailto:keith.bray@rackspace.com" target="_blank">keith.bray@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="font-size:14px;word-wrap:break-word">
<div style="font-family:Calibri,sans-serif">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. </div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">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 <a href="http://README.MD" target="_blank">README.MD</a> [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 <a href="http://README.MD" target="_blank">README.MD</a>). 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. </div></div></blockquote><div><br></div><div>Yes, this is exactly the use case that has been driving our consideration of the artifacts resource in Glance.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;word-wrap:break-word">
<div style="font-family:Calibri,sans-serif"> 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.</div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">[1] <a href="https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering" target="_blank">https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering</a></div>
<div style="font-family:Calibri,sans-serif"><u> </u><a href="https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering" style="font-size:medium;font-family:Consolas" target="_blank">https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering</a></div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">[2] <a href="https://blueprints.launchpad.net/heat/+spec/stack-keywords" style="font-size:medium;font-family:Consolas" target="_blank">https://blueprints.launchpad.net/heat/+spec/stack-keywords</a></div>
<div><a href="https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords" style="font-family:Consolas;font-size:medium" target="_blank">https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords</a></div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">[3] <a href="https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template" target="_blank">https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template</a></div>
<div style="font-family:Calibri,sans-serif"><a href="https://wiki.openstack.org/wiki/Heat/UI#Help_Text" style="font-family:Consolas;font-size:medium" target="_blank">https://wiki.openstack.org/wiki/Heat/UI#Help_Text</a></div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">[4] Ex. Help Text accompanying a template in <a href="http://README.MD" target="_blank">README.MD</a> format:</div>
<div style="font-family:Calibri,sans-serif"><a href="https://github.com/rackspace-orchestration-templates/docker" target="_blank">https://github.com/rackspace-orchestration-templates/docker</a></div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<div style="font-family:Calibri,sans-serif">-Keith</div>
<div style="font-family:Calibri,sans-serif"><br>
</div>
<span style="font-family:Calibri,sans-serif">
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;text-align:left;font-size:11pt;font-family:Calibri;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span>Steven Dake <<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>><div class=""><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div><span style="font-weight:bold">Date: </span>Thursday, April 3, 2014 10:30 AM<div><div class="h5"><br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [heat] metadata for a HOT<br>
</div></div></div><div><div class="h5">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div text="#000000" bgcolor="#FFFFFF">
<div>On 04/02/2014 08:41 PM, Keith Bray wrote:<br>
</div>
<blockquote type="cite">
<div><a href="https://wiki.openstack.org/wiki/Heat/StackMetadata" target="_blank">https://wiki.openstack.org/wiki/Heat/StackMetadata</a></div>
<div><br>
</div>
<div><a href="https://wiki.openstack.org/wiki/Heat/UI" target="_blank">https://wiki.openstack.org/wiki/Heat/UI</a></div>
<div><br>
</div>
<div>-Keith</div>
<div><br>
</div>
</blockquote>
Keith,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
For example just taking the keywords proposal:<br>
metadata:<br>
composed_of:<br>
- wordpress<br>
- mysql<br>
architecture:<br>
- lamp<br>
<br>
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.<br>
<br>
I don't believe the idea of structured metadata based upon real use cases has really been explored or -2'ed.<br>
<br>
Regards,<br>
-steve<br>
<br>
<blockquote type="cite">
<div></div>
<span>
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;text-align:left;font-size:11pt;font-family:Calibri;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span>Lingxian Kong <<a href="mailto:anlin.kong@gmail.com" target="_blank">anlin.kong@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, April 2, 2014 9:31 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [heat] metadata for a HOT<br>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div style="font-family:'courier new',monospace;font-size:small">
Is there any relevant wiki or specification doc?</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-04-03 4:45 GMT+08:00 Mike Spreitzer <span dir="ltr">
<<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<font face="sans-serif">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?</font><br>
<br>
<font face="sans-serif">Thanks,</font> <br>
<font face="sans-serif">Mike</font><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div><b><font style="background-color:rgb(243,243,243)" color="#000000" face="courier new,monospace">---------------------------------------</font></b></div>
<div><font color="#0000ff" face="comic sans
ms,sans-serif"><b>Lingxian Kong</b></font></div>
<div><font color="#ff00ff" face="comic sans
ms,sans-serif">Huawei Technologies Co.,LTD.</font></div>
<div><font color="#ff00ff" face="comic sans
ms,sans-serif">IT Product Line CloudOS PDU</font></div>
<div><font color="#ff00ff" face="comic sans
ms,sans-serif">China, Xi'an</font></div>
<div><font color="#ff00ff" face="comic sans
ms,sans-serif">Mobile: <a href="tel:%2B86-18602962792" value="+8618602962792" target="_blank">+86-18602962792</a></font></div>
<div><font color="#ff00ff" face="comic sans
ms,sans-serif">Email:
<a href="mailto:konglingxian@huawei.com" target="_blank">konglingxian@huawei.com</a>;
<a href="mailto:anlin.kong@gmail.com" target="_blank">anlin.kong@gmail.com</a></font></div>
</div>
</div>
</div>
</div>
</blockquote>
</span><br>
<fieldset></fieldset> <br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div></div></span>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>