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.

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.


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>







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.


We agree. We will track this in Redmine for  0.4.0.




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?

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