Brainstorming tasks for next sprint

Steven Dake sdake at redhat.com
Tue Feb 14 16:27:04 UTC 2012


On 02/13/2012 02:06 PM, Matt Wagner wrote:
> 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
> 
Matt,

At some point in the near future I'd like to have a conversation about
adding multi-instance deployables, high availability, and vm start
ordering using pacemaker-cloud software APIs.

This fits in well with the idea of your proposed scheduler changes.  As
part of aeolus scheduling, aeolus could tell pacemaker-cloud which cloud
to deploy on, and pacemaker cloud would execute the process of actually
deploying.  This leaves scheduling in the domain of aeolus.

Regards
-steve


> 
> [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