Open Stack

On 12/6/13 4:32 PM, "Randall Burt" <randall.burt at RACKSPACE.COM> wrote:

>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.
There was discussion about the particular implementation which didn't feel
quite resolved to me. The 2 options being, putting keywords in the
template and then parsing them out to store separately in the database and
what you suggest, passing them in along with the template.

The thought behind putting them in the template was to make it more
apparent during a stack update that the keywords may need to be updated.
As long as the final implementation is passing these keywords back via
stack-list and stack-show and allows for the user interface to query
stacks by keyword then it solves the use case.

I didn't change the initial proposal because after scoping the use case to
stack keywords I didn't notice any major negative response. Does including
the keywords within the template cause major heartburn?
>
>> 
>> 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-templa
>>te
>> 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_Te
>>mp
>> 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.

Agreed, I can definitely see future use cases that would support an
endpoint to converge the entire template. :)
>
>> 
>> 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!

Doh! Will do next go round.

Thanks,
Tim
>
>> 
>> 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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev