<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><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<br>
      alex<br>
      <br>
      <br>
      On 16/04/2013 11:38, Randall Burt wrote:<br>
    </div>
    <blockquote
      cite="mid:6ket7iptwvx8035waddnn824.1366137487689@email.android.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Exchange Server">
      <!-- converted from text -->
      <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
      <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 class="moz-txt-link-rfc2396E" href="mailto:adrian.otto@rackspace.com"><adrian.otto@rackspace.com></a> <br>
        Date: 04/16/2013 10:22 AM (GMT-08:00) <br>
        To: OpenStack Development Mailing" List
        <a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a> <br>
        Cc: OpenStack Development Mailing List
        <a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a> <br>
        Subject: Re: [openstack-dev] [Heat] Future Vision for Heat <br>
        <br>
        <br>
      </div>
      <font size="2"><span style="font-size:10pt;">
          <div class="PlainText">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 class="moz-txt-link-rfc2396E" href="mailto:ziad@sawalha.com"><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 class="moz-txt-link-rfc2396E" href="mailto:adrian.otto@rackspace.com"><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 moz-do-not-send="true"
              href="https://wiki.openstack.org/wiki/Heat/Vision">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 class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
            >> <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            > <br>
            > <br>
            > _______________________________________________<br>
            > OpenStack-dev mailing list<br>
            > <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
            > <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            <br>
            _______________________________________________<br>
            OpenStack-dev mailing list<br>
            <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
          </div>
        </span></font>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>