David
Thank you for the feedback. It's greatly appreciated. My comments inline below.
Joe
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 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.
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 instance.
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 value.
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 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)
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 format.
* 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.
good point. We'll need to nail that down.
* What about more complex file-download scenarios (e.g., cloning directories/directory trees from a remote server) ?
If the tooling layout is complexity the user could build it into the image.
* I don't understand the section 'Building user provided config 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 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
Having the format of the parameters be dirt simple allows flexibility reduces complexity.
* 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