Open Stack

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell <tim.schnell at rackspace.com>wrote:

> So the originally question that I attempted to pose was, "Can we add a
> schema-less metadata section to the template that can be used for a
> variety of purposes?". It looks like the answer is no, we need to discuss
> the features that would go in the metadata section and add them to the HOT
> specification if they are viable. I don't necessarily agree with this
> answer but I accept it as viable and take responsibility for the
> long-winded process that it took to get to this point.
>
> I think some valid points have been made and I have re-focused my efforts
> into the following proposed solution.
>
> I am fine with getting rid of the concept of a schema-less metadata
> section. If we can arrive at a workable design for a few use cases then I
> think that we won't need to discuss any of the options that Zane mentioned
> for handling the metadata section, comments, separate file, or in the
> template body.
>
> Use Case #1
> I see valid value in being able to group templates based on a type or
> keyword. This would allow any client, Horizon or a Template Catalog
> service, to better organize and handle display options for an end-user.
>
> I believe that Ladislav initially proposed a solution that will work here.
> So I will second a proposal that we add a new top-level field to the HOT
> specification called "keywords" that contains this template type.
>
>         keywords: wordpress, mysql, etc
>
>
>
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.



> Use Case #2
> The template author should also be able to explicitly define a help string
> that is distinct and separate from the description of an individual
> parameter. An example where this use case originated was with Nova
> Keypairs. The description of a keypair parameter might be something like,
> "This is the name of a nova key pair that will be used to ssh to the
> compute instance." A help string for this same parameter would be, "To
> learn more about nova keypairs click on this help article."
>
> I propose adding an additional field to the parameter definition:
>
>         Parameters:
>                 <parameter name>:
>                         description: This is the name of a nova key pair
> that will be used to
> ssh to the compute instance.
>                         help: To learn more about nova key pairs click on
> this <a
> href="/some/url/">help article</a>.
>
>
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?



> Use Case #3
> Grouping parameters would help the client make smarter decisions about how
> to display the parameters for input to the end-user. This is so that all
> parameters related to some database resource can be intelligently grouped
> together. In addition to grouping these parameters together, there should
> be a method to ensuring that the order within the group of parameters can
> be explicitly stated. This way, the client can return a group of database
> parameters and the template author can indicate that the database instance
> name should be first, then the username, then the password, instead of
> that group being returned in a random order.
>
>         Parameters:
>                 db_name:
>                         group: db
>                         order: 0
>                 db_username:
>                         group: db
>                         order: 1
>                 db_password:
>                         group: db
>                         order: 2
>                 web_node_name:
>                         group: web_node
>                         order: 0
>                 keypair:
>                         group: web_node
>                         order: 1
>
>
>
>
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:

ParameterGroups:
    db:
        name: ...
        username: ...
        password: ...
    web_node:
        name: ...
        keypair: ...

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.

Thanks very much for writing up these use cases!

-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/f6c7f895/attachment.html>