On 08/08/2011 08:05 PM, 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
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.
Or is it similar to Knife from Chef
(
http://wiki.opscode.com/display/chef/Knife+Bootstrap), FOG for Ruby,
and perhaps func?
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
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' ?
* 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.
* What about more complex file-download scenarios (e.g., cloning
directories/directory trees from a remote server) ?
Why not defer this to the "real" management tool?
-- kb