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
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) ? * 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 * 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. * 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.
David