<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>
<div><br>
</div>
</div>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Christopher Armstrong <<a href="mailto:chris.armstrong@rackspace.com">chris.armstrong@rackspace.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">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, November 26, 2013 4:02 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">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell <span dir="ltr">
<<a href="mailto:tim.schnell@rackspace.com" target="_blank">tim.schnell@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the originally question that I attempted to pose was, "Can we add a<br>
schema-less metadata section to the template that can be used for a<br>
variety of purposes?". It looks like the answer is no, we need to discuss<br>
the features that would go in the metadata section and add them to the HOT<br>
specification if they are viable. I don't necessarily agree with this<br>
answer but I accept it as viable and take responsibility for the<br>
long-winded process that it took to get to this point.<br>
<br>
I think some valid points have been made and I have re-focused my efforts<br>
into the following proposed solution.<br>
<br>
I am fine with getting rid of the concept of a schema-less metadata<br>
section. If we can arrive at a workable design for a few use cases then I<br>
think that we won't need to discuss any of the options that Zane mentioned<br>
for handling the metadata section, comments, separate file, or in the<br>
template body.<br>
<br>
Use Case #1<br>
I see valid value in being able to group templates based on a type or<br>
keyword. This would allow any client, Horizon or a Template Catalog<br>
service, to better organize and handle display options for an end-user.<br>
<br>
I believe that Ladislav initially proposed a solution that will work here.<br>
So I will second a proposal that we add a new top-level field to the HOT<br>
specification called "keywords" that contains this template type.<br>
<br>
keywords: wordpress, mysql, etc<br>
<br>
<br>
</blockquote>
<div><br>
</div>
<div>My immediate inclination would be to just make keywords/tags out-of-band metadata managed by the template repository. I imagine this would be something that would be very useful to change without having to edit the template anyway.</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div><i>I'm not exactly sure what you are suggesting here, but I think that adding these keywords to the template will be less error prone than attempting to derive them some other way.</i></div>
<span id="OLK_SRC_BODY_SECTION">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Use Case #2<br>
The template author should also be able to explicitly define a help string<br>
that is distinct and separate from the description of an individual<br>
parameter. An example where this use case originated was with Nova<br>
Keypairs. The description of a keypair parameter might be something like,<br>
"This is the name of a nova key pair that will be used to ssh to the<br>
compute instance." A help string for this same parameter would be, "To<br>
learn more about nova keypairs click on this help article."<br>
<br>
I propose adding an additional field to the parameter definition:<br>
<br>
Parameters:<br>
<parameter name>:<br>
description: This is the name of a nova key pair that will be used to<br>
ssh to the compute instance.<br>
help: To learn more about nova key pairs click on this <a<br>
href="/some/url/">help article</a>.<br>
<br>
</blockquote>
<div><br>
</div>
<div>This one seems a bit weirder. I don't really understand what's wrong with just adding this content to the description field. However, if there are currently any objects in HOT that don't have any mechanism for providing a description, we should definitely
add them where they're missing. Do you think we need to extend the semantics of the "description" field to allow HTML?</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div><i>Description and help are separate things from a UI perspective. A description might be displayed as a label in a form or in a paragraph somewhere around the input. A help string is typically displayed as hover text when focusing on the input or hovering/clicking
on a question mark icon next to the field. We could technically separate these things in the code but because they serve separate purposes I would prefer to have them be defined explicitly.</i></div>
<span id="OLK_SRC_BODY_SECTION">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Use Case #3<br>
Grouping parameters would help the client make smarter decisions about how<br>
to display the parameters for input to the end-user. This is so that all<br>
parameters related to some database resource can be intelligently grouped<br>
together. In addition to grouping these parameters together, there should<br>
be a method to ensuring that the order within the group of parameters can<br>
be explicitly stated. This way, the client can return a group of database<br>
parameters and the template author can indicate that the database instance<br>
name should be first, then the username, then the password, instead of<br>
that group being returned in a random order.<br>
<br>
Parameters:<br>
db_name:<br>
group: db<br>
order: 0<br>
db_username:<br>
group: db<br>
order: 1<br>
db_password:<br>
group: db<br>
order: 2<br>
web_node_name:<br>
group: web_node<br>
order: 0<br>
keypair:<br>
group: web_node<br>
order: 1<br>
<br>
<br>
<br>
</blockquote>
<div><br>
</div>
<div>Have you considered just rendering them in the order that they appear in the template? I realize it's not the name (since you don't have any group names that you could use as a title for "boxes" around groups of parameters), but it might be a good enough
compromise. If you think it's absolutely mandatory to be able to group them in named groups, then I would actually propose a prettier syntax:</div>
<div><br>
</div>
<div>ParameterGroups:</div>
<div> db:</div>
<div> name: ...</div>
<div> username: ...</div>
<div> password: ...</div>
<div> web_node:</div>
<div> name: ...</div>
<div> keypair: ...</div>
<div><br>
</div>
<div>The ordering would be based on the ordering that they appear within the template, and you wouldn't have to repeat yourself naming the group for each parameter.</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div><i>I like having ParameterGroups as a top level field, this is a cleaner design. I do think that we still need to be able to define the order of parameters within each group as well, this could be done by accepting the position of the parameters in the
template but having an additional field will suggest to the template author that providing the order of the parameters will have significance later on.</i></div>
<span id="OLK_SRC_BODY_SECTION">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks very much for writing up these use cases!</div>
</div>
<div><br>
</div>
-- <br>
<div dir="ltr">
<div>IRC: radix</div>
Christopher Armstrong
<div>Rackspace</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div><i>Thanks radix!</i></div>
<div><i>Tim</i></div>
</body>
</html>