RFC: Integrating Aeolus with Heat

Tomas Sedovic tsedovic at redhat.com
Tue Aug 28 12:04:55 UTC 2012


On 08/27/2012 06:16 PM, Mo Morsi wrote:
> On 08/21/2012 12:15 PM, Tomas Sedovic wrote:
>> Hey Folks,
>>
>> I've been contributing to the Heat project lately and I think it's
>> gotten to a point where we (the Aeolus community) could look at it and
>> figure out if it's something we want to use.
>>
>> Please forgive me the length of this email. I tried to make it as
>> short but there's a lot to cover. Grab your favourite beverage and sit
>> comfortably.
>>
>>
>> A little background
>> -------------------
>>
>> Heat is a project that provides orchestration and high availability to
>> OpenStack. Its API is modelled after Amazon CloudFormation.
>>
>> What it does in Aeolus' terms is: you create a deployable and pass it
>> to Heat API along with any launch-time parameters. Heat will decide on
>> the correct order of the resources (instances, databases, load
>> balancers, remote storage, floating IP addresses, etc.) and launches
>> and configures the whole thing to produce a running deployment.
>>
>> Heat started about five months ago and hopes to become one of the core
>> OpenStack components. It's written in Python following the OpenStack
>> development model and tools.
>
> Is Heat implemented as a centralized python service? How does the user
> currently invoke that service and how does the service in return managed
> the openstack components?

Yes, it's a centralized python service.

The user communicates with Heat using the CloudFormation API over HTTP.

They can also use a command-line client tool that Heat provides or any 
library that understands AWS CloudFormation and has a configurable entry 
point.

The OpenStack components internally communicate via AMQP and they all 
have their own HTTP APIs and python client libraries. Heat is currently 
using the client libs which in turn call the HTTP API.

>
> Is there a hard dependency of openstack in heat? Will that be removed /
> made optional when the deltacloud backend is in place?

There is at the moment but Ian and I are confident that we can remove 
those dependencies when the Deltacloud backend is in. The proof of 
concept that we're working on doesn't depend on OpenStack running or 
even being installed.

However, the Heat code uses exceptions imported from the 
python-novaclient lib so right now that needs to be installed as well. I 
mentioned dealing with that in another point in the original email.

>
>
>>
>>
>> What's this to do with Aeolus?
>> ------------------------------
>>
>> We're trying to solve some of the same problems:
>>
>> * launching multiple instances in correct order
>> * passing parameters that are only known when an instance is launched
>> * configuring and advertising the services running inside the VMs
>
> Does Heat require anything to be installed on the instances themselves?

It does not if all you're interested in is launching of instances.

If you want to do post-boot configuration or service monitoring, you 
need to have cloud-init and cfntools installed.

Cloud-init is a set of tools for handling configuring instances and 
running scripts passed into userdata. It's packaged for Fedora and 
Ubuntu (don't know about other distros)

https://launchpad.net/cloud-init/

cfntools build on cloud-init and provide a couple of features to better 
integrate with Heat. Eventually, Heat devs want to merge this to cloud-init.

This is analogous to Audrey's VM agent -- you don't need it but if you 
have it, you can do more cool stuff.

>
>
>
>>
>> If we could outsource this to a project whose sole focus is solving
>> these issues, we could focus on things that make Aeolus unique:
>> building great UI, tools and APIs for managing cross-cloud deployments.
>>
>> As a side benefit, we would get the current and future features of
>> Heat for free:
>>
>> * high availability
>> * auto-scaling
>> * load-balancing
>>
>
> <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.

>
> Supporting multiple deployable formats would be a nice feature in either
> application but obviously puts a burden on the developers / testers /
> etc. I'm not 100% familiar w/ the intricacies of the formats, but if
> they are simple enough and map well enough to each other, a barebones
> utility to do the conversion may be optimal for the time being.
>

I agree.

>
>
>>
>>
>> ### Heat-Conductor communication ###
>>
>> Heat is working on implementing a proper RESTful API that will
>>
>> 1) be more consistent with other OpenStack components
>> 2) suck less
>>
>> Once that's done, Conductor should probably adopt this API.
>>
>> We then need to figure out how to pass data from Heat back to
>> Conductor. If Conductor's launching instances via Heat, how does that
>> information get updated?
>>
>> 1) Conductor asks Heat every time it needs the data
>>
>> 2) Conductor asks Heat periodically and caches the results
>>
>> 3) Heat allows Conductor to register a callback -- either via HTTP
>> (webhooks) or via RPC -- and tells Conductor when stuff happens (e.g.
>> an instance was launched, crashed, etc.)
>>
>> 4) Conductor continues to use DBomatic to query the instances directly
>> via Deltacloud, ignoring any additional information Heat may provide
>>
>> For the proof of concept, everything other than 1) is a premature
>> optimization and then we'll see.
>>
>> I think 4) would be rather brittle especially since adopting Heat
>> might possibly let us drop DBomatic entirely.
>
> Some of this reminds me of condor, we were using that for a while in
> sort of an orchestration manner. It was responsible for tracking the
> lifetimes of instances on different cloud providers and dbomatic was
> initially written to track events through condor logs. It seems the
> level of abstraction is a bit different as Heat represents resources
> using the openstack model.
>

If this turns out to be another Condor (I mean the situation with 
regards to Aeolus, not the tool itself) then we're not going to use it. 
At least Heat has an actual API that Aeolus can use.

The way Heat represents resources is closer to Aeolus than OpenStack. 
Heat's interface is very similar to CloudFormation, which in turn is 
quite analogous to the way Aeolus works.

They both work with clumps of related instances, parameters and services 
that you can pass to them for configuration, a declarative template 
describing the clump, etc.

Resource-wise, OpenStack is to Heat what Deltacloud is to Aeolus (but 
don't take that analogy too far).

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

>     -Mo
>




More information about the aeolus-devel mailing list