RFC: Integrating Aeolus with Heat

Tomas Sedovic tsedovic at redhat.com
Thu Sep 27 12:14:45 UTC 2012


On 09/26/2012 07:53 PM, Hugh Brock wrote:
> 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.
>

Writing such a converter for Aeolus Deployable XML -> 
Heat/CloudFormation templates definitely falls into the Aeolus & Heat 
integration effort.

It makes sense to have that as a standalone library/tool that would 
support multiple formats in the future.

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




More information about the aeolus-devel mailing list