[openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

Tim Schnell tim.schnell at RACKSPACE.COM
Wed Nov 27 16:50:07 UTC 2013

On 11/27/13 10:39 AM, "Zane Bitter" <zbitter at redhat.com> wrote:

>On 26/11/13 23:44, Tim Schnell wrote:
>>> A template-validate call would need to return all the group and
>>> >information, but otherwise heat can ignore this extra data.
>> I agree with all of your modifications, although bringing up the
>> template-validate call reminded me that the implementation of this use
>> case should also imply a new REST endpoint specifically for returning
>> parameters. It seems like the current implementation in Horizon is a bit
>> hack-y by calling template-validate instead of something like
>> "get-parameters".
>That's inherited from how the cfn-compatible API does it, but it doesn't
>seem hacky to me. And it matches exactly how the UI works - you upload a
>template, it validates it and gets back the list of parameters.
>This raises a good point though - it ought to be Heat that determines
>the order of the parameters and returns them in a list (like heat-cfn
>does - though the list is currently randomly ordered). Clients need to
>treat the template as a black box, since the format changes over time.

I would be fine with Heat returning the parameters already ordered
(dependent on the order recognizing parameter grouping). I don't have a
strong opinion about the naming convention of the REST API call that I
have to make to get the parameters but I would also like to start
discussing including the current parameter values in whatever api call
this ends up being. For a Stack Update, I would like to populate the
parameters with previously entered values, although this has further
implications for values that are encrypted, like passwords.

Horizon, currently does not implement a Stack Update and this has been one
of the major sticking points for me trying to figure out how to provide an
interface for it.

I would imagine that adding the parameter values to the template validate
response would make it more obvious that it may warrant a separate
endpoint. Then template_validate can(should?) simply return a boolean

>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list