<div dir="ltr">Hi Alex <div><br></div><div style>Thanks for your feedback wrt Curvature and Nested containers. Please do provide feedback post talk ... </div><div style><br></div><div style>Regarding TOSCA: I had some initial discussions with the core team about nested containers and they were very interested (Scott Moser et al) in digging more. Maybe time to circle back with them. </div>
<div style><br></div><div style>debo~</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 1:37 PM, Alex Heneveld <span dir="ltr"><<a href="mailto:alex.heneveld@cloudsoftcorp.com" target="_blank">alex.heneveld@cloudsoftcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
very useful summary. thanks adrian for this and thanks all for
the great discussion yesterday. a few comments:<br>
<br>
(1) @doug, @thomas: +1. while it would be possible for external
servers to understand different models and call REST using a
native dsl, it should also be possible to support multiple model
interpreters as part of the big blue box. that would seem better
for the "legacy" CFN :) and the new DSL (eg YAML) and/or possibly
TOSCA XML (or a lite version thereof!).<br>
<br>
(2) should the workflow service and the scheduler be more closely
integrated, or even the same? feels like whatever heat does for
its orchestration would want the same task management, scheduling,
locking, etc that imperative plans/workflow included as part of a
heat blueprint would want.<br>
<br>
(3) @debojyoti: +1. i'd really like to see support for nested /
hierarchical components or typed relationships. this gives a nice
solution to services/tiers/pools/autoscaling-groups going up one
level but you could go higher too. it makes it composable which
becomes very powerful (one of the best features of TOSCA imho). i
look forward to the curvature talk (and a visio-style gui for
heat!!).<br>
<br>
finally -- (4) -- is there any interest in continuing the
discussion while so many of us are here?<br>
<br>
i have heard rumours of extra rooms available for the asking.<br>
<br>
best<span class="HOEnZb"><font color="#888888"><br>
alex</font></span><div><div class="h5"><br>
<br>
<br>
On 16/04/2013 11:38, Randall Burt wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div>
<div>IIRC the understanding is/was that the "native" heat
primatives that make up the target for any Model Interpreter
*should* be sufficient to support either approach.</div>
<br>
<br>
<br>
-------- Original message --------<br>
From: Adrian Otto <a href="mailto:adrian.otto@rackspace.com" target="_blank"><adrian.otto@rackspace.com></a> <br>
Date: 04/16/2013 10:22 AM (GMT-08:00) <br>
To: OpenStack Development Mailing" List
<a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><openstack-dev@lists.openstack.org></a> <br>
Cc: OpenStack Development Mailing List
<a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><openstack-dev@lists.openstack.org></a> <br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat <br>
<br>
<br>
</div>
<font><span style="font-size:10pt">
<div>Ziad,<br>
<br>
Yes, if an alternate API were added that uses an imperative
modeling style, it may not translate cleanly to the native
(declarative) Heat DSL.<br>
<br>
I suppose the imperative plan could be passed through the
native API, or there may be a way to bypass the native API
and stimulate the downstream parts of the system as needed.
Clearly if there is a way for everything to go through the
same API, that may be cleaner. We have not considered this
use case in enough depth yet to be certain.<br>
<br>
Adrian<br>
<br>
On Apr 16, 2013, at 6:49 AM, "Ziad Sawalha"
<a href="mailto:ziad@sawalha.com" target="_blank"><ziad@sawalha.com></a> wrote:<br>
<br>
> If I understood this correctly, the native HEAT API is
going to be declarative (yay!) and would go through a model
interpreter which would spit out an imperative plan for
execution (script, workflow, whatever). That is all good.<br>
> <br>
> But if I have an API that is imperative, would I not
need to bypass the model interpreter and go straight to an
engine. Is my logic correct? And if so, how do we
accommodated for that in this design?<br>
> <br>
> <br>
> On Apr 16, 2013, at 3:56 AM, Adrian Otto
<a href="mailto:adrian.otto@rackspace.com" target="_blank"><adrian.otto@rackspace.com></a> wrote:<br>
> <br>
>> Heaters,<br>
>> <br>
>> I attended the various sessions at the Design
Summit today in Portland, and assembled as many of the ideas
for future planning as I could. For the benefit of those
who are not attending, or who were not in these sessions, I
created this Wiki page to express what I think is an early
consensus on where we could take things. Let's tweak this if
it's not a good direction.<br>
>> <br>
>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>> <br>
>> Keith will be doing an Unconference session on the
Workflow Service idea
I believe on Wednesday afternoon.<br>
>> <br>
>> Thanks,<br>
>> <br>
>> Adrian<br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</span></font>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div></div></div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>-Debo~<br>
</div>