Open Stack

+1

I believe that the core of Heat should, for the most part, remain pretty
agnostic
to the format of the deployment descriptions.

There will be a bit of pain for users of Heat for a while until the dust
settles and
the community gravitates towards the preferred format.  But I'd prefer to
let the users
and the community decide the winner instead of just us doing it right now.

It will also allow Heat to have a longer life-span since it won't be tied
to one
particular format and can more easily migrate in the future.  Formats will
come and go.

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug at us.ibm.com
The more I'm around some people, the more I like my dog.



From:	Thomas Spatzier <thomas.spatzier at de.ibm.com>
To:	OpenStack Development Mailing List
            <openstack-dev at lists.openstack.org>,
Date:	04/10/2013 04:24 AM
Subject:	Re: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???



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




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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130410/19f6fb41/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130410/19f6fb41/attachment.gif>