Open Stack

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

>
>    From: Christopher Armstrong <chris.armstrong at rackspace.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> 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>
> 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
> > 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.*
>
>
Basically, I'm just suggesting putting the tags outside of template. Not
deriving them -- I still think they should be explicitly specified, but
just putting them in e.g. the database instead of directly in the template.

Basically, in a public repository of templates, I can imagine tags being
based on third-party or moderator input, instead of just based on what the
template author says.  Keeping them outside of the template would allow
content moderators to do that without posting a new version of the template.

Anyway, I don't feel that strongly about this - if there's a strong enough
desire to see tags in the template, then I won't argue against it.



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

Okay, fair enough.


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

I guess Steve Baker has a better suggestion - I forgot that order usually
isn't preserved in YAML properties, so using a list of objects is better.



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