On Tue, Nov 26, 2013 at 4:35 PM, Tim Schnell <tim.schn...@rackspace.com>wrote:
> > From: Christopher Armstrong <chris.armstr...@rackspace.com> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, November 26, 2013 4:02 PM > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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.schn...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
