On 09/12/2011 11:06 AM, jrd(a)redhat.com wrote:
> From: Greg Blomquist <gblomqui(a)redhat.com>
> Date: Mon, 12 Sep 2011 10:44:57 -0400
>
> 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 for pulling this together Greg!
I'm not conversant enough with the underpinning code to express an
opinion about the integration points, but it sounds plausible.
Question re scope: If we were trying to pare down to the absolute
rock-bottom functionality, would it save implementation time to skip
the show-instance page enhancements? If the answer is yes, I advocate
staging the work that way, ie do the prompting on the launch page
first, and time permitting, do the show-instance stuff.
My two kopeks....
That piece of functionality serves two purposes. First, it allows the
user to see what they've launched, and how they launched it. Second, it
gives Dan R. a little exposure to the Conductor codebase and Rails.
Dan's been a python/django developer for some time. So, the Rails
transition isn't terrible for him to take on. But, having an actual
codebase like Conductor to work on makes huge difference when learning
something new.
With that in mind, we've actually looked a paralyzing the work where Dan
works on the DB and "show instance" page pieces, and I work on the XML
consumption and parameter collection UI pieces. If the "show instance"
stuff looks like it won't make it, we can cut bait and continue on with
just the collection of parameters. Overall, I think the "show instance"
changes are fairly important to keep around since it's currently the
only place where users will be able to see how they launched previous
instances.
This brings up a good point though. I should actually update the doc to
talk about other "nice-to-haves" that we're largely skipping unless we
find a time machine.