<div dir="ltr">I think the heat's version of nested containers is slightly different. Maybe it would be good to sync up in one of the meetings to align the stuff. The original Donabe idea is pre-heat and we presented this to TOSCA in early 2012 and they liked it a lot. So I wouldnt be surprised if all these things look similar at a 30K feet level :)<div>
<br></div><div style>Regarding the Curvature backend: it is based on pure Openstack APIs and authenticated via keystone. So one could take Curvature and just point it to *any* pure openstack implementation and it should work. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 9, 2013 at 2:45 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, May 08, 2013 at 10:31:52PM +0000, Gabriel Hurley wrote:<br>
> Here's the roadmap on this topic as it stands:<br>
><br>
> D3.js is in the process of being incorporated, and the team at Cisco that built Curvature is interested in combining some of the client-side know-how they've developed by building Curvature with the existing editable network topology code the folks at NTT and NEC built in Horizon, and combining all of that with what Heat wants to do to produce something AWESOME and very much in the Curvature style but built on the existing OpenStack APIs rather than the Ruby backend (Donabe).<br>

><br>
> Fortunately the "nested stacks"/"recursive containers" work is separate from the interface work, and that's primarily the part that was written in Ruby (Donabe). Heat is investigating that area with other DSLs such as TOSCA/OASIS (forgive me if I'm wrong there), and we'll eventually all arrive in the same place.<br>

<br>
</div>As previously stated[1] Heat already supports nested/recursive stacks, and<br>
I'm still not clear if "recursive containers" is the same thing or not, my<br>
assumption currently is that it is.<br>
<br>
The DSL/Providers discussion is about allowing users to specify custom<br>
resource types via templates (which is really just an extension to our<br>
current nested stack interface), so maybe that does map more closely to the<br>
definition of "recursive containers", or does it really mean inheritance?<br>
<br>
As you say Gabriel, hopefully over time the terminology and concepts will<br>
converge.<br>
<br>
[1]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007327.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007327.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-Debo~<br>
</div>