Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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 ___
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
Nilakhya, We discussed this a bit at the summit and I think the consensus was that this would be a good thing to do by passing a flag to resource-list that would flatten the structure of nested stacks in the call. Tim Schnell brought this up as well and may be interested in helping define the use case and spec. On May 14, 2014, at 4:32 PM, Nilakhya Chatterjee nilakhya.chatter...@globallogic.com wrote: Hi All, I recently tried to create a nested stack with the following example : http://paste.openstack.org/show/79156/ heat resource-list gives only MyStack but intention should be to list all the resources created by the nested templates, as also pointed by the command help: resource-list Show list of resources belonging to a stack Let me know if this requires a BP to be created for discussion. Thanks. -- Nilakhya | Consultant Engineering GlobalLogic P +x.xxx.xxx. 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
Excerpts from Tim Schnell's message of 2014-05-19 08:26:22 -0700: 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. +1 to a flag, and anything else that makes nested stacks less weird. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
On Mon, May 19, 2014 at 03:26:22PM +, 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
On May 19, 2014, at 11:39 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 19, 2014 at 03:26:22PM +, 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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
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 +, 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
Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.
# heat stack-create -f example.yaml # heat stack-list Assume the stack id is: 5d44526e-e75c-4cec-aeea-252d6d15254b # heat resource-list 5d44526e-e75c-4cec-aeea-252d6d15254b You get the resource named 'MyStack'. To check the details: # heat resource-show 5d44526e-e75c-4cec-aeea-252d6d15254b MyStack You now get the physical_resource_id for MyStack. Let's assume it to be: 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 # heat resource-list 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 Now you get your resource whose type is 'file:////heat.yaml'. Its name could be a random string. You can check that resource using: # heat resource-show 2ab05ea0-8cae-40b9-99cc-3aaf69badde6 name The process is a little bit dirty, though doable. If you want to submit a blueprint on this, it would be desirable to have it generic enough to cover all nested stack cases. Regards, - Qiming On Thu, May 15, 2014 at 03:02:00AM +0530, Nilakhya Chatterjee wrote: Hi All, I recently tried to create a nested stack with the following example : http://paste.openstack.org/show/79156/ heat resource-list gives only MyStack but intention should be to list all the resources created by the nested templates, as also pointed by the command help: resource-list Show list of resources belonging to a stack Let me know if this requires a BP to be created for discussion. Thanks. -- Nilakhya | Consultant Engineering GlobalLogic P +x.xxx.xxx. M +91.989.112.5770 S skype www.globallogic.com http://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
