<font size=2 face="sans-serif">Clint wrote:</font>
<br>
<br><tt><font size=2>> There is a third stealth-objective that CFN has
caused to linger in<br>
> Heat. That is "packaging cloud applications". By allowing
the 100%<br>
> concrete CFN template to stand alone, users can "ship" the
template.<br>
> <br>
> IMO this marrying of software assembly, config, and orchestration
is a<br>
> concern unto itself, and best left outside of the core infrastructure<br>
> orchestration system.</font></tt>
<br>
<br><font size=2 face="sans-serif">I favor separation of concerns.  I
do not follow what you are suggesting about how to separate these particular
concerns.  Can you elaborate?</font>
<br>
<br><font size=2 face="sans-serif">Clint also wrote:</font>
<br>
<br><tt><font size=2>> A ruby DSL is not something I think is ever going
to happen in<br>
> OpenStack.</font></tt>
<br>
<br><font size=2 face="sans-serif">Ruby is particularly good when the runtime
scripting is done through chef or puppet, which are based on Ruby.  For
example, Weaver supports chef based scripting, and integrates in a convenient
way.</font>
<br>
<br><font size=2 face="sans-serif">A distributed system does not all have
to be written in the same language.</font>
<br>
<br><font size=2 face="sans-serif">Thomas wrote:</font>
<br>
<br><tt><font size=2>> I don't fully get this idea of HOT consuming
a monolithic model produced by<br>
> some compiler - be it Weaver or anything else.<br>
> I thought the goal was to develop HOT in a way that users can actually<br>
> write HOT, as opposed to having to use some "compiler" to
produce some<br>
> useful model.<br>
> So wouldn't it make sense to make sure we add the right concepts to
HOT to<br>
> make sure we are able to express what we want to express and have
things<br>
> like composability, re-use, substitutability?</font></tt>
<br>
<br><font size=2 face="sans-serif">I am generally suspicious of analogies,
but let me offer one here.  In the realm of programming languages,
many have great features for modularity within one source file.  These
features are greatly appreciated and used.  But that does not stop
people from wanting to maintain sources factored into multiple files.</font>
<br>
<br><font size=2 face="sans-serif">Back to the world at hand, I do not
see a conflict between (1) making a language for monoliths with sophisticated
internal structure and (2) defining one or more languages for non-monolithic
sources.</font>
<br>
<br><font size=2 face="sans-serif">Thomas wrote:</font>
<br><tt><font size=2>> As said in my comment above, I would like to
see us focusing on the<br>
> agreement of one language - HOT - instead of yet another DSL.<br>
> There are things out there that are well established (like chef or
puppet),<br>
> and HOT should be able to efficiently and intuitively use those things
and<br>
> orchestrate components built using those things.</font></tt>
<br>
<br><font size=2 face="sans-serif">Yes, it may be that our best tactic
at this point is to allow multiple (2), some or all not defined through
the OpenStack Foundation, while agreeing here on (1).</font>
<br>
<br><font size=2 face="sans-serif">Thomas wrote:</font>
<br><tt><font size=2>> Anyway, this might be off the track that was
originally discussed in this<br>
> thread (i.e. holistic scheduling and so on) ...</font></tt>
<br>
<br><font size=2 face="sans-serif">We are engaged in a boundary-drawing
and relationship-drawing exercise.  I brought up this idea of a software
orchestration compiler to show why I think the software orchestration preparation
stage is best done earlier rather than later.</font>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>