Open Stack

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