Aeolus Community Assessment

Richard Su rwsu at redhat.com
Thu Jun 7 21:36:11 UTC 2012


I think we have not made a good case on why someone would want to use 
aeolus. And how one would use the tools we have built to do something 
useful.

I agree with Jay that it is a bit troubling that we have built out so 
many features without direct feedback from customers/users/community to 
understand if there is a need for them. For the most part, we have laid 
the ground work with most of the most obvious features, so I do not 
think we have strayed too far. But instead of features, we ought to 
focus more on building solutions to specific problems that users need 
solving. Exactly which problems we aim to solve is something we need to 
get a better handle on.

Looking at what we have built thus far, it is difficult for me to see 
how it would be useful to a potential customer. Yes, we support EC2, 
RHEV, and vSphere and yes, you can build images and deploy them. But 
would someone really use what we have currently in a production 
environment. I would argue probably not.

Let us imagine you have a compute farm and are looking to deploy over a 
thousand instances to serve as compute nodes. You bought into the idea 
of having a hybrid cloud and plan to deploy most of the instances on a 
private cloud and in the event you need to speed up processing to meet 
deadlines, you would like to increase your throughput by bringing up 
nodes on a public cloud.

How well do the tools we have built meet that goal? Sure we can build 
and launch the instances from the Conductor UI. But if you're managing 
thousands of instances, the UI is likely not the tool you would be using 
primarily. If you're managing large number of instance you'll likely 
have your own tools to automate launching of instances if you see your 
throughput is not meeting set targets. We have recognized this as a 
limitation with Conductor and the recent focus on the api is good to 
see. But I think this is the type of analysis we should be doing.

To continue with the example, your environment would be heavily 
scripted. If an instance crashes, you would have scripts to 
automatically cleanup and relaunch. If it fails continously, ideally the 
system would be smart enough to alert you if a particular host is a 
trouble spot and it be placed offline for analysis (wishful thinking). 
For each instance, you would also like to have access to metrics like 
cpu, disk, and network utilization. These metrics would help you flag 
instance for analysis that aren't being fully utilized or at imminent 
risk of crashing; say your compute process hangs or servers who run the 
risk of crashing either from high load or low disk space.

To minimize cost, if more nodes on your private cloud are becoming idle 
because the jobs are finishing faster, you would like to know which ones 
and how many so that you can divert processing back internally and off 
of the public cloud and shut down instances on the public cloud.

What happens if a cloud provider goes offline? Can I script my way out 
of trouble? I like to be alerted when that happens so I don't send more 
compute requests to instances on that provider.

I think we are a good way there to meet the requirements for this user 
scenario. What we lack is ways to get metrics, provider state, and 
instance state information through an api to allow scripting.

Now that we have released a product, hopefully, we'll start to get more 
feedback on exactly what a customer is looking for. But in absence of 
such feedback, I think it would be useful for us to develop scenarios on 
our own like the one above in anticipation of how users would likely use 
aeolus. This would help to put more focus on what we develop.

Once we develop a portfolio of these scenarios, I think it will make it 
easier for us to explain why and how you should use aeolus and give 
users a better feel on its usefulness if they adopt this platform. 
aeolusproject.org explains what aeolus does, but it doesn't argue for 
why or how one would use aeolus.

- Richard




More information about the aeolus-devel mailing list