Open Stack

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