David,
Thanks so much for sending this! I wanna address a couple of questions right away, and
give more feedback when I'm not typing on my phone. :)
On Aug 8, 2011, at 8:05 PM, David Lutterkort <lutter(a)redhat.com> wrote:
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. That management
system may be any of a number of popular solutions, like JON, puppet,
chef, cfengine, ... or something homegrown, or just a couple of Perl
scripts that do the right thing.
In that sense, Audrey plays a similar role for cloud as cobbler pays for
physical boots, or to be more precise, as %post scripts play in some
kickstart files that sometimes are used with cobbler.
On top of the bootstrapping task of Audrey, there's a desire to provide
some middle ground between the magic Perl script to manage configuration
and a fullblown config mgmt system. The big use case that Audrey tries
to address in this space is organizational separation of roles for
different parts of a machines config (think: DB group sets up databases,
platform group sets up JBoss, app group sets up .war delivering app)
That's the bit about this writeup that doesn't sit right with me; for
one, calling those components 'services' is very confusing, since the
Service XML really just talks about a script, a few files, and
parameters for the script. Something generic like 'bundle' or
'component' would be less confusing.
The bigger issue with this is though that the above use case can already
be addressed with the assembly-wide config bundle (<tooling> in the
writeup) - just use a script that executes downloaded files in turn, and
make the role-specific scripts files that get downloaded to the
instance.
To really address separation-of-roles as a use case, there are some
obvious feature requests that would need to be added to make this really
fly: first off, instead of copying <service/> elements across lots of
assemblies (think: n different assemblies that all need to run JBoss),
you'd want to get the <service/> content from a repository; second, once
you've got your JBoss service description working, you'll want to tweak
it for different scenarios (small app vs. memory-hungry app vs. app that
needs memcached), i.e., have a way to create a new <service/> based on
an existing one. With that, we're halfway down the road to a config mgmt
system, but one based on script execution, not on should-state
description; that has the risk of horrible interactions between
different services, that can not be caught by the tool, since it only
deals in opaque scripts.
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.
There's a lot more to discuss here, but, like I said...when I'm not typing on a
phone.
Incidentally, both these use cases can be addressed with the
assembly-wide <tooling> section; all it needs is the ability to specify
a user-defined script, additional files to download, and parameters for
the script. Sticking to one assembly-wide tooling section would greatly
simplify this doc, and the implementation of the config server.
Some more random questions from reading the writeup:
* Can users influence where downloaded files go ? Will there be a
conflict if two file's URLs have basename 'stuff.txt' ?
Not at the moment, but I've been toying with the idea of adding a path (or something)
attribute which tells where the downloaded file should go in the tarball.
* To make it possible to pass more structured data as
parameters
in the future, Audrey should also make the parameters available
in a YAML or similar file on the instance, and point to that
setting an env var; a YAML or JSON file would most likely also
be the preferred way to pass params into anything that's not a
bash script (but Python or Ruby)
* What about permissions, ownership etc. of downloaded files ? If
the downloaded files are the instance's private ssh keys, you
don't want them to be world readable ever.
True. Joe might be be able to shed a little more light here, but as far as I know
we're not currently handling file permissions in any way.
* What about more complex file-download scenarios (e.g.,
cloning
directories/directory trees from a remote server) ?
Hmm...this might work over FTP, but not sure with Http urls.
* I don't understand the section 'Building user provided
config
tooling into an image'
* The encoding of parameters before sending them to the instance
is very adhoc, and full of nasty corner cases (how do I pass
'S&P says "we know"' as a parameter ?) It would be simpler
and
more robust to use a standard mechanism for serializing data
(YAML/JSON/XML/whatever) and sticking that as a special file
into the tarball
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.
* Is an API for the config server planned ? It would probably
be
helpful if that supported queries like 'what were the parameters
that were sent to instance <UUID>' or 'what files were sent to
instance <UUID>'. Also, things like 'get the log from running
the tooling script' and 'was the tooling script successful'.
Thinking about that API now might shed some more light on the
conductor/audrey interaction and whether the XML format is
'right' for all this.
Two things:
First, we have to be careful what we expose via any API. It could mean showing private
data (passwords, keys, etc) to API clients.
There is a longer term idea of sending Config results back to conductor. But, I'm
honestly not sure how this overlaps with features in Katello regarding configuration
status.
* The doc is titled 'Audrey-Conductor Integration', but
doesn't
say much about the nitty gritty of that interaction, in
particular the API on the Audrey side.
That's fair. Much of the discussion you're talking about appears in other
documents. This integration is really referring to the fact that bits of code needed to
be added to conductor to support configurable deployments, and that code has typically
been referred to as Audrey.
David