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.