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
