On Wed, 2011-07-20 at 12:03 +0100, Angus Thomas wrote:
On 15/07/11 22:25, Hugh Brock wrote:
> Aeolus Orchestrator:
>
> * lets users specify a clump of images to launch and configure
> simultaneously. We want the user's specification to be human
> readable and portable
>
> * lets users specify values to collect at launch-time. The values
> will influence how the instances configure themselves, either by
> being interpolated into config snippets in the clump
> specification, or by being passed directly to the instance
> post-boot. Launch-time values mean the instances in a clump can be
> configured differently each time they are launched
>
> * lets users provide configuration parameters and tooling for each
> instance, to be injected and run at launch time. User-provided
> configuration tooling can do anything including install software
> packages, set config values, or start and stop services. Config
> tooling can be in any form that the user's image supports --
> puppet manifest, bash script, powershell script are all fine.
I'm not sure I understand the division between Conductor and
Orchestrator. The capabilities around supplying launch-time parameters
so that an instance will configure itself for a particular purpose by
installing software & starting services etc. are required just as much
to the launch of a single instance as it does to a clump of them.
It's a fair point, but I do think they're pretty closely related - e.g.
maybe you'd call it Orcheconfigurator or something :)
I keep comparing what we're doing here to Amazon's Cloudformations
stuff. And there, it's a completely standalone feature which addresses
both multi-instance launch and supplying parameters to instances at
launch time. It works well as a conceptual split IMHO
The main difference I see is that, in a multi-instance clump, the
instances may need a way to discover each other at launch time and
configure themselves to interact. That doesn't feel like a sufficiently
large difference to justify a logical separation between Conductor and
Orchestrator.
More clearly defining the scope of a project, so that the people working
on it are freed up from an over-complex design, and are able to move
forward on achieving specific goals would be beneficial, but I think
there's quite a bit more thinking required around where the divisions
ought to fall.
Putting it another way, if the logical division is between Conductor
itself and the config server and other components which enable boot-time
configuration of instances, then I think there's no point in also
differentiating between single intances and clumps of instances, since
their needs are very similar.
Again, because the concept of config server, audrey and deployables are
so intimately related and at such an early stage, I don't think we
really know where they are going to end up. I honestly think we'll give
ourselves a better chance of getting a good result here if they are able
to completely re-define themselves as they iterate.
Also, I don't see why they are so intimately tied up with conductor - we
should be trying to promote the Orchestrator concept as useful without
conductor - e.g. if you just want to have a cross-cloud version of
CloudFormations.
Cheers,
Mark.