<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>See in-line for comments on Clint's original list of options, and detail on each below.</div>
<div><br>
On Apr 10, 2013, at 5:35 AM, "Doug Davis" <<a href="mailto:dug@us.ibm.com">dug@us.ibm.com</a>> wrote:<br>
</div>
<blockquote type="cite">
<div>
<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>
</p>
</div>
</blockquote>
+1<br>
<blockquote type="cite">
<div>
<p><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. </font></p>
</div>
</blockquote>
Yes, this is part of the modularity vision I'm referring to. Heat should not be directly tied to a single format on the public side of the API. It should allow for whatever formats are needed by our Openstack user community.<br>
<blockquote type="cite">
<div>
<p><font size="2" face="sans-serif">thanks<br>
-Doug<br>
________________________________________________________<br>
STSM | Standards Architect | IBM Software Group<br>
(919) 254-6905 | IBM 444-6905 | <a href="mailto:dug@us.ibm.com">dug@us.ibm.com</a><br>
The more I'm around some people, the more I like my dog.</font><br>
<br>
<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 <<a href="mailto:thomas.spatzier@de.ibm.com">thomas.spatzier@de.ibm.com</a>></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,
</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></p>
<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>
</font></tt></div>
</blockquote>
<div><br>
</div>
Yes.
<div><br>
<blockquote type="cite">
<div><tt><font size="2">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>
</font></tt></div>
</blockquote>
<div><br>
</div>
Agreed.
<div><br>
<blockquote type="cite">
<div><tt><font size="2">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>
</font></tt></div>
</blockquote>
<div><br>
</div>
We have a lot to discuss in rather limited time, so we should keep this nice and crisp, getting across the conceptual difference between imperative and declarative models, and how TOSCA allows expression of each.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">Does that make sense to you?<br>
<br>
Regards,<br>
Thomas<br>
---------------------------------------------------------------------<br>
Tivoli CTO Office - Cloud Orchestration, Cloud Standards<br>
<br>
<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
Date: 10.04.2013 08:25<br>
Subject: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???<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>
</font></tt></div>
</blockquote>
<div><br>
</div>
This is already supported to a reasonable extent, and probably makes sense to retain what's already done. Handling existing CloudFormation templates is a valid use case for Heat. I don't think we should lose sight of that.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">* Open DSL w/ Declarative model(undefined yet)<br>
</font></tt></div>
</blockquote>
<div><br>
</div>
See my comment below on CAMP, as these are actually not very different. I am writing a WIKI page that details what this looks like, and will link it (hopefully today/tomorrow) to a new BP that simply asks for an open and vendor independent API and DSL. I have
a very clear vision for how this can be accomplished, and will detail it both at the summit and in written proposal form.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">* TOSCA<br>
</font></tt></div>
</blockquote>
<div><br>
</div>
We should be able to rather easily support TOSCA, at least the declarative modeling style, regardless if there is a default expression that aims to be more concise/simple.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">* CAMP<br>
</font></tt></div>
</blockquote>
<div><br>
</div>
CAMP focuses more on the interoperability aspects, and the API. It solves how you handle concurrent versions, extensibility, format discovery, type discovery, etc. The Open DSL with the declarative model that I'm referencing is synergistic here. Anish Karmarkar
(Oracle) and I (Rackspace) will both be present at ODS and will attend the Heat sessions. We are co-editors on the CAMP specification, and can indicate what use of CAMP could be appropriate for the Heat API, while still enabling TOSCA.</div>
<div><br>
</div>
<div>Note that TOSCA and CAMP are also complimentary. This really is not an "either-or" choice, it's more of how we plan our development to iteratively advance toward the point where we can support arbitrary expressions/formats, and have a simple and effective
modular approach to handling each.</div>
<div><br>
</div>
<div>Also, recognize I'm not suggesting that we try to support everything for everyone. We should start simple, and use an approach that we can easily build out as needed with minimal rework. I see no reason why we could not gradually support TOSCA, CAMP, and
others all in Heat with a common system architecture that's actually not that complicated. It just seems that way because these standards feel like unknowns.</div>
<div><br>
</div>
<div>The right people will be present at the Summit to demystify this for the whole Heat dev team and interested OpenStack stakeholders. We should focus primarily on what the use cases are for Heat, and pick solutions that fit those use cases well.</div>
<div><br>
</div>
<div>We should create a WIKI page detailing the use cases so our community can begin to contribute to that list, and we can sort them by relative priority as a team.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2"></font></tt><tt><font size="2"><a href="http://xkcd.com/927/">http://xkcd.com/927/</a></font></tt><tt><font size="2"><br>
</font></tt></div>
</blockquote>
<div><br>
</div>
Cute. To be clear, CAMP and TOSCA are not competing standards. They are complimentary with different areas of focus. What we do with Heat will certainly not create a competing standard. We will work to compliment and simplify what already exists.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">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>
</font></tt></div>
</blockquote>
<div><br>
</div>
We should have an open template format that's simple and concise. A CAMP compliant REST API can ingest that. The simple format should be our default. TOSCA (or portions thereof) can be handled using a plug-in at the parser level, processed by the Heat engine.
Remember that templates are a way to express an orchestration. The Heat engine handles what actually happens to carry out those instructions. Modularity can allow us to extend the engine as needed.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">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>
</font></tt></div>
</blockquote>
<div><br>
</div>
Absolutely.</div>
<div><br>
<blockquote type="cite">
<div><tt><font size="2">Clint Byrum<br>
HP Cloud Services<br>
</font></tt></div>
</blockquote>
<div><br>
</div>
Thanks,</div>
</div>
<div><br>
</div>
<div>Adrian Otto</div>
<div>--</div>
<div>Rackspace</div>
</body>
</html>