I've submitted the spec (finally) and will work on some initial patches this afternoon/tomorrow. Please provide any feedback and thanks!
https://review.openstack.org/#/c/98219 On Jun 5, 2014, at 11:35 AM, Randall Burt <[email protected]> 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 > <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >> 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" <[email protected]> wrote: >>>> >>>>> On 5/19/14 12:35 PM, "Randall Burt" <[email protected]> wrote: >>>>> >>>>> >>>>>> On May 19, 2014, at 11:39 AM, Steven Hardy <[email protected]> >>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
