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.gor...@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.schn...@rackspace.com> wrote: >> >>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
