On 08/09/2011 09:33 AM, John R. Dunning wrote:
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.
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@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.
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 implementation.
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 simplify.
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.