Thank you for the feedback. It's greatly appreciated. My comments inline
On Mon, 2011-08-08 at 17:05 -0700, David Lutterkort 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
> 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. 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.
Perhaps but the term service has some momentum. I think changing it now
would result in more confusion for folks that already know it.
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
This functionality is supported in the design.
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
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.
I don't see the complexity of the server specific tooling to
be that great and I don't think it outweighs the potential
I think you may be correct that these may very well end up being
the most common use cases. Our design does not preclude that. It
also provides a bit more so users that don't want to are not forced
into having a single "assembly" wide tooling that performs all the
launch config for the entire instance.
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' ?
No they can not but they can build tooling into the image.
* To make it possible to pass more structured data as
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)
The vision for Audrey is to keep the parameter name/value pairs as
dirt simple as possible and not lock them into a specific tooling
* What about permissions, ownership etc. of downloaded files ?
the downloaded files are the instance's private ssh keys, you
don't want them to be world readable ever.
good point. We'll need to nail that down.
* What about more complex file-download scenarios (e.g.,
directories/directory trees from a remote server) ?
If the tooling layout is complexity the user could build it into
* I don't understand the section 'Building user
tooling into an image'
I've added a little more description to that section.
The idea is that not all tooling needs to be described in
the DeployableXML. Some tooling can already be built into an
image. This tooling could be provided by us or by the user.
Some tooling, although minimal (Puppet for httpd & sshd) is already
being included with Audrey. It is envisioned that this will be expanded
in the future.
* The encoding of parameters before sending them to the
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
more robust to use a standard mechanism for serializing data
(YAML/JSON/XML/whatever) and sticking that as a special file
into the tarball
Having the format of the parameters be dirt simple allows flexibility
* Is an API for the config server planned ? It would probably
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.
* 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.