<html><body>
<p><font size="2" face="sans-serif">+1</font><br>
<br>
<font size="2" face="sans-serif">I believe that the core of Heat should, for the most part, remain pretty agnostic</font><br>
<font size="2" face="sans-serif">to the format of the deployment descriptions.</font><br>
<br>
<font size="2" face="sans-serif">There will be a bit of pain for users of Heat for a while until the dust settles and</font><br>
<font size="2" face="sans-serif">the community gravitates towards the preferred format. But I'd prefer to let the users</font><br>
<font size="2" face="sans-serif">and the community decide the winner instead of just us doing it right now.</font><br>
<br>
<font size="2" face="sans-serif">It will also allow Heat to have a longer life-span since it won't be tied to one</font><br>
<font size="2" face="sans-serif">particular format and can more easily migrate in the future. Formats will come and go. <br>
<br>
thanks<br>
-Doug<br>
________________________________________________________<br>
STSM | Standards Architect | IBM Software Group<br>
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com<br>
The more I'm around some people, the more I like my dog.</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF1DADFD15F888f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Thomas Spatzier ---04/10/2013 04:24:59 AM---Hi Clint, you are raising a very valid point here. I agre"><font size="2" color="#424282" face="sans-serif">Thomas Spatzier ---04/10/2013 04:24:59 AM---Hi Clint, you are raising a very valid point here. I agree that just adding support</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Thomas Spatzier <thomas.spatzier@de.ibm.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">04/10/2013 04:24 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hi Clint,<br>
<br>
you are raising a very valid point here. I agree that just adding support<br>
for all of the format brought forward could be problematic, and I have a<br>
few thoughts on that.<br>
<br>
My experience is that there are many pattern engines (let me just use that<br>
term here) out there - some done as open source, some in various products<br>
of different vendors. I have seen very similar concepts in all of those<br>
engines, but each has its own proprietary format, e.g. we have an internal<br>
format in our product, partners in the OASIS TOSCA TC have their internal<br>
format in their engines and so on. So what we did when adopting TOSCA was<br>
to keep our internal format and add TOSCA as kind of front-end format<br>
on-top. This works, if the internal format and TOSCA (or any other<br>
standard) are well enough aligned.<br>
<br>
So the discussion should maybe not be the adoption of one or the other<br>
format as the "native Heat metamodel", but the evolution of the internal<br>
meta model to a state where it (1) fits the use cases Heat wants to<br>
address, and (2) is aligned with the desired other formats as closely as<br>
possible. Then we could have very thin pluggable layers that add support<br>
for alternative "front-end formats".<br>
<br>
Maybe we can have exactly this discussion next week. I have a session on<br>
the TOSCA proposal at 11:50am on Monday, and I see your session is<br>
scheduled for after lunch.<br>
My plan was to give an overview of TOSCA in my session since maybe not all<br>
are familiar with it, but not spend too much time on it, but use the<br>
session for discussing the points above.<br>
<br>
Does that make sense to you?<br>
<br>
Regards,<br>
Thomas<br>
---------------------------------------------------------------------<br>
Tivoli CTO Office - Cloud Orchestration, Cloud Standards<br>
<br>
<br>
<br>
From: Clint Byrum <clint@fewbar.com><br>
To: openstack-dev <openstack-dev@lists.openstack.org>,<br>
Date: 10.04.2013 08:25<br>
Subject: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???<br>
<br>
<br>
<br>
As we near the next OpenStack Summit, it has become clear that the way<br>
forward for Heat users is.. well, not very clear.<br>
<br>
Heat currently only supports one way to define applications. That is the<br>
hybrid Heat-specific plus CloudFormation-compatible templating language.<br>
<br>
We also have a proposal to add TOSCA support to Heat:<br>
<br>
</font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/heat/+spec/tosca-support">https://blueprints.launchpad.net/heat/+spec/tosca-support</a></font></tt><tt><font size="2"><br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007252.html">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007252.html</a></font></tt><tt><font size="2"><br>
<br>
Adrian from RackSpace has stated that they are working on an "Open API &<br>
DSL" and a "Declarative Model":<br>
<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007126.html">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007126.html</a></font></tt><tt><font size="2"><br>
<br>
I've also heard OASIS/CAMP thrown around as something that might be<br>
implemented in Heat.<br>
<br>
I count no less than 4 possible ways for users to express application<br>
deployments. Succinctly:<br>
<br>
* CloudFormation-ish<br>
* Open DSL w/ Declarative model(undefined yet)<br>
* TOSCA<br>
* CAMP<br>
<br>
</font></tt><tt><font size="2"><a href="http://xkcd.com/927/">http://xkcd.com/927/</a></font></tt><tt><font size="2"><br>
<br>
I am concerned about the fragmentation that users may be presented<br>
with if we do not take a step back and talk about the ramifications<br>
of supporting all of them. Its great to be as broad and accepting as<br>
possible when it makes sense, but not at the expense of user confusion<br>
and/or incompatibility.<br>
<br>
So, I am calling on those interested in the various formats to at least<br>
raise your hands and let us, the heat users and developers, know what<br>
you expect from Heat as a project, and what makes any of these standards<br>
worth implementing. I think this is worth having a break-out session at<br>
the summit next week to discuss, and would also encourage everyone to<br>
start (or continue) the discussion right here on the mailing list.<br>
<br>
<br>
Clint Byrum<br>
HP Cloud Services<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>