Aeolus Community Assessment

Mark McLoughlin markmc at redhat.com
Thu Jun 7 16:48:56 UTC 2012


Hey,

I don't contribute to the project any more, so I'm reluctant to get in
too deep ... but here are a few thoughts for whatever they're worth

On Mon, 2012-06-04 at 15:39 -0400, Chris Alfonso wrote:

Oh, first - nice mail Chris - you've kicked off a hugely important
discussion IMHO

> Problem Statement:
> Aeolus projects upstream community is Red Hat, full stop.
> 
[..]
> 
> Quickly, the value proposition of having a community (Why it matters that we create a community)[1]:
> * Security
> * Affordability
> * Transparency
> * Perpetuity
> * Interoperablity
> * Localization

I'd add innovation - healthy open-source projects often go off in
directions that are entirely unanticipated by their founders. Aeolus
really is trying to break new ground (it's not cloning EC2 or UNIX) so I
think having the project open to real innovation is even more important.

[..]
> Typical paths to a successfull community
> - Seed the project development[3]
> - Get feedback from early and often releases[3]
> - Attract users of the software[2]
> - Attract developers[2]
> - Letting go[2]

Also:

  - enabling an ecosystem of diverse interests
  - truly open, meritocratic design and development
  - a compelling mission that people can buy into

[..]
> 
> - First, did we build something that is useful, I say yes.

Aeolus has built a lot of useful stuff.

I could totally see people wanting:

  - a way to set up an EC2 API proxy server, give it my EC2 credentials
    and give other people access to the proxy server, impose quotas on 
    their usage, do chargeback, etc.

  - an extension to this where I can add credentials for other cloud 
    providers too

  - a way to launch multiple instances together on OpenStack and 
    configure them to talk to each other, hook them into a
    configuration management system, etc. (ala AWS Cloud Formations)[1]

  - a way to build images of different distros for e.g. OpenStack[2]

  - a way to efficiently get notifications (e.g. via websockets or 
    AMQP) of what's happening my instances on EC2

  - a way of making the same (roughly) image available in multiple 
    clouds and rebuild it as needed

Aeolus does - or almost does - all of this. Yet if your best friend came
to and said "I want to be able to do foo" - where foo is any of the
above - would you really feel right about saying "Aeolus is *perfect*
for you!".

Aeolus doesn't have a perfect solution for any of those use cases, but
it could be!

> However, we built something that is less useful than using most cloud
> provider management tools directly (because we went for the common
> denominator feature/api base).

I don't think that's necessarily a fundamental problem. The common
dominator abstraction gives portability and people understand that. But
I think a lesson can be learned from libvirt which allows you to use
hypervisor-specific features through the abstraction, thereby giving you
the choice to limit your portability.

Another example is Puppet - the abstraction is similarly limiting, but
you're welcome to punch through the abstraction (and lose portability)
if you need to.

Cheers,
Mark.

[1] - http://wiki.openstack.org/Heat
[2] - https://github.com/rackerjoe/oz-image-build




More information about the aeolus-devel mailing list