Open Stack

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.schnell at RACKSPACE.COM> wrote:

>On 5/19/14 12:35 PM, "Randall Burt" <randall.burt at RACKSPACE.COM> wrote:
>
>
>>On May 19, 2014, at 11:39 AM, Steven Hardy <shardy at 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 at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev