Aeolus Community Assessment

Angus Thomas athomas at redhat.com
Mon Jun 11 15:31:02 UTC 2012


On 06/07/2012 07:29 PM, Scott Seago wrote:
> 3) multi-instance deployment with service configuration, dependency 
> handling, etc
> 4) cross-cloud launching (i.e. take a user request to launch 
> something; figure out where to place it based on resource availability 
> and other business logic)
> (and possibly more)
>
> From the other replies to the thread I've seen various proposals that 
> essentially amounted to trying to take either 3) or 4) out and make it 
> a deltacloud plugin. I would suggest we start on the other side -- 
> again largely to allow incremental progress and to avoid a big 
> de-stabilizing massive integration which would inevitably result from 
> a ground-up rewrite. Basically we'd pick 3) or 4) and rewrite the 
> existing functionality using a rails engine. Create something 
> self-contained that would work on its own, but would still lend itself 
> to a fully-integrated conductor application much like we have now -- 
> but with two separate (smaller) codebases, one of which can be used 
> independently of the other. If there's something that conductor uses 
> internally now that we _also_ need as a deltacloud plugin, that could 
> be done too -- but again I'd say we should _start_ by making the 
> conductor component pluggable, and then refactor the plugin such that 
> it could be used in both deltacloud _and_ conductor.
>
> Most important in the above is that we avoid a ground-up rewrite all 
> at once. We take individual bits that already work in conductor and 
> refactor them to create a pluggable component and (possibly in some 
> cases) refactor to the point it can be used by deltacloud as well -- 
> but if we go the other way (starting with a new deltacloud plugin for 
> something that wasn't done in deltacloud before), then the integration 
> effort on the conductor side will be much more difficult.


One of the big advantages of this approach, I think, is that it 
incrementally builds on what we have.

As in the specific cases above, we should look for elements of 
functionality within Conductor which can be encapsulated in an engine. 
Doing that encapsulation ought to have the additional benefit of 
facilitating the implementation of new APIs from Conductor.

At the same time that we're incrementally segregating functional 
components within Conductor, we need, as discussed elsewhere in this 
thread, to do a better job of interacting with upstream communities. 
Nothing would serve so well to speed up and focus the process of 
splitting up Conductor's functionality into reusable discrete components 
as hearing from another project that they like our hardware profile 
matching, for example, and want to reuse it. Or, we might discover that 
our implementation is far worse than theirs, and that we should swap 
their code in place of ours.

Whichever way around it happened, we'd be evolving a segregated, 
modular, more maintainable codebase.

The case for a clean-site re-implementation is always going to be 
attractive, but it is risky.. We could spend time extracting logic from 
Conductor and putting more-or-less the same logic into Deltacloud, or 
anywhere else, but doing so would stall Conductor development, and would 
be open to the risk that we'd fail to get the new codebase to the point 
of maturity that the current code has already reached. Assuming that we 
succeeded, we'd reach the stage where we've matched today's 
functionality, with what we expected to be a superior architecture. The 
number of effective obstacles to community engagement upstream that we'd 
have removed in the process is debatable.

If we could agree that Conductor needs to be more modular, that gives us 
a direction of travel, and means that we don't need to attempt to solve 
all our architectural problems today.






More information about the aeolus-devel mailing list