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