I'm loving this thread 

We should target the misunderstood market of trendy bar dwelling virtualization & network engineers with this cryptic print-out campaign  http://me.ndftz.com/aeolus-blue.pdf

*kidding* 

But seriously,  there have been many legitimately valid points raised here and I soberingly offer my support to help get our message out.

Some thoughts on things that would be awesome:

• a public mock instance (with instrumentation & analytics) 
• a mock data mode for mentioned public instance and also for building our apps.
• scripted elevator pitch, 
• full scripted pitches based on various scenarios, 
• boilerplate slide deck, 
• an animated architectural summary video,  
• video & written walkthroughs
• a bit more personality —  i'd like to see developer bios with illustrated avatars, links to their twitter accounts etc. stuff that makes us more approachable.

I can help with many of these points but am seriously out of my depth with the first two.



On 08/06/2012, at 7:46 AM, Hugh O. Brock wrote:

On Thu, Jun 07, 2012 at 02:36:11PM -0700, Richard Su wrote:
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.

This is a fantastic idea Richard, and your comment on the website is
dead right.

What we want to do is get folks using what we have and what we
continue to develop in the API area particularly, so that we can have
some level of confidence that we are building something people will
want to use. Putting some scenarios together that show people how we
think they can use the software will help a lot.

--H



--
== Hugh Brock, hbrock@redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey