Open Stack

I hope I'm not re-opening worm cans here, and that's not my intent, but I just wanted to get a little clarification in-line below:

On Dec 6, 2013, at 3:24 PM, Tim Schnell <tim.schnell at RACKSPACE.COM>
 wrote:

> 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

As proposed, these look like template keywords and not stack keywords.

I may be mis-remembering the conversation around this, but it would seem to me this mixes tagging templates and tagging stacks. In my mind, these are separate things. For the stack part, it seems like I could just pass something like "--keyword blah" multiple times to python-heatclient and not have to edit the template I'm passing. This lets me organize my stacks the way I want rather than relying on the template author (who may not be me) to organize things for me. Alternatively, I'd at least like the ability to accept, replace, and/or augment the keywords the template author proposes.

> 
> 2) Parameter Grouping and Ordering
> blueprint: 
> https://blueprints.launchpad.net/heat/+spec/parameter-grouping-ordering
> spec: 
> https://wiki.openstack.org/wiki/Heat/UI#Parameter_Grouping_and_Ordering
> 
> 3) Parameter Help Text
> blueprint: 
> https://blueprints.launchpad.net/heat/+spec/add-help-text-to-template
> spec: https://wiki.openstack.org/wiki/Heat/UI#Help_Text
> 
> 4) Parameter Label
> blueprint: 
> https://blueprints.launchpad.net/heat/+spec/add-parameter-label-to-template
> 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
> blueprint: 
> https://blueprints.launchpad.net/heat/+spec/get-parameters-from-api
> spec: 
> https://wiki.openstack.org/wiki/Heat/UI#New_API_Endpoint_for_Returning_Temp
> late_Parameters

History around validate_template aside, I wonder if this doesn't re-open the discussion around having an endpoint that will translate an entire template into the native format (HOT). I understand that the idea is that we normalize parameter values to relieve user interfaces from having to understand several formats supported by Heat, but it just seems to me that there's a more general use case here.

> 
> Thanks,
> Tim

I know its probably nit-picky, but I would prefer these specs be individual wiki pages instead of lumped all together. At any rate, thanks for organizing all this!

> 
> 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
>>> case.
>>> 
>>> _______________________________________________
>>> 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
>> 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