On Mon, 2011-09-12 at 10:44 -0400, Greg Blomquist wrote:
I've written up a document explaining how we're planning on
implementing
collecting Audrey parameters from within Conductor. Please take a look
and let me know if you have any questions.
My plan is to begin implementing this design today and course correct if
anyone brings up something earth-shattering.
A couple of notes up front:
1) This is dependent on a patch that was submitted quite some time ago,
but never acked. I'm basically pulling that patch, and will have to
rebase and resubmit later...most likely concurrently with this patch.
2) I'd appreciate suggestions on the model changes. Right now it's a
fairly rudimentary key value store for capturing the Audrey parameters
and values. It will serve our purpose for now, since we're only gonna
support scalar values for the time being. But, as this evolves, the
model design will have to change too. I'm not looking to completely
future proof this, but any suggestions on this model are very welcome.
link:
https://www.aeolusproject.org/redmine/projects/audrey/wiki/Collect_Audrey...
Thanks!
---
Greg
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
Looks great Greg!
Just a couple comments/questions:
1-
The example "this deployable XML file" has all top level services with
no named services. How will multiple services be handled.
2-
The table under model updates only shows one each of: parameter_name,
parameter_type & parameter_value. I "assume" these three entries will be
repeated for each parameter? Is this correct? Perhaps an example that
ties to the "this deployable XML file" example files listed could help
folks understand how this will work.
Joe