Open Stack

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.burt at 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.gorski at 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.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
> >>
> >> _______________________________________________
> >> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/>
http://www.globallogic.com/email_disclaimer.txt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/063866cb/attachment.html>