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

Tim Schnell tim.schnell at RACKSPACE.COM
Fri Dec 6 21:24:43 UTC 2013

To resolve this thread, I have created 5 blueprints based on this mailing
list discussion. I have attempted to distill the proposed specification
down to what seemed generally agreed upon but if you feel strongly that I
have incorrectly captured something let's talk about it!

Here are the blueprints:

1) Stack Keywords
blueprint: https://blueprints.launchpad.net/heat/+spec/stack-keywords
spec: https://wiki.openstack.org/wiki/Heat/UI#Stack_Keywords

2) Parameter Grouping and Ordering

3) Parameter Help Text
spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text

4) Parameter Label
spec: https://wiki.openstack.org/wiki/Heat/UI#Parameter_Label

This last blueprint did not get as much discussion so I have added it with
the discussion flag set. I think this will get more important in the
future but I don't need to implement right now. I'd love to hear more
thoughts about it.

5) Get Parameters API Endpoint


On 11/28/13 4:55 AM, "Zane Bitter" <zbitter at redhat.com> wrote:

>On 27/11/13 23:37, Fox, Kevin M wrote:
>> Hmm... Yeah. when you tell heat client the url to a template file, you
>>could set a flag telling the heat client it is in a git repo. It could
>>then automatically look for repo information and set a stack metadata
>>item pointing back to it.
>Or just store the URL.
>> If you didn't care about taking a performance hit, heat client could
>>always try and check to see if it was a git repo url. That may add
>>several extra http requests though...
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Clint Byrum [clint at fewbar.com]
>> Sent: Wednesday, November 27, 2013 1:04 PM
>> To: openstack-dev
>> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related
>>requirements &      roadmap
>> Excerpts from Fox, Kevin M's message of 2013-11-27 08:58:16 -0800:
>>> This use case is sort of a providence case. Where did the stack come
>>>from so I can find out more about it.
>> This exhibits similar problems to our Copyright header problems. Relying
>> on authors to maintain their authorship information in two places is
>> cumbersome and thus the one that is not automated will likely fall out
>> of sync fairly quickly.
>>> You could put a git commit field in the template itself but then it
>>>would be hard to keep updated.
>> Or you could have Heat able to pull from any remote source rather than
>> just allowing submission of the template directly. It would just be
>> another column in the stack record. This would allow said support person
>> to see where it came from by viewing the stack, which solves the use
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list