On 07/25/2011 09:39 PM, Angus Thomas wrote:
On 07/24/2011 07:44 PM, Hugh Brock wrote:
> Speaking of the whole Conductor/Orchestrator split. Mark and I got
> very excited about this because it seemed like there would be room for
> two smaller independent OSS projects there rather than one big hairy
> one. I've heard privately from various people however that they
> thought that split would leave Conductor as a not-all-that-interesting
> piece by itself, concerned only with cloud resource allocation and
> permissions (and some level of display of various things).
> How do folks out there feel about this? Can we have some debate here,
Carving up all the things that we want to achieve with aeolus, and
breaking it all up into manageable chunks, with goals which are
sufficiently tightly defined that they allow focussed discussions where
there's a shared understanding, would be a great help. We can't be
complacent about the problems of excessive complexity.
On the other hand, creating another app besides Conductor, which would
do some of the things which are currently intended to be done by
Conductor won't be helpful.
Specifically in the case of the proposal around Conductor&
Orchestrator, there simply isn't enough substance there to stand up two
independent applications, and have each of the be useful and interesting
- likely to draw a greater number of community contributions.
As I said in a previous thread, the requirement for the ability to
configure and customise instances on boot, to make them provide a
bespoke service, for example, is certainly compelling. However, it
applies just as much to a launch of a single instance as it does to the
simultaneous launch of multiple instances.
It would not help us to remove the configuration and customisation of
instances on boot, and support for multi-instance deployables, from the
Conductor application, because what that would leave, an app which can
only launch uncustomised images, one at a time, would no longer be
particularly useful or interesting. There are not credible user
scenarios where a user would be sufficiently sophisticated that they
require pool management, quotas and provider matching, but would not
need to have any of the instances which they launch be customised on
start up at all.
Given the investment of effort thus far in Conductor, in testing, in
creating the best new UI we can etc., this really isn't the time to
devalue it be taking extracting core functionality (albeit functionality
which is not yet implemented beyond a basic prototype).
In summary, I think we should continue to deliver the best application
we can in Conductor, and we shouldn't attempt to solve what is primarily
a problem of the most efficient way of organising developers by imposing
a sub-optimal design on the software we create. That feels like putting
the cart before the horse.
On the other hand, if Orchestrator were a subsystem of Conductor, then
the value of the application is preserved, and we could potentially get
some isolation and clarity around the development of support for complex
boot-time configuration of instances too.
There are several aspects of Conductor's functionality (provider
matching, monitoring etc.) which would lend themselves to implementation
in discrete loadable modules which could be developed semi-independently
and loaded into Conductor at runtime.
I agree with Angus. There should be one UI for launching both instances
and deployables. User should be able to configure instance or deployable
in same way, of course there is additional complexity for deployables,
but it's not a reason for building another standalone UI.
It makes sense to move all launch config stuff into separate
lib/subcomponent, but this should still be only backend used by conductor.