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
