Aeolus Community Assessment

Jan Provaznik jprovazn at redhat.com
Thu Jun 7 06:44:05 UTC 2012


On 06/04/2012 09:39 PM, Chris Alfonso wrote:
> Problem Statement:
> Aeolus projects upstream community is Red Hat, full stop.
>
> It's probably too easy to get caught up in hand waving and just say
> "it's important to have a healthy upstream aeolus community." I've been
> thinking a lot about what the benefits really are to having a "healthy"
> community, and what it means to be such. I want to keep this real and
> not go all academic, but I will add references to really smart people's
> research and perspective to add some sort of credibility (because you
> guys know I keep booze at my desk and as such might think I've already
> started the weekend).
>
> /me pours a shot.
>
> Quickly, the value proposition of having a community (Why it matters
> that we create a community)[1]:
> * Security
> * Affordability
> * Transparency
> * Perpetuity
> * Interoperablity
> * Localization
>
> A thriving, healthy open source community is one that yields the value
> proposition listed above. Just throwing a license header in project and
> making it available for the masses to download is not the blueprint to
> building a community. All this does is make the project source code
> 'open'. Without a community, there simply is no project [2].
> Furthermore, we can formulate how the Aeolus projects reach the
> mountain-top that is a vibrant open source community - if we agree on
> the value proposition listed above as the output of a thriving, healthy
> community.
>
> 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]
>
> We, as a Red Hat sponsored group of hooligans, and I mean that in the
> most affectionate way possible, have done a tremendous job seeding the
> aeolus projects. We've created a metric ton of feature and function. So
> if we've built some pretty cool features...why aren't they coming[5]?
> It's necessary to address each of the factors at some point, but I'm
> just going to focus on how we attract users and developers in this mail.
> I think we need to ask ourselves some tough questions and be honest with
> our answers.
>
> 1. Are we building function and feature that people want (individuals,
> entreprenuers, enterprises) to use? If so, is the barrier to setup and
> use aelous low or high?
> 2. How easy is it for developers to get involved and understand the
> components involved and then debug, path, contribute changes?
> 3. Are we doing a good job letting our target users know aeolus exists?
>
> There are plenty more questions we can analyze to come up with a self
> evaluation, but I think the above 3 are sufficient for this already too
> long email.
> - First, did we build something that is useful, I say yes. 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). There are some scenarios in which aeolus is easy to
> setup, and there are others that are mindblowingly difficult and
> confusing. The learning curve for an admin and a user is fairly steep as
> well. If you don't believe me, you probably didn't hang out in the SA
> training classes, or you started working on the projects at their
> inception and have become blind to the complexities, or you've never had
> the floppyinject-hook have its way with you!
>
> - Second, all aeolus developers are Red Hat folks. There are probably a
> number of reasons for this: perhaps the components that make up aeolus
> don't lend themselves well enough to reuse in other projects, they
> aren't puzzle pieces that can be plugged in to solve any other problem
> than what we've decided to solve. The design priniciples of each of the
> projects differ from one another. The languages themselves used between
> the projects are different. The frameworks used between the projects are
> different. The protocols used between the projects are different. What
> we've done is create an enormous learning curve for any developer that
> dares to take on the challenge of contributing (and they haven't even
> looked at the development process guidelines at this point).
>
> - Third, we have folks go to a user group here and there, *I think*.
> Developers aren't good salesmen or ad-men, in general. Since we are not
> creating a market with aeolus, we are way behind a lot of other projects
> in this space, we had probably better pony up and do a much better job
> letting folks know aeolus exists and is here to take down the
> competition, because we're better than them! We need to get a fleet of
> folks traveling to trade-shows, meetups, usergroups, conferences. Put
> together consistent, professional marketing materials and get it in
> people's faces.
>
> markmc made a few suggestions to address making aeolus components more
> useful to the masses, and I tend to agree they are great places to start
> aeolus components without having to setup all the infrastructure.
>
> (1) Credentials delegation plugin for deltacloud
>
> Add a plugin interface to deltacloud which enables credential re-mapping.
> Write a plugin which authenticates the incoming user against its own
> user DB and grants any valid user access to a configured set of
> credentials
> The idea here is to allow deltacloud to be used as a proxy by which
> someone can share access to a set of credentials with others, without
> actually sharing the credentials themselves
>
> (2) Notifications of interesting deltacloud events
> Add a plugin interface which is called with details of any interesting
> events happening in deltacloud.
> Provide plugins for publishing those notifications over Qpid, RabbitMQ,
> ZeroMQ, syslog, etc.
> The idea here is that the person sharing their credentials can use this
> notifications system to do chargeback
>
> (3) Track resource ownership
> If user A launches an instance via the credential re-mapping plugin,
> then user B should not be able to see the instance or kill it.
> Requires the plugin to have a DB which tracks the ownership of instances
>
> (4) Add instance state change event notifications
> There should be a way to have a service monitor clouds (via deltacloud)
> for the state of an instance and notify you of changes via a message
> bus.
> Is this external to deltacloud, just polling via deltacloud? If so, what
> credentials is it using to do the polling?
> Is it part of the credential re-mapping plugin, since that has access to
> credentials? But surely this is useful even if you're not using
> credential re-mapping? Does it publish these state changes via the same
> mechanism as
> deltacloud's notification system?
>
> (4) Add per-user quotas
> The admin sharing a set of credentials should be able to set quotas on
> each of the user accounts. This is for safety sake, not as a replacement
> for chargeback.
> The plugin needs to listen for instance launch notifications and
> instance state change notifications in order to update the quota usage
> of each user.
>
> (5) Extend (1) to support credentials for multiple drivers/providers
>
> (6) Experiment with ways for deltacloud (via a plugin or driver) to map
> incoming requests to one of multiple clouds
>
> (7) Explore using Heat on top of deltacloud
>
> Suggested Actions:
> 1 - take one some of the suggested architectural changes that make the
> aeolus components more reusable in projects outside aeolus as a whole
> 2 - set up a schedule to start marketing the components and aeolus as a
> whole, go out and get community members instead of waiting for them to
> show up
>
> If you think this is bonkers or if you have any other opinions on how we
> can better foster the community, let's hear it.
>
> Thanks,
>
> Chris
>
> [1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1656616
> [2]
> http://www.oss-watch.ac.uk/resources/howtobuildcommunity.xml#body.1_div.3
> [3] www.feedbooks.com/book/4285.pdf (The Cathedral and the Bazaar)
> [4]
> http://michaeldehaan.net/post/21881841161/my-working-theory-of-open-source-project-leadership
>
> [5] http://en.wikipedia.org/wiki/Field_of_Dreams

Hm, it seems my mail wasn't delivered to aeolus-devel yesterday, 
resending it...


Hi Chris,
It would be best to get the answer on "What are biggest blockers for 
community" from community, but since Aeolus community is... not big, 
it's up to us to do initial step - thanks for opening this topic.

What I don't agree with is doing some architecture changes because of 
hoping we attract some ppl. First, I'm not convinced that the Aeolus 
would become simpler and second I don't believe this is a blocker. I 
would say that most people don't even get to this level (where they look 
at Aeolus architecture). True is that some architecture changes 
mentioned in your list are already happening as mentioned in other replies.

As you said, we should let people know that Aeolus exists which we 
probably don't do loud enough. Also we should offer them easy way how to 
try it. But installing Aeolus on non-rpm systems (and non-rpm systems 
are majority) is pretty difficult. I don't think many people pass 
through this level. So one of first steps would be creation of general 
.tar.gz package(s) which can be installed on any distro (+some 
installation script like aeolus-configure).


Jan



More information about the aeolus-devel mailing list