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