Open Stack

Hi Adrian,

Thanks for taking the time to do this, definitely provides a good starting
point for further discussion and captures many of the concepts mentioned
during the sessions on Monday.

On Tue, Apr 16, 2013 at 08:56:23AM +0000, Adrian Otto 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

Thanks for taking the time to do this, definitely provides a good starting
point for further discussion and captures many of the concepts mentioned
during the sessions on Monday.

I think your diagram represents a possible long-term view of how the
architecture could develop, but obviously there are many components there
which do not currently exist, or which are currently part of the heat core
orchestration engine.

I think it may be useful to look at the initial modifications required to
support the new "superset DSL", and I'll try to get a diagram up later with
my view of what is required to do this, but in summary:

- The model interpreter can be in heat-engine, as the first thing which
  processes the template during template-driven lifecycle operations
  (create/update) - this is separate from the current "parser" logic, so we
  can incrementally modify the underlying parser logic and interpreter
  logic in-step.

- The API layer can be unmodified

- Translations to/from formats other than our current CFN-compatible format
  and the new "Native DSL" (or "HOT" - Heat Openstack Template as was
  suggested on Monday :D) are performed outside of heat - IMO we only want
  to care about the superset DSL inside heat, and we don't want the
  complexity of the stacked API's, multiple model interpreter plugins etc (at
  least initially)

- Scheduler/parser logic remains in the heat-engine (this should not ever
  be moved into the API in your diagram IMO)

> Keith will be doing an Unconference session on the Workflow Service idea… I believe on Wednesday afternoon.

This definitely sounds interesting, and I'm interested in further
discussing this idea, see you there!

Steve