On 08/09/2011 09:33 AM, John R. Dunning wrote:
> 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
> > 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
Before we ever begin to tackle this scenario, this description has to
undergo several revisions to reach any acceptable level of clarity.
> 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
Well, the top-level tooling supports this already. They can have a
single top-level script and any arbitrary list of files that can also be
specified in the current "tooling" xml element.
This arbitrary list of files can contain additional scripts to be
executed. There's nothing preventing that. The only requirement on the
user is that their top-level script has to be the one to call execute
these additional scripts. In other words, Audrey doesn't execute the
scripts for them.
So, if the only argument for services is that people might not want to
cram all the scriptage into a single file, they don't have to. What I'm
not getting is the use case that drives the need for services.
So, let's talk about the use cases. We have a couple of use cases that
I know about. In brief, they look like:
1) bootstrap a system to an existing arbitrary management platform
- system means, specifically in the first go-round, a guest
- bootstrap can be generalized to "execute some arbitrary code"
- management platform includes things like JON, Katello, or even a
lower level config management system like puppet or chef
2) provide a simple means of executing scripts on a system
- again, system means guest here for now
Both of these can be accomplished with the top-level tooling setup.
If the implementation of either #1 or #2 involves supporting the concept
of services, I think there are implicit use cases that are added to this
list. But, I don't know what those use cases are. So, I'm not
altogether sure what we're actually supposed to support with the
For instance, in one of David's examples he indicated that it would be
nice (and probably a natural extension) to be able to provide the
ability to build in service dependency management. In other words, it
could become not enough to provide simple service ordering. It might be
necessary to provide actual service dependencies. Is that a use case?
What other use cases exist for services? Either those that drive the
need for services, or those that come about by including services...
So I advocate not making that decision until we have more concrete
examples to work with.
What are the concrete examples that support the need for services above
and beyond the need for top-level tooling?
> 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
I'm not as on fire about this. In the end, the format of the data
passed between the config server and the instance is something that only
the config server and instance need to worry about. It can be as
complicated or simple as we want it to be. However, as soon as we say
that some other tool has to parse this format, this will need to change
to be more generally consumable.