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 07/27/11 - 06:10:51PM, 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.
OK, so I took a look.
1) What is the <outputs> XML supposed to represent? I think this is possibly supposed to match up with the "Parameters" explanation, but I'm not entirely sure.
2) During Configuration hand-off, I think we need to seriously consider changing from a REST based API to a QMF based one. At least, we should put the question to rest before 0.4.0. For a first implementation, using REST is fine, but we need to make the decision (and implement it) before Iteration 4 is over.
3) In the invocation section for the examples, I'm a bit confused. The document specifies what the Requires Parameters look like (presumably on the wire) and then mention the environment variables that will be created (AUDREY_VAR_service_A_param1, AUDREY_VAR_service_A_param2, etc for Example 1). However, it then mentions that the start script will be invoked with:
./start "|serviceA|param1:True,param2:val2|service_B|param1:val1|serviceC|"
Wouldn't that instead just be:
./start
with the correct environment variables from above? Or am I missing something?
Otherwise, this seems to specify what we have been talking about, so it looks good.
Thanks for the feedback Chris,
The below response was generated by Joe and Greg working together.
On Aug 1, 2011, at 10:17 AM, Chris Lalancette wrote:
On 07/27/11 - 06:10:51PM, 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.
OK, so I took a look.
- What is the <outputs> XML supposed to represent? I think this is possibly
supposed to match up with the "Parameters" explanation, but I'm not entirely sure.
That is what we originally referred to as "Provides Params"
In an email thread to aeolus-devel titiled: "Deployables, templates, images and you" the term "return" was used:
see: https://fedorahosted.org/pipermail/aeolus-devel/2011-May/001640.html
To be compatible with the data in that thread I will update our doc to use the term "return(s)"
e.g.:
<assembly> <name>frontend</name> <image id="11abf870-894c-4336-bc9f-37904c394924"> ... <returns> <return name="http_port"/> <return name="hostname"/> </returns> </image> <assembly>
- During Configuration hand-off, I think we need to seriously consider
changing from a REST based API to a QMF based one. At least, we should put the question to rest before 0.4.0. For a first implementation, using REST is fine, but we need to make the decision (and implement it) before Iteration 4 is over.
We agree. We will track this in Redmine for 0.4.0.
- In the invocation section for the examples, I'm a bit confused. The
document specifies what the Requires Parameters look like (presumably on the wire) and then mention the environment variables that will be created (AUDREY_VAR_service_A_param1, AUDREY_VAR_service_A_param2, etc for Example 1). However, it then mentions that the start script will be invoked with:
./start "|serviceA|param1:True,param2:val2|service_B|param1:val1|serviceC|"
Wouldn't that instead just be:
./start
with the correct environment variables from above? Or am I missing something?
I had initially thought doing both, passing the requires parameters on the command line and setting the environment variables, would be good. I had already been thinking this would be overkill. I believe just setting the environment variables is the correct thing to do.
Thanks for pointing that out.
Otherwise, this seems to specify what we have been talking about, so it looks good.
-- Chris Lalancette
Thanks!
Joe and Greg
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?
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)
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.
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.
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.
-- bk
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
On Aug 3, 2011, at 2:44 PM, Greg Blomquist wrote:
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
Hey Bryan,
Greg and I have talked over the order in which the services are configured to match the order they appear in the Deployable.XML as you suggested.
Thanks for the input.
Joe
On 08/08/2011 02:05 PM, Joseph VLcek wrote:
On Aug 3, 2011, at 2:44 PM, Greg Blomquist wrote:
Hey Bryan,
Greg and I have talked over the order in which the services are configured to match the order they appear in the Deployable.XML as you suggested.
Thanks for the input.
Great! -- bk
On Wed, 2011-08-03 at 14:44 -0400, Greg Blomquist wrote:
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 think it's fine to use factor to capture a few key data pieces about the instance independent of assembly XML, e.g. IP address, fqdn, domainname, and OS. (Fine, with the caveat that facter introduces a dep on Ruby in the instance; I don't have an issue with that, others might though)
For output parameters, it would be simpler to adopt a convention that the script should provide these on its stdout (or in a well-known file, or a file set through the environment) For example, script needs to print a valid YAML file on its stdout, where the toplevel data structure is a hash, whose keys are the names of the output params.
Involving facter in the process just complicates things for the user; if they want to produce some custom piece of data as an output param, they'd need to hook into facter to do that.
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.
Ok in simple cases, but not what the user ultimately wants to say: they don't want to be responsible for global ordering of services, since that can get nasty in more complicated setups. What they want is to say 'before working on httpd, make sure the DB has been set up' - another aspect of services that gets us into config mgmt territory. But implementing that would be way overkill for Audrey.
David
On 08/08/2011 10:31 PM, David Lutterkort wrote:
On Wed, 2011-08-03 at 14:44 -0400, Greg Blomquist wrote:
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 think it's fine to use factor to capture a few key data pieces about the instance independent of assembly XML, e.g. IP address, fqdn, domainname, and OS. (Fine, with the caveat that facter introduces a dep on Ruby in the instance; I don't have an issue with that, others might though)
For output parameters, it would be simpler to adopt a convention that the script should provide these on its stdout (or in a well-known file, or a file set through the environment) For example, script needs to print a valid YAML file on its stdout, where the toplevel data structure is a hash, whose keys are the names of the output params.
Involving facter in the process just complicates things for the user; if they want to produce some custom piece of data as an output param, they'd need to hook into facter to do that.
FWIW... on the katello side we have followed the model of require python only until you get to real config management, then you require ruby. I would assume for the size, we would want to keep Audrey to python only. Even if JON/Katello inject Java or Ruby later.
But.. this is a religious statement. I am fine moving more to ruby.
-- bk
Few comments:
First, on services, the goal is to be able to bootstap the instance. I don't like httpd being used as an example as that could be interpreted as software config and not infra startup config. Nicer example are starting puppet, Matahari, mounting an NFS share etc.
Then,
"Audrey provided and user provided config tooling
Currently some config tooling is provide along with the Audrey Start code. In the future more could be added. If a conflict arises between user provided config tooling and Audrey provided for a particular service the user provided tooling will be used and the Audrey provided tooling will be ignored.
If the user provides a /Top-Level/ configuration tooling executable all other tooling will be ignored."
This section does not seem correct. only case I can think of here is if the image came from an OVA source and has the OVA activation daemon. Then Audry should be able to run the OVA activation daemon, and then it's boot config. We should also be able to tell it to skip calling OVA activation daemon if required.
Carl.
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
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
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
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Tue, 2011-08-02 at 10:05 -0400, Carl Trieloff wrote:
Few comments:
First, on services, the goal is to be able to bootstap the instance. I don't like httpd being used as an example as that could be interpreted as software config and not infra startup config. Nicer example are starting puppet, Matahari, mounting an NFS share etc.
Then,
"Audrey provided and user provided config tooling
Currently some config tooling is provide along with the Audrey Start code. In the future more could be added. If a conflict arises between user provided config tooling and Audrey provided for a particular service the user provided tooling will be used and the Audrey provided tooling will be ignored.
If the user provides a Top-Level configuration tooling executable all other tooling will be ignored."
This section does not seem correct. only case I can think of here is if the image came from an OVA source and has the OVA activation daemon. Then Audry should be able to run the OVA activation daemon, and then it's boot config. We should also be able to tell it to skip calling OVA activation daemon if required.
Carl.
Thank you for the feedback Carl.
Our proposal covers setting up httpd, connecting to a puppet master, or even setting up an nfs mount because we put the control into the hands of any scripting language.
The Top-Level script is optional. So I believe what we are proposing will also support the OVA case if the user wants that.
If I'm misunderstanding something please let me know.
Thank you, Joe
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.
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
David,
Thanks so much for sending this! I wanna address a couple of questions right away, and give more feedback when I'm not typing on my phone. :)
On Aug 8, 2011, at 8:05 PM, David Lutterkort lutter@redhat.com 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.
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
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.
There's a lot more to discuss here, but, like I said...when I'm not typing on a phone.
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' ?
Not at the moment, but I've been toying with the idea of adding a path (or something) attribute which tells where the downloaded file should go in the tarball.
* 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.
True. Joe might be be able to shed a little more light here, but as far as I know we're not currently handling file permissions in any way.
* What about more complex file-download scenarios (e.g., cloning directories/directory trees from a remote server) ?
Hmm...this might work over FTP, but not sure with Http urls.
* 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
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.
* 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.
Two things:
First, we have to be careful what we expose via any API. It could mean showing private data (passwords, keys, etc) to API clients.
There is a longer term idea of sending Config results back to conductor. But, I'm honestly not sure how this overlaps with features in Katello regarding configuration status.
* 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.
That's fair. Much of the discussion you're talking about appears in other documents. This integration is really referring to the fact that bits of code needed to be added to conductor to support configurable deployments, and that code has typically been referred to as Audrey.
David
From: David Lutterkort lutter@redhat.com 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@redhat.com 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/09/2011 09:33 AM, John R. Dunning wrote:
From: David Lutterkort lutter@redhat.com 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.
Before we ever begin to tackle this scenario, this description has to undergo several revisions to reach any acceptable level of clarity.
[...]
From: Greg Blomquist gblomqui@redhat.com 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.
Well, the top-level tooling supports this already. They can have a single top-level script and any arbitrary list of files that can also be specified in the current "tooling" xml element.
This arbitrary list of files can contain additional scripts to be executed. There's nothing preventing that. The only requirement on the user is that their top-level script has to be the one to call execute these additional scripts. In other words, Audrey doesn't execute the scripts for them.
So, if the only argument for services is that people might not want to cram all the scriptage into a single file, they don't have to. What I'm not getting is the use case that drives the need for services.
So, let's talk about the use cases. We have a couple of use cases that I know about. In brief, they look like:
1) bootstrap a system to an existing arbitrary management platform - system means, specifically in the first go-round, a guest - bootstrap can be generalized to "execute some arbitrary code" - management platform includes things like JON, Katello, or even a lower level config management system like puppet or chef
2) provide a simple means of executing scripts on a system - again, system means guest here for now
Both of these can be accomplished with the top-level tooling setup.
If the implementation of either #1 or #2 involves supporting the concept of services, I think there are implicit use cases that are added to this list. But, I don't know what those use cases are. So, I'm not altogether sure what we're actually supposed to support with the implementation.
For instance, in one of David's examples he indicated that it would be nice (and probably a natural extension) to be able to provide the ability to build in service dependency management. In other words, it could become not enough to provide simple service ordering. It might be necessary to provide actual service dependencies. Is that a use case?
What other use cases exist for services? Either those that drive the need for services, or those that come about by including services...
So I advocate not making that decision until we have more concrete examples to work with.
What are the concrete examples that support the need for services above and beyond the need for top-level tooling?
[...]
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.
I'm not as on fire about this. In the end, the format of the data passed between the config server and the instance is something that only the config server and instance need to worry about. It can be as complicated or simple as we want it to be. However, as soon as we say that some other tool has to parse this format, this will need to change to be more generally consumable.
On 08/08/2011 08:05 PM, 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.
Or is it similar to Knife from Chef (http://wiki.opscode.com/display/chef/Knife+Bootstrap), FOG for Ruby, and perhaps func?
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) ?
Why not defer this to the "real" management tool?
-- kb
On Tue, 2011-08-09 at 10:27 -0400, Bryan Kearney wrote:
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?
I completely agree - I mostly threw up these two to point out that once you move from the bootstrapping use case to more general mgmt, there are lots of variations on something as simple as copying files that need to be addressed.
David
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
aeolus-devel@lists.fedorahosted.org