Brainstorming tasks for next sprint

Tzu-Mainn Chen tzumainn at redhat.com
Mon Feb 13 21:20:46 UTC 2012


Regarding b); I can see a reasonable use case where you might *not* want Conductor to figure out which cloud to use on its own, so I'd be careful of eliminating functionality there.  If we were to allow both behaviours, perhaps the right thing to do would be to create site-wide Conductor parameters, one of which would toggle the above.  Otherwise, I'd think that specific UIs would start getting too cluttered.

My own idea on what to focus on?  Documentation.  I think that we should reorganize the wiki to a) provide documentation appropriate to different levels of interest (high-level, CTO level, developer level), and to provide logical paths for people to read and explore.

In addition, I think that creating a "help" system within Conductor would be of huge benefit in getting new users comfortable with the system.

Mainn

----- Original Message -----
From: "Matt Wagner" <matt.wagner at redhat.com>
To: aeolus-devel at lists.fedorahosted.org
Sent: Monday, February 13, 2012 4:06:24 PM
Subject: Brainstorming tasks for next sprint

Hi all,

As we start to wrap up bug-fixing, I was hoping to get a conversation
going about what we need to tackle in upcoming sprints.

Two things I think would be well-worth pursuing:

a.) Actual OpenStack support. We (ostensibly) support Rackspace today,
so this may be relatively straightforward. (Or those could be famous
last words.) I think this is important for two reasons. The first is
that OpenStack is a popular private-cloud offering, so we should support
it alongside vSphere and RHEV. (It might also help those who keep trying
to compare us *to* OpenStack understand that we occupy different
spaces.) 

The second is that OpenStack powers several public clouds, and it would
be fantastic if EC2 wasn't the only public cloud we supported. Obviously
Rackspace's offering is using OpenStack or something extremely close.
But Internap's Open Public Cloud[1] and HP's new HP Cloud are powered by
OpenStack, so OpenStack support would get us compatibility with multiple
public cloud providers.

b.) Smarter matching of where we launch instances. I don't think this
will be something we get right the first time -- it seems like there are
a bunch of criteria that different people will weigh differently. But I
think that's all the more reason to start out with something now and
iterate over it. Our 'priority' concept helps somewhat, but it still
feels pretty constrained. It feels like we've worked to make it easy to
launch an instance in the cloud of your choosing (a noble enough goal, I
admit), as opposed to allowing you to launch an instance and let
Conductor do something intelligent on its own.

What else do you think we should try to focus on?

-- Matt


[1]
http://www.internap.com/flexible-cloud-hosting-solutions/enterprise-public-cloud-solutions/open-public-cloud-solutions/
[2] http://www.hpcloud.com/http://www.hpcloud.com/



More information about the aeolus-devel mailing list