Open Stack

Clint wrote:

> There is a third stealth-objective that CFN has caused to linger in
> Heat. That is "packaging cloud applications". By allowing the 100%
> concrete CFN template to stand alone, users can "ship" the template.
> 
> IMO this marrying of software assembly, config, and orchestration is a
> concern unto itself, and best left outside of the core infrastructure
> orchestration system.

I favor separation of concerns.  I do not follow what you are suggesting 
about how to separate these particular concerns.  Can you elaborate?

Clint also wrote:

> A ruby DSL is not something I think is ever going to happen in
> OpenStack.

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.

A distributed system does not all have to be written in the same language.

Thomas wrote:

> I don't fully get this idea of HOT consuming a monolithic model produced 
by
> some compiler - be it Weaver or anything else.
> I thought the goal was to develop HOT in a way that users can actually
> write HOT, as opposed to having to use some "compiler" to produce some
> useful model.
> So wouldn't it make sense to make sure we add the right concepts to HOT 
to
> make sure we are able to express what we want to express and have things
> like composability, re-use, substitutability?

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.

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.

Thomas wrote:
> As said in my comment above, I would like to see us focusing on the
> agreement of one language - HOT - instead of yet another DSL.
> There are things out there that are well established (like chef or 
puppet),
> and HOT should be able to efficiently and intuitively use those things 
and
> orchestrate components built using those things.

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).

Thomas wrote:
> Anyway, this might be off the track that was originally discussed in 
this
> thread (i.e. holistic scheduling and so on) ...

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.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130925/d1cc2686/attachment.html>