Open Stack

On Tue, Apr 23, 2013 at 12:52:23AM +0200, Florian Rosenberg wrote:
> 
> Hi Adrian,
> 
> thanks for the summary during the summit. Some questions on the
> architecture:
> 
> What is the purpose of the "model interpreter" within the REST API module?
> As I see this architecture now, the model interpreter is responsible for
> parsing the new DSL that you proposed to build up an internal model, right?
> So is there a need for another model interpreter once we agree on the
> common format? I'm asking this because I'm a little fuzzy on the
> distinction between the 'model interpreter' and the 'model processor'.
> Further, how is the REST API knowing to which engine we need to forward
> this too (is this federation of Heat engines reflecting the current
> implementation or is this part of the new architecture)?

I agree, the model interpreter probably won't end up in the API (at least
in the short/medium term, because it will be necessarily coupled with the
model processor, aka "parser" in our previous discussions)

The way I see it working (short/medium term) is:

- Stack template (either CFN or HOT) is passed to either the ReST or CFN
  API
- Template is passed to the engine via RPC call
- Template is processed by "model interpreter", which mangles e.g CFN to
  the internal format (HOT), or does nothing if it's already HOT format
- Processed template is passed to the "Model Processor", aka "parser",
  which renders the template in our internal objects, ready to orchestrate

Long term (when the internal HOT format is stable), it might make sense to
push the "model interpreter" up to the API level, probably via a
template-interpreter-plugin model, but I see this as something we shouldn't
care about during the first-pass where the priority must be
capturing/defining the new template language, and keeping our existing
functionality working.

So I see the following problems with the diagram:
- Model interpreter should be stacked on top of Model Processor in the
  engine
- CFN blob is confusing, should probably be removed
- The whole API relay blob should be removed or greyed out, as it's out of
  scope for heat (for the time being at least)
- I don't like the Blueprint terminology, I would prefer just to say "Heat
  Template", since it's consistent with our current documentation and is
  generic enough to refer to either template format (since we'll end up
  handling two formats via the API, not just HOT)

Adrian - If you're happy to update to reflect those comments that would be
great, may also be helpful to share the editable diagram somewhere, I have
a diagrams repo in my GitHub account, also thinking of reinstating a
central repo somewhere where we can all push design/presentation materials
(not worked out where yet..)

https://github.com/hardys/diagrams

Steve