From: Joseph VLcek <jvlcek(a)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.