Open Stack

Steven,

> Excerpt from
> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 23.04.2013 09:29
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
>
> 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)

I agree that the Model Interpreter shouldn't be part of the API layer.
Actually, before I read your mail, I already started to draw an alternative
architecture diagram as base for discussion. I updated the wiki page, so if
you refresh, you should see my version with some notes on the changes I
made.

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

I am asking myself if there is a model interpreter at all in the Heat
Engine, or if the Engine just parses (processes) the model into its
internal objects. Since CFN is tightly built in at the moment and I thought
you said it would be hard to decouple it short term, I was assuming that
the Model Processor for now would have to understand both Heat Template and
CFN. I tried to mark this with the little CFN box in the diagram.

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

That seems to make sense. Or I could also image to have the interpreter
layer (actually I see it more as a translation layer) as a layer below the
API layer, basically by pulling the grayed out box (out of scope and add-on
for now) in my diagram into the core.
That layer would do translation only and leave interpretation completely to
the Heat Engine's Model Processor.

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

Good point. I still have to get familiar with all this infrastructure, but
agree that such a central repo makes sense. Please provide more details
when you have figured out where/how exactly we maintain our working
documents.

Thomas