Open Stack

On Wed, Apr 10, 2013 at 10:18:05AM +0200, Thomas Spatzier wrote:
> Hi Clint,
> 
> you are raising a very valid point here. I agree that just adding support
> for all of the format brought forward could be problematic, and I have a
> few thoughts on that.
> 
> My experience is that there are many pattern engines (let me just use that
> term here) out there - some done as open source, some in various products
> of different vendors. I have seen very similar concepts in all of those
> engines, but each has its own proprietary format, e.g. we have an internal
> format in our product, partners in the OASIS TOSCA TC have their internal
> format in their engines and so on. So what we did when adopting TOSCA was
> to keep our internal format and add TOSCA as kind of front-end format
> on-top. This works, if the internal format and TOSCA (or any other
> standard) are well enough aligned.
> 
> So the discussion should maybe not be the adoption of one or the other
> format as the "native Heat metamodel", but the evolution of the internal
> meta model to a state where it (1) fits the use cases Heat wants to
> address, and (2) is aligned with the desired other formats as closely as
> possible. Then we could have very thin pluggable layers that add support
> for alternative "front-end formats".

+1 - IMO a single, relatively simple internal template language is the way
to go, and format-translation plugins layered on that internal/native format
makes perfect sense as a flexible way to support alternate template types.

This approach should also avoid introducing huge additional complexity to
the core orchestration engine and resource implementations, which was my
primary concern after first looking at the TOSCA spec ;)

> Maybe we can have exactly this discussion next week. I have a session on
> the TOSCA proposal at 11:50am on Monday, and I see your session is
> scheduled for after lunch.
> My plan was to give an overview of TOSCA in my session since maybe not all
> are familiar with it, but not spend too much time on it, but use the
> session for discussing the points above.

Sounds good.  Look forward to the discussion :)

Steve