RFC feature planning - robust instance launching

Tomas Sedovic tsedovic at redhat.com
Wed Mar 28 15:53:08 UTC 2012


On 03/28/2012 05:16 PM, Matt Wagner wrote:
> On Wed, Mar 28, 2012 at 04:55:10PM +0200, Tomas Sedovic wrote:
>> Hey Matt,
>>
>> Heat's goal is to take care of orchestration and high availability
>> concerns when launching deployments in the cloud.
>>
>> Essentially, you feed it a CloudFormations or TOSCA template, it will
>> figure out the proper order in which to start the instances and make
>> sure the services inside them are configured and launched properly.
>
> Ah, interesting. How much does this overlap with what Audrey does?

I'm not really sure about that.

Greg Blomquist (of Audrey) is in the #heat channel (freenode) so feel 
free to drop in and ask the guys there.

I can do that later. We'll probably send an introduction email here so 
people know what's going on.

>
>> It will also take care of monitoring the deployments and keeping them up.
>
> So this much works without Conductor? We would feed Heat a template of
> some sort describing the deployment, and it would restart things that
> failed?
>
>> We hope to integrate Heat into OpenStack but since it's going to be a
>> daemon with a web-accessible API, there's no reason why Aeolus can't
>> use it as well.
>
> Does Heat require actually using OpenStack, or is it just an affiliated
> project?
>
> Similarly -- are we viewing Heat as something that would be a required
> component of Aeolus long-term, or just as an optional add-on?
>
> Note that these questions are all just out of curiosity, really; I don't
> mean to imply that I have strong opinions about how any of this fits
> together.
>
> -- Matt

Right now the code is in flux. I think it does require OpenStack at the 
moment but it's barely in the proof-of-concept stage. But we definitely 
want to be provider-independent.

Since Heat should be able to do all the heavy-lifting when it comes to 
launching deployments, it sounds reasonable for Conductor to delegate 
the job there.

It would mean Yet Another Dependency with all the associated 
complexities. Plus at this point it's not 100% clear how much aligned 
Conductor's and Heat's goals are.

I want to make this clear though:

Heat is not Aeolus. At least not right now. Nobody's forcing Heat on 
Aeolus. If it's a good fit and the Aeolus community would benefit from 
it, super.

If not, that's all right, too.

If Aeolus people think this may be something they'd like to use and want 
to make sure Heat is actually usable with Aeolus, they should join #heat 
on freenode, subscribe to Heat's mailing list, check out the source and 
participate in the discussion.

Maybe it makes sense to put Heat through Aeolus incubation later on. 
That depends on you as much as on us.


side note: this feels *extremely* schizophrenic to write as I'm 
currently involved in both projects...



More information about the aeolus-devel mailing list