RFC: Integrating Aeolus with Heat

Hugh Brock hbrock at redhat.com
Wed Sep 26 17:53:15 UTC 2012


On Wed, Sep 26, 2012 at 06:06:19PM +0100, Steven Hardy wrote:
> On Wed, Sep 26, 2012 at 08:39:11AM -0400, Mo Morsi wrote:
> > Sorry for the delay been heads down prepping for the conf.
> > 
> > 
> > On 08/28/2012 08:04 AM, Tomas Sedovic wrote:
> > >> <snip>
> > >>
> > >>>
> > >>>
> > >>> ### Template format ###
> > >>>
> > >>> Aeolus uses a different format from Heat to describe deployables.
> > >>>
> > >>> We need to settle on what's the best thing to use. Options:
> > >>>
> > >>> 1) Translate Aeolus Deployable XML to Amazon CloudFormation JSON
> > >>>
> > >>> 2) Implement Aeolus Deployable XML format in Heat
> > >>>
> > >>> 3) Adopt CloudFormation JSON in Conductor
> > >>>
> > >>> 4) Have both Aeouls and Heat adopt another (open standard) format
> > >>>
> > >>> With all likelihood Heat will reject 2), we won't switch to 3) and
> > >>> since *both* communities would have to accept and implement 4), we'll
> > >>> probably stick to 1) for some time.
> > >>>
> > >>> Still, listing it here as it needs to be decided.
> > >>
> > >> Curious as to why you went w/ the CloudFormation JSON as the deployable
> > >> descriptor format? Is this what openstack uses?
> > >
> > >
> > > There's been a precedent for that in OpenStack (they started with EC2
> > > API before moving to their own, iirc).
> > >
> > > More importantly, CloudFormation is reasonably well documented and
> > > people are using it.
> > >
> > > Heat wants to provide an easy path for people using EC2 to switch to
> > > OpenStack. CloudFormation (both the API and the format) is one piece
> > > of the puzzle.
> > 
> > I was thinking about this a bit, and while supporting the CloudFormation
> > API makes sense to allow for switching as easy as possible, doesn't it
> > just encourage end-users to use Amazon's API? (eg proprietary and what
> > we're trying to move away from w/ Aeolus). What happens when Amazon
> > changes their API?
> 
> I think people starting from scratch on openstack (rather than migrating
> from AWS) would want to actively avoid the Amazon API - there are plenty
> of weird/bad aspects to the API, but we support it because it's a widely
> recognised specification, which is fairly well docmented, and it also has
> pretty good client-library support.
> 
> The client-library point should help manage the API-changing problem,
> since the AWS API is versioned, all we need to do is state which version
> of their API specification we support, then hopefully the compatibility
> problems can be handled in the client libraries (e.g projects like boto
> for python)
> 
> > 
> > It makes sense from OpenStack's perspective to use their own API, with
> > EC2 compatibility as an extra feature supported on the side. I'm not
> > against it, but apprehensive about how many proprietary APIs we expose
> > on top of our open implementations.
> 
> We've already refactored our internal interfaces to provide a more
> generic interal API, and efforts are underway to support multiple API
> variants - we will soon have an openstack-specific ReST API, as well as
> the existing AWS-compatible Cloudformation API.  This should provide a
> cleaner interface for users who don't care about AWS compatibility, and
> is being implemented in a similar style to existing openstack ReST APIs.
> 
> Template format is a more difficult problem; heat currently only supports
> AWS CFN template format, adding support for another template format would
> be hard (but not impossible).  We have already made some progress
> decoupling heat core logic and interfaces from AWS naming and formats,
> so taken to it's logical conclusion I can imagine the template validation
> and translation could take place at the API level, leaving us with a
> completely generic/open internal format (we are a long way from that
> point now though..)
> 
> Here is an approximation of the sort of architecture we are moving
> towards, hopefully it illustrates that we're aiming for modularity and
> separation:
> 
> https://github.com/hardys/diagrams/blob/master/PNG/architecture-overview.png

This is great stuff Steve.

My understanding is that the OpenStack folks will want Heat to develop
support for a non-AWS-specific API in addition to CloudFormations, for
exactly the reasons you cite Mo. 

I believe it will be most successful if we have a converter for the
common templates out there (CloudFormations, App Blueprints, TOSCA,
whatever else there is) so that Heat itself can be completely agnostic.

I also believe that Conductor should expose an API that is compatible
with Heat for instance lifecycle management -- in other words, people
should be able to take templates that work with Heat and decide to run
them through the Conductor abstraction layer instead -- whereupon
Conductor will do all the stuff it is good at, like checking quotas and
matching hardware profiles and choosing providers and so on, and then
pass the template through to Heat with the appropriate account
credentials supplied.

What that API is is still somewhat up for discussion, so maybe we ought
to start discussing it here?

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list