Open Stack

On 10/04/13 10:18, 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

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

Both the TOSCA overview and this discussion sound very valuable to me. 
Thanks to a last-minute change of plans I will be at Summit, so I look 
forward to hearing them.

FWIW it appears to me that CAMP is targeted at the PaaS level, and while 
I'm supportive of that effort it doesn't seem to me to be in scope for 
Heat, which I see as limited to the IaaS layer. I'm willing to be 
re-educated though ;)

cheers,
Zane.

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