Open Stack

Hi Alex

Thanks for your feedback wrt Curvature and Nested containers. Please do
provide feedback post talk ...

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.

debo~


On Tue, Apr 16, 2013 at 1:37 PM, Alex Heneveld <
alex.heneveld at cloudsoftcorp.com> wrote:

>
> very useful summary.  thanks adrian for this and thanks all for the great
> discussion yesterday.  a few comments:
>
> (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!).
>
> (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.
>
> (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!!).
>
> finally -- (4) -- is there any interest in continuing the discussion while
> so many of us are here?
>
> i have heard rumours of extra rooms available for the asking.
>
> best
> alex
>
>
>
> On 16/04/2013 11:38, Randall Burt wrote:
>
>  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.
>
>
>
> -------- Original message --------
> From: Adrian Otto <adrian.otto at rackspace.com> <adrian.otto at rackspace.com>
> Date: 04/16/2013 10:22 AM (GMT-08:00)
> To: OpenStack Development Mailing" List
> <openstack-dev at lists.openstack.org> <openstack-dev at lists.openstack.org>
> Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org><openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
>
>
>  Ziad,
>
> Yes, if an alternate API were added that uses an imperative modeling
> style, it may not translate cleanly to the native (declarative) Heat DSL.
>
> 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.
>
> Adrian
>
> On Apr 16, 2013, at 6:49 AM, "Ziad Sawalha" <ziad at sawalha.com><ziad at sawalha.com>wrote:
>
> > 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.
> >
> > 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?
> >
> >
> > On Apr 16, 2013, at 3:56 AM, Adrian Otto <adrian.otto at rackspace.com><adrian.otto at rackspace.com>wrote:
> >
> >> Heaters,
> >>
> >> 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.
> >>
> >> https://wiki.openstack.org/wiki/Heat/Vision
> >>
> >> Keith will be doing an Unconference session on the Workflow Service
> idea… I believe on Wednesday afternoon.
> >>
> >> Thanks,
> >>
> >> Adrian
> >> _______________________________________________
> >> 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 listOpenStack-dev at lists.openstack.orghttp://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
>
>


-- 
-Debo~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130416/ee4fe2a9/attachment.html>