Open Stack

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

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.

Does that make sense to you?

Regards,
Thomas
---------------------------------------------------------------------
Tivoli CTO Office - Cloud Orchestration, Cloud Standards



From:	Clint Byrum <clint at fewbar.com>
To:	openstack-dev <openstack-dev at lists.openstack.org>,
Date:	10.04.2013 08:25
Subject:	[openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???



As we near the next OpenStack Summit, it has become clear that the way
forward for Heat users is.. well, not very clear.

Heat currently only supports one way to define applications. That is the
hybrid Heat-specific plus CloudFormation-compatible templating language.

We also have a proposal to add TOSCA support to Heat:

https://blueprints.launchpad.net/heat/+spec/tosca-support
http://lists.openstack.org/pipermail/openstack-dev/2013-April/007252.html

Adrian from RackSpace has stated that they are working on an "Open API &
DSL" and a "Declarative Model":

http://lists.openstack.org/pipermail/openstack-dev/2013-April/007126.html

I've also heard OASIS/CAMP thrown around as something that might be
implemented in Heat.

I count no less than 4 possible ways for users to express application
deployments. Succinctly:

* CloudFormation-ish
* Open DSL w/ Declarative model(undefined yet)
* TOSCA
* CAMP

http://xkcd.com/927/

I am concerned about the fragmentation that users may be presented
with if we do not take a step back and talk about the ramifications
of supporting all of them. Its great to be as broad and accepting as
possible when it makes sense, but not at the expense of user confusion
and/or incompatibility.

So, I am calling on those interested in the various formats to at least
raise your hands and let us, the heat users and developers, know what
you expect from Heat as a project, and what makes any of these standards
worth implementing. I think this is worth having a break-out session at
the summit next week to discuss, and would also encourage everyone to
start (or continue) the discussion right here on the mailing list.


Clint Byrum
HP Cloud Services

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev