On 5/19/14 12:35 PM, "Randall Burt" <randall.b...@rackspace.com> wrote:
>On May 19, 2014, at 11:39 AM, Steven Hardy <sha...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
