<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><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><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><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>