Aeolus Community Assessment

Michael Orazi morazi at redhat.com
Thu Jun 7 17:37:54 UTC 2012



----- Original Message -----
> On Mon, 2012-06-04 at 15:39 -0400, Chris Alfonso wrote:
> 
> > markmc made a few suggestions to address making aeolus components
> > more useful to the masses
> 
> > (1) Credentials delegation plugin for deltacloud
> > (2) Notifications of interesting deltacloud events
> > (3) Track resource ownership
> > (4) Add instance state change event notifications
> > (4) Add per-user quotas
> > (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
> 
> I feel like I need to defend myself here a bit :)
> 
> This conversation went like
> 
>   Let's think about how we could build Aeolus's fundamental feature
>   set
>   from the ground up as individually interesting projects
> 
>   Well, (1) is interesting in its own right (see my other mail about
>   an
>   EC2 proxy which allows you to share usage of credentials)
> 
>   Also, (2) is useful on its own
> 
>   To extend (1) a bit more, you'd add policy and quotas around how
>   individual users could use the shared credential
> 
>   A devil's advocate asks - wait, how do you implement quotas?
> 
>   Well, you could combine (1) and (2) and do funky stuff to track how
>   much of their quota people have used. Hence (3), (4) and (4)
> 
>   Let's not get get rat-holed on quotas! They're a safety limit!
>   Chargeback is actually the more useful feature and (2) enables
>   that.
> 
>   (5) is an obvious extension to (1) if (1) proves interesting to
>   people
> 
>   (6) is where you're getting really funky, so let's not predict how
>   that would pan out other than to say we could experiment with it as
>   a
>   further extension to (1)
> 
>   (7) shows how (1) and its extensions suddenly gets very useful if
>   you're building stuff on top of deltacloud
> 
> So, while it might come across as "here's a new top-down architecture
> proposal", I actually intended it to be more like "how would we
> implement a bunch of Aeolus's interesting features using a
> start-small-and-iterate-based-on-feedback model?". The same model
> that
> Jay describes so well.
> 
> Cheers,
> Mark.
> 
> 

Apols for being slow in responding...  When this originally went around I put together a response but never hit send.  This turned out to be rather good because a lot of folks jumped in and said things in a much better way than I did.  Given the good input so far, I still wanted to express some thoughts/concerns.

I like a lot of the architectural ideas you proposed in terms of small things that are of interest.  I have to admit that when I saw the indications that individual services (and in some cases plugins) would want to have DB, I started rat holing down some practical concerns like:
- as we add more individual data stores even describing a multi-node installation gets more and more difficult (this may reduce to significantly less of a concern at the project level)
- I was getting pretty nifty flashbacks to installing/debugging things around iwhd/mongo in the early days when we had less of a handle on mongo (and a less stable version to boot)
- when we start doing complicated things across data sources, we need to tackle potential 2 phase commit issues in some fashion whenever things ought to happen transactionally

Given the strong response on the thread that a lot of this functionality feels like it belongs in conductor, it drove home the point again that we've been treating the API/cli as a second-class citizen for entirely too long.  Perhaps part of the solution is simply more aggressively focusing on making the things we currently have available as RESTful endpoints and providing a decent cli + some programming examples to help get folks started.  As the first small handful of steps, we have the image engine mentioned earlier in the thread and some services around surfacing providers via API so we can make it easier to do initial customer Aeolus set up type CRUD.

The other big +1 I see is that in all the cases you point out, they seem like really good candidates to give a really close look and see how tightly or loosely coupled they are currently.  Being ready/able to split things out, tends to make them considerably more testable and usable in my experience.

Thanks,
Mike









More information about the aeolus-devel mailing list