From: David Lutterkort <lutter(a)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
> It can be found here:
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
From: Greg Blomquist <gblomqui(a)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
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