Brainstorming tasks for next sprint

Greg Blomquist gblomqui at redhat.com
Thu Mar 15 13:15:21 UTC 2012


On 02/13/2012 04: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?

What about additional reporting and monitoring? (didn't see this in the
thread yet)

Specifically, I'm thinking about how Audrey can provide configuration
status of individual VMs.  But, I think Conductor would have to grab
that data and surface that data to the user.  We're currently trying to
record the data points we believe that Audrey can capture:
https://www.aeolusproject.org/redmine/projects/audrey/wiki/Audrey_Reporting

But, I'm sure there are tons of other data points to present.

Are there rails reporting frameworks that anyone has worked with in the
past?  Have monitoring and reporting been discussed as features for
Conductor?

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