On 26/07/11 09:30, Mark McLoughlin wrote:
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,
>> 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.
I disagree. Take cloud-init as an example:
https://help.ubuntu.com/community/CloudInit
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 .... ?
I don't think that separating them is the problem
that needs to be solved.
We could achieve multi-instance launch without having any boot time
configuration of instances at all.
Conversely, by focussing on solving the problems around boot-time
configuration for single instances, and forgetting about multi-instance
deployables, we could achieve most of the goals in that area too.
The only added complexity that arises by putting multi-instance launch
and boot time configuration together is that we'll want the ability to
use the boot-time configuration scripts to tell instances in the same
deployable about each other. That will present some challenges around
the order in which instances can be launched, and the means of
retrieving parameters from one instance and passing them to another.
That feels like the kind of problem we should be solving last, once
we've already dealt with the simpler boot-time configuration and
multi-instance launch cases.
> 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.
There's no cause for sadness about acknowledging that Conductor
depending on Audrey for most interesting use cases. It depends on
imagefactory, iwhd and condor too, to varying extents.
My concern is about what was referred to at the head of this thread as
"the whole Conductor/Orchestrator split"
There's no upside to presenting users with two applications, one of
which can launch instances, and the other of which suddenly becomes
required as soon as more than one instance is going to be launched, or a
boot-time script needs to be deployed.
If nobody is advocating an Orchestrator application, which users would
interact with instead of Conductor in those cases, then I'm happy.
> 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.
I hope I've clarified what I'm disagreeing
with above. I also hope that
it was only ever a minor part of the proposal, if it was a part at all.
I'm certainly not disagreeing with most of what is below.
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
Aeolus umbrella.
- 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
deltacloud instance.
- 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.
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel