Re: Release 0.4.0 planning, revision 2
Angus Thomas
Monday, 25 July 2011 Mon, 25 Jul '11
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, please?
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. Angus