On Mon, 2011-07-25 at 20:39 +0100, 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.
I disagree. Take cloud-init as an example:
This is one of the more interesting, practical and well-executed cloud
projects out there IMHO. Both Conductor and Orchestrator have at least
as much substance as that.
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.
Of course. But our multi-instance-launch and configure-instance-at-boot
are intimately related currently. Do you have a proposal for how they
could be separated or .... ?
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.
That's a pretty sad statement.
Conductor allows an admin to set up a self-service cloud portal where
users can use the resources of multiple clouds from the same UI. If
you're right and such a thing requires Audrey's features to be
interesting, then Conductor is just not interesting at all. But I do
believe Conductor is interesting in its own right.
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.
You know, after all this, I think you're actually only disagreeing with
a minor part of the proposal.
Here's all I'm saying:
- Deployable parsing and interpretation, config server and the audrey
guest agent could be a fairly self-contained effort under the
- At this early stage, keeping it fairly self-contained will give the
effort a better chance of success because it becomes easier to
iterate on the design.
- A bunch of the code Conductor needs for handling deployables and
talking to config sever should live in a library outside of
Conductor and developed as part of the Audrey effort.
- Audrey is interesting in its own right and should have its own
simple stateless API/UI server which you can run against any
- This is a subtly different way of thinking about Audrey. With the
benefit of hindsight, I think we integrated this stuff too early
into Conductor. If we had understood how both pieces could live
independently, I think we would have kept them separate until
the Audrey concept had proven itself out.
- Hindsight is one thing. Deciding that we should now remove
deployables again from Conductor is a whole different thing. I
think it's worth discussing once standalone Audrey is better
established, but it's certainly neither the first step nor
obviously the best choice.