RFC: Integrating Aeolus with Heat

Mo Morsi mmorsi at redhat.com
Wed Sep 26 12:39:11 UTC 2012


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?

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.




> <snip>
>
>>
>>
>>>
>>>
>>> ### Is Heat going to be the only way to launch deployments in
>>> Conductor or will it be an optional part? ###
>>>
>>> We will need to see how stable and usable Heat is. How easy it is to
>>> deploy and keep up (it would be another dependency, after all) and how
>>> much benefit and code cleanup it brings to Aeolus.
>>
>>
>> I'd be in favour of keeping this optional for the time being. It sounds
>> like Heat would be a useful add on, but I'd rather keep the required
>> dependency set as small as possible. Even external components that are
>> currently in place should be made modular / pluggable: image management,
>> config servers, system engines, etc.
>>
>
> Yeah I understand what adding yet another service means complications.
>
> On the other hand, one of the main benefits I'm hoping for is the
> ability to drop a lot of the code that Conductor's using for dealing
> with these kinds of things.
>
> If we had to keep that and support Heat (or whatnot) at the same time,
> it may still be desirable but probably less so.
>
> On the other hand, I think there were talks about doing the whole
> instance launching business pluggable anyway. In that case Heat (or
> any other engine) could be swapped in and we'd have a leaner Conductor
> core.
>

Hrm yours and lutter's comments make me envision another rails plugin,
similar to IME but this time for Infrastructure Management and
Brokering, that way implementations such as heat, deltacloud, or another
w/ custom logic could be swapped in / out as desired.

Might be worth looking into, though I'm apprehensive about introducing
yet another component until we grow more of a community and/or host this
as a service.

  -Mo






More information about the aeolus-devel mailing list