Open Stack

From: Christopher Armstrong <chris.armstrong at rackspace.com<mailto:chris.armstrong at rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, November 26, 2013 4:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell <tim.schnell at rackspace.com<mailto: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.

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.


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?

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.


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.

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.

Thanks very much for writing up these use cases!

--
IRC: radix
Christopher Armstrong
Rackspace

Thanks radix!
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/e7b138d8/attachment.html>