RFC: Integrating Aeolus with Heat

Steven Hardy shardy at redhat.com
Wed Sep 26 17:06:19 UTC 2012


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

Steve



More information about the aeolus-devel mailing list