From: David Lutterkort lutter@redhat.com Date: Mon, 08 Aug 2011 17:05:46 -0700
On Wed, 2011-07-27 at 18:10 -0400, Joseph VLcek wrote:
Greg Blomquist and I have put together an Audrey design document for the 0.4.0 effort.
It can be found here: http://www.aeolusproject.org/page/Audrey-Conductor_Integration_0.4.0
This is mostly to recap a conversation I've had with Joe and jrd: from what I've read (and heard) about Audrey, it's main purpose is bootstrapping a cloud instance into a management system.
I think that's a very interesting use case, but not the only one.
Audrey is clearly intended to accomodate the case where the only configuration needed is enough to get whatever local agent(s) talking to their mother ships.
It's also intended to be sufficiently general purpose to allow users to stick whatever scripts or other tools they want in there, so that they can do the big-hairy-perl-script solution if they choose, or any other permutation. IOW, it's explicitly a non goal to say "You, Ms User, are required to use some more complex central-server-based config system in order to get your instances set up".
In addition, we're trying to think ahead and leave room for non-cloud-centric schemes. We've heard from customers as well as folks in the platform group at RH that they like the idea of metadata describing a "machine" and how it gets started up. So while it's the case that it has "cloud" tattooed on its forehead now, it may not always. [...]
From: Greg Blomquist gblomqui@redhat.com Date: Mon, 8 Aug 2011 20:36:56 -0400 (EDT)
[...]
We should really just stick with two simple use cases with Audrey: 1. Bootstrap management infrastructure 2. Configure instances with scripts if user does not use/want more elaborate mgmt infrastructure
The more I think about how all these pieces of Aeolus will have to play together, the more I start to think that just the top-level scripts are sufficient.
I don't think I buy that, at least not yet. I'll grant you that for the very simple cases with which we've been prototyping, a single script is way easier to understand and implement. I believe, unless we discover that real users really *do* want to gravitate toward more structured startup scenarios, that we're going to find a bunch of people wanting to go their own way, even within an instance. And therefore forcing them to cram it all into one script is going to be a mess.
So I advocate not making that decision until we have more concrete examples to work with. [...]
I agree and still want this. The original idea was that the data being passed from Conf server to client was a simple list of key value pairs. It seems to me that we've moved beyond that concept.
Again, let's get further along before we decide that. If we get there and discover that there are no cases where you just want generic parameters, with an optional interpreter for them, that's fine, we can simplify.