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 Although we would appreciate input from anyone I'm requesting review feedback from the following people: John Dunning Hugh Brock Chris Lalancette Mark McLoughlin Carl Trieloff Brian Kearney I am asking that all feedback be provided by COB one week from today, August 3, 2011. We are already moving forward with some development according to the presented design so direction changing feedback would be greatly appreciated as early as possible. If anyone needs more time please let us know. I tried to provide XML examples that align with the format outlined in past discussion. If I missed that please let me know.

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 Although we would appreciate input from anyone I'm requesting review feedback from the following people: John Dunning Hugh Brock Chris Lalancette Mark McLoughlin Carl Trieloff Brian Kearney I am asking that all feedback be provided by COB one week from today, August 3, 2011. We are already moving forward with some development according to the presented design so direction changing feedback would be greatly appreciated as early as possible. If anyone needs more time please let us know. I tried to provide XML examples that align with the format outlined in past discussion. If I missed that please let me know. Thank you, Joe and Greg

On 08/01/2011 03:45 PM, Bryan Kearney wrote: > On 07/27/2011 06:10 PM, 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 >> >> Although we would appreciate input from anyone I'm requesting review feedback from the following people: >> John Dunning >> Hugh Brock >> Chris Lalancette >> Mark McLoughlin >> Carl Trieloff >> Brian Kearney >> >> I am asking that all feedback be provided by COB one week from today, August 3, 2011. We are already moving forward with some development according to the presented design so direction changing feedback would be greatly appreciated as early as possible. If anyone needs more time please let us know. >> >> I tried to provide XML examples that align with the format outlined in past discussion. If I missed that please let me know. >> >> Thank you, >> Joe and Greg >> > > Read through the doc. I still have conflicting thoughts that "I am sure > this is done somewhere else, why are we not using it" but I know that is > being discussed in other places. > > I will try to make comments relative to the section headers: > > Introducing ServiceXML > ====================== > You mention output parameters. Can there be more that one? Is the status > of the execution a unique parameter? There can be many. The output parameters are more in relation to the system and not the service or script outputs. The output parameters are currently captured only through facter. So, after a guest has been configured, it can send its output parameters back to the config server to be broadcast to other guests that might depend on those values. Additionally, to keep consistent with what Mark M. proposed back in May, we'll be changing the name of the the "outputs" to "returns". > > Changes to Assembly XMl -> Executable > ==================================== > It is not clear here is the script is local, or from the config server. > Later on I assume to to be from the config server only. Given the way > the variables are named, I assume no service can be defined without some > shim layer so I assume it will also be http based (more on this later) shim layer? The script needs to be accessible by the config server. It can be local to the config server (file://) or not (http://). In either case the config server downloads the file(s) listed in the deployableXML and builds a single tarball to be downloaded by the guest. > > Changes to Assembly XMl -> Parameters > ===================================== > Here you mention they are output parameters only. I assume they are > meant to be input filled out by conductor. Same in Service XML below. This is bad documentation (me, I'm the guy who sucks). The section header you're talking about here should actually read "outputs" to match the example deployableXML. Additionally--as noted above--we're changing the name of the "outputs" element from "outputs" to "returns" (to match what Mark M. suggested back in May). The "outputs" element of the XML contains only those pieces of data that the guest will send back to the config server. The "deployable / assemblies / assembly / services / service / parameters" element of the XML contains the parameters required by the service. And, these are the bits of data that should be collected by conductor. > > Changes to Assembly XMl -> Executable > ===================================== > I believe the rule that if you provide a top level script that it > disabled all service scripts will make things very brittle. However if > we KISS that may be ok for now. > > > How the config tooling wil be delivered..... > ============================================= > Question: What is the stack for the Audrey tools? I assume python. What is the Audrey Startup script written in? Python. What is the Config Server written in? Ruby (Sinatra). What is the language for the downloaded executable(s)? Anything that can be executed (bash, python, ruby, perl, etc.) > > How Audrey will invoke the config..... > ====================================== > You mention a requires parameter. Are there optional parameters? I did > not see that in the XMl. > > In general, I am concerned with how service names interacts with the > desire to make reusable atomic services. Per the document the service > name denotes execution order. It also provides a name space for the > variables iff they are passed into the root executable. The name space > is not used by executables delivered with the sctipt. So.. I can not > have two services reference the same varaible, and changing the service > name will require me to modify my scripts. Seems brittle. > > Add to that that the parameter passing appears to be custom, and that > the values are in base64 then we are in a situation where anything we > want to be a service _must_ have a custom shim script to do the unique > param parsing, which may be service name aware, and has to take on the > base 64 decoding. > > I would suggest making the order be implied in the location in the file, > or by a unique attribute. I would aslo suggest making the names of the > parameters be absolute (single name space) and an ability to call the > executables with more normal parameters. Our first pass is to actually have the Audrey Startup script parse and decode the parameters and create environment variables for the parameters (See the example callout in the "Config Tooling Mechanism section). This will imply a single name space. This also obviates the need for the shim script. Also, we're dropping the bit where it sends the pre-processed parameter string to the executable(s). The executables will get all their parameters from the environment vars. I like the idea of including an ordering attribute, or some other means of specifying the order of execution of the services. We had been thinking that if you wanted a specific order, you provide a top level script that calls your service scripts in a certain order. First pass, we'll keep with this idea, then implement some form of declarative ordering. To specify more normal parameters for the executables, we could move the "service / parameters" element under the "service / executable", so it would look more like "service / executable / parameters". We'll look into this more, too. Thanks Bryan! ---- Greg > > -- bk > >

> You mention output parameters. Can there be more that one? Is the status > of the execution a unique parameter? There can be many. The output parameters are more in relation to the system and not the service or script outputs. The output parameters are currently captured only through facter.

I like the idea of including an ordering attribute, or some other means of specifying the order of execution of the services. We had been thinking that if you wanted a specific order, you provide a top level script that calls your service scripts in a certain order.

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 Although we would appreciate input from anyone I'm requesting review feedback from the following people: John Dunning Hugh Brock Chris Lalancette Mark McLoughlin Carl Trieloff Brian Kearney I am asking that all feedback be provided by COB one week from today, August 3, 2011. We are already moving forward with some development according to the presented design so direction changing feedback would be greatly appreciated as early as possible. If anyone needs more time please let us know. I tried to provide XML examples that align with the format outlined in past discussion. If I missed that please let me know. Thank you, Joe and Greg _______________________________________________ aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel

From: Joseph VLcek <jvlcek(a)redhat.com&gt; 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

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

> From: David Lutterkort <lutter(a)redhat.com&gt; > Date: Mon, 08 Aug 2011 17:05:46 -0700 > > 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. I think that's a very interesting use case, but not the only one. Audrey is clearly intended to accomodate the case where the only configuration needed is enough to get whatever local agent(s) talking to their mother ships. It's also intended to be sufficiently general purpose to allow users to stick whatever scripts or other tools they want in there, so that they can do the big-hairy-perl-script solution if they choose, or any other permutation. IOW, it's explicitly a non goal to say "You, Ms User, are required to use some more complex central-server-based config system in order to get your instances set up". In addition, we're trying to think ahead and leave room for non-cloud-centric schemes. We've heard from customers as well as folks in the platform group at RH that they like the idea of metadata describing a "machine" and how it gets started up. So while it's the case that it has "cloud" tattooed on its forehead now, it may not always.

[...] > From: Greg Blomquist <gblomqui(a)redhat.com&gt; > Date: Mon, 8 Aug 2011 20:36:56 -0400 (EDT) > [...] > > > > 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 > > The more I think about how all these pieces of Aeolus will have to play together, the more I start to think that just the top-level scripts are sufficient. I don't think I buy that, at least not yet. I'll grant you that for the very simple cases with which we've been prototyping, a single script is way easier to understand and implement. I believe, unless we discover that real users really *do* want to gravitate toward more structured startup scenarios, that we're going to find a bunch of people wanting to go their own way, even within an instance. And therefore forcing them to cram it all into one script is going to be a mess.

So I advocate not making that decision until we have more concrete examples to work with.

[...] > > I agree and still want this. The original idea was that the data being passed from Conf server to client was a simple list of key value pairs. It seems to me that we've moved beyond that concept. Again, let's get further along before we decide that. If we get there and discover that there are no cases where you just want generic parameters, with an optional interpreter for them, that's fine, we can simplify.

On 08/08/2011 08:05 PM, David Lutterkort wrote: > > * 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?