From: Joseph VLcek jvlcek@redhat.com Date: Wed, 27 Jul 2011 18:10:51 -0400
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
Assorted comments, in no particular priority:
I believe the sample xml snippets in your doc have diverged somewhat from the current thinking about how these structures should be represented. That's fine, this is all a work in progress, just please remember to keep the doc and examples updated as we continue to nail things down.
I'd like to see us finish thinking through the semantics of parameter specs, at least in so far as they will matter for rev 1. What's there is good for the simple nail-down-a-value-in-the-deployable, but I believe we still claim to want to support prompt-for-value and get-value-from-other-source (like a different instance). If there are other variants, that's fine too, but let's spend a bit of time and write down what those can be.
Under scripts-as-urls: I think it's worth expounding just a little on the different effects you get if you reference some artifact externally, as opposed to including it verbatim. In particular, the idea that your allegedly-stable-and-working deployable can be completely screwed up if some random person hacks the referenced script.
Under config handoff, it specifies rest to the server. Have we given up on qpid for that? If not, I suggest that it either not specify, or allow that there will be multiple transports.
The example config tooling script is the first mention of the fact that the infrastructure sets up env vars in order to pass values to the user-written pieces. That probably deserves an explicit description. [Later: oh, ok, it mentions that in more detail further down]
I like the descripotion of how the tarball of crud from the server gets unpacked and processed.
One of the features which has been talked about periodically is the idea of having a well-known location for the config values which get delivered by this mechanism. A motivation for that was to enable much-more-complex config management tools, for instance a nest of non-trivial puppet classes and such, to be written in such a way as to pick up the base config values which come down via audrey. Does the structure you laid out here accomodate that, or is it worth building a separate thing just for that purpose?
Overall, I like it!
Further observations:
One of the perennial questions about all this area is where *should* the line be between audrey and some other config management systems. That concern has already been reflected in some other comments. Based on everything I've heard, I believe we don't know enough yet to answer that question very solidly, and I make the observation that what you're describing here accomodates the idea of things like "go talk to this puppetmaster and build yourself up from there". So I claim we should be continuing to develop on this path, and get to the point where we can routinely stand up working examples and play with them to figure that out. Also, getting something simple out for the community to play with will, I expect, get us all kinds of requests for ways to push it forward.
We've already done some of that with the JON stuff you guys have been working on, and I expect we'll do more.
We may also find that there isn't really a single requirement for how people want to think about things, but instead there's a spectrum. And that we won't be able to do everything everybody wants :-)
At such time as we get further clarity about all that, we'll likely want to expand/enhance this doc to describe more precisely what level of stuff we expect to be done by audrey vs other tools.
And BTW thanks for including all the examples!
Good stuff.