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
> It can be found here:
> 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:
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)
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
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
To specify more normal parameters for the executables, we could move the
"service / parameters" element under the "service / executable", so
would look more like "service / executable / parameters". We'll look
into this more, too.