Open Stack

I have submitted a new/expanded spec for this feature: https://review.openstack.org/#/c/98219/. I hope to start some WiP patches this afternoon/tomorrow morning. Spec reviews and input most welcome.

On Jun 5, 2014, at 11:35 AM, Randall Burt <randall.burt at RACKSPACE.COM> wrote:

> Hey, sorry for the slow follow. I have to put some finishing touches on a spec and submit that for review. I'll reply to the list with the link later today. Hope to have an initial patch up as well in the next day or so.
> 
> On Jun 5, 2014, at 10:03 AM, Nilakhya Chatterjee <nilakhya.chatterjee at globallogic.com>
> wrote:
> 
>> HI Guys, 
>> 
>> It was gr8 to find your interest in solving the nested stack resource listing.
>> 
>> Lets move ahead by finishing any discussions left over the BP and getting an approval on It.
>> 
>> Till now what makes sense to me are : 
>> 
>> a) an additional flag in the client call  --nested (randall)
>> b) A flattened  DS in the output  (tim) 
>> 
>> 
>> Thanks all ! 
>> 
>> 
>> On Wed, May 21, 2014 at 12:42 AM, Randall Burt <randall.burt at rackspace.com> wrote:
>> Bartosz, would that be in addition to --nested? Seems like id want to be able to say "all of it" as well as "some of it".
>> 
>> On May 20, 2014, at 1:24 PM, Bartosz Górski <bartosz.gorski at ntti3.com>
>> wrote:
>> 
>>> Hi Tim,
>>> 
>>> Maybe instead of just a flag like --nested (bool value) to resource-list we can add optional argument like --depth X or --nested-level X (X - integer value) to limit the depth for recursive listing of nested resources?
>>> 
>>> Best,
>>> Bartosz
>>> 
>>> On 05/19/2014 09:13 PM, Tim Schnell wrote:
>>>> Blueprint:
>>>> https://blueprints.launchpad.net/heat/+spec/explode-nested-resources
>>>> 
>>>> Spec: https://wiki.openstack.org/wiki/Heat/explode-resource-list
>>>> 
>>>> Tim
>>>> 
>>>> On 5/19/14 1:53 PM, "Tim Schnell" <tim.schnell at RACKSPACE.COM> wrote:
>>>> 
>>>>> On 5/19/14 12:35 PM, "Randall Burt" <randall.burt at RACKSPACE.COM> wrote:
>>>>> 
>>>>> 
>>>>>> On May 19, 2014, at 11:39 AM, Steven Hardy <shardy at redhat.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> On Mon, May 19, 2014 at 03:26:22PM +0000, Tim Schnell wrote:
>>>>>>>> Hi Nilakhya,
>>>>>>>> 
>>>>>>>> As Randall mentioned we did discuss this exact issue at the summit. I
>>>>>>>> was
>>>>>>>> planning on putting a blueprint together today to continue the
>>>>>>>> discussion.
>>>>>>>> The Stack Preview call is already doing the necessary recursion to
>>>>>>>> gather
>>>>>>>> the resources so we discussed being able to pass a stack id to the
>>>>>>>> preview
>>>>>>>> endpoint to get all of the resources.
>>>>>>>> 
>>>>>>>> However, after thinking about it some more, I agree with Randall that
>>>>>>>> maybe this should be an extra query parameter passed to the
>>>>>>>> resource-list
>>>>>>>> call. I'Ll have the blueprint up later today, unless you have already
>>>>>>>> started on it.
>>>>>>> Note there is a patch from Anderson/Richard which may help with this:
>>>>>>> 
>>>>>>> https://review.openstack.org/#/c/85781/
>>>>>>> 
>>>>>>> The idea was to enable easier introspection of resources backed by
>>>>>>> nested
>>>>>>> stacks in a UI, but it could be equally useful to generate a "tree"
>>>>>>> resource view in the CLI client by walking the links.
>>>>>>> 
>>>>>>> This would obviously be less efficient than recursing inside the
>>>>>>> engine,
>>>>>>> but arguably the output would be much more useful if it retains the
>>>>>>> nesting
>>>>>>> structure, as opposed to presenting a fully flattened "soup" of
>>>>>>> resources
>>>>>>> with no idea which stack/layer they belong to.
>>>>>>> 
>>>>>>> Steve
>>>>>> Could we simply add stack name/id to this output if the flag is passed? I
>>>>>> agree that we currently have the capability to traverse the tree
>>>>>> structure of nested stacks, but several folks have requested this
>>>>>> capability, mostly for UI/UX purposes. It would be faster if you want the
>>>>>> flat structure and we still retain the capability to create your own
>>>>>> tree/widget/whatever by following the links. Also, I think its best to
>>>>>> include this in the API directly since not all users are integrating
>>>>>> using the python-heatclient.
>>>>> +1 for adding the stack name/id to the output to maintain a reference to
>>>>> the initial stack that the resource belongs to. The original stated
>>>>> use-case that I am aware of was to have a flat list of all resources
>>>>> associated with a stack to be displayed in the UI when the user prompts to
>>>>> delete a stack. This would prevent confusion about what and why different
>>>>> resources are being deleted due to the stack delete.
>>>>> 
>>>>> This use-case does not require any information about the nested stacks but
>>>>> I can foresee that information being useful in the future. I think a
>>>>> flattened data structure (with a reference to stack id) is still the most
>>>>> efficient solution. The patch landed by Anderson/Richard provides an
>>>>> alternate method to drill down into nested stacks if the hierarchy is
>>>>> important information though this is not the optimal solution in this
>>>>> case.
>>>>> 
>>>>> Tim
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>> 
>> 
>> 
>> -- 
>> 
>> Nilakhya | Consultant Engineering
>> GlobalLogic
>> P +x.xxx.xxx.xxxx  M +91.989.112.5770  S skype
>> www.globallogic.com
>> 
>> http://www.globallogic.com/email_disclaimer.txt
>> _______________________________________________
>> 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