I have submitted a new/expanded spec for this feature: https://review.openstack.org/#/c/98219/. I hope to start some WiP patches this afternoon/tomorrow morning. Spec reviews and input most welcome.
On Jun 5, 2014, at 11:35 AM, Randall Burt <randall.b...@rackspace.com> wrote: > Hey, sorry for the slow follow. I have to put some finishing touches on a > spec and submit that for review. I'll reply to the list with the link later > today. Hope to have an initial patch up as well in the next day or so. > > On Jun 5, 2014, at 10:03 AM, Nilakhya Chatterjee > <nilakhya.chatter...@globallogic.com> > wrote: > >> HI Guys, >> >> It was gr8 to find your interest in solving the nested stack resource >> listing. >> >> Lets move ahead by finishing any discussions left over the BP and getting an >> approval on It. >> >> Till now what makes sense to me are : >> >> a) an additional flag in the client call --nested (randall) >> b) A flattened DS in the output (tim) >> >> >> Thanks all ! >> >> >> On Wed, May 21, 2014 at 12:42 AM, Randall Burt <randall.b...@rackspace.com> >> wrote: >> 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 >> >> >> >> -- >> >> Nilakhya | Consultant Engineering >> GlobalLogic >> P +x.xxx.xxx.xxxx M +91.989.112.5770 S skype >> www.globallogic.com >> >> http://www.globallogic.com/email_disclaimer.txt >> _______________________________________________ >> 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
