Open Stack

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