Open Stack

From: Steve Baker <sbaker at redhat.com<mailto:sbaker at redhat.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:29 PM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <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 11/27/2013 11:02 AM, Christopher Armstrong wrote:
On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell <tim.schnell at rackspace.com<mailto:tim.schnell at rackspace.com>> wrote:


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!

Good point, I'd like to revise my previous parameter-groups example:

parameter-groups:
- name: db
  description: Database configuration options
  parameters: [db_name, db_username, db_password]
- name: web_node
  description: Web server configuration
  parameters: [web_node_name, keypair]
parameters:
  # as above, but without requiring any order or group attributes

Here, parameter-groups is a list which implies the order, and parameters are specified in the group as a list, so we get the order from that too. This means a new parameter-groups section which contains anything required to build a good parameters form, and no modifications required to the parameters section at all.


+1 This structure gives me all of the information that I would need for organizing the parameters on the screen in an exact way.

Thanks,
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/154dd55c/attachment.html>