Hey Mark,
On 07/26/2011 10:04 AM, Mark McLoughlin wrote:
Hi Greg,
On Tue, 2011-07-26 at 09:36 -0400, Greg Blomquist wrote:
> On 07/26/2011 04:30 AM, Mark McLoughlin wrote:
>
> [...]
>
>>
>> You know, after all this, I think you're actually only disagreeing with
>> a minor part of the proposal.
>>
>> Here's all I'm saying:
>>
>> - Deployable parsing and interpretation, config server and the audrey
>> guest agent could be a fairly self-contained effort under the
>> Aeolus umbrella.
>
> I agree that the parsing and interpretation of deployables is something
> that could be broken out and housed in an Audrey library called on by
> Conductor.
Cool.
>> - At this early stage, keeping it fairly self-contained will give the
>> effort a better chance of success because it becomes easier to
>> iterate on the design.
>
> Agree. I'm already a fair bit down the road of being fully integrated
> with Conductor, though. So, I suggest that I keep down that path until
> I have the proof of concept integration working, then circle back to
> refactor it out if that's the right next step.
Fine by me. I'm not trying to throw current efforts off track.
KK
>> - A bunch of the code Conductor needs for handling deployables and
>> talking to config sever should live in a library outside of
>> Conductor and developed as part of the Audrey effort.
>
> This seems achievable, under the same caveat as above.
Cool.
>> - Audrey is interesting in its own right and should have its own
>> simple stateless API/UI server which you can run against any
>> deltacloud instance.
>
> This is where you throw me. I'm not sure what you mean by running
> against a deltacloud instance. I can't see this working without
> reproducing a bunch of code already in Conductor. Unless you're seeing
> this from a different angle.
This is what I was trying to demo with Orch last week.
Ah. /me still needs to take a look at that.
The idea is:
- a library contains the code for parsing a deployable, figuring out
what parameters are required from the user and, based on user
supplied parameters, returning a description of the instances that
need launching
- the library also contains the code needed for setting up config
server with the instance config
- conductor uses this library and adds a UI for launching deployables,
code which takes the instance descriptions from the library and
launches them, code for storing instance IDs in the DB as
deployments, code for the suggested deployables dropdown and code
for associating a config server with a provider account
- orch also uses the library, but is a simple stateless UI/API server
(configured to point at a specific deltacloud and config server
instance) which has its own UI for launching deployables, launches
instances using deltacloud directly and returns a URL which encodes
the instance IDs so that they don't have to be stored in a DB.
K, I see. I'm a little torn...on the fence between what Angus is saying
and this idea of having a separate UI for launching deployables.
The duplicated code between orch and conductor should be minimal, but
we'd get a nice way to hack on and promote Audrey independent of
Conductor.
>> - This is a subtly different way of thinking about Audrey. With the
>> benefit of hindsight, I think we integrated this stuff too early
>> into Conductor. If we had understood how both pieces could live
>> independently, I think we would have kept them separate until
>> the Audrey concept had proven itself out.
>
> What are your thoughts here? I can see audrey being packaged as some
> library code that conductor can interact with...but, I'm not seeing the
> standalone concept. I'm sure there's more to this, and I'd like to
> understand it.
Happy to go into more detail. Maybe the best way would be for me to
flesh out orch some more?
Perhaps. The explanation above helps out quite a bit. And, me reading
the orch code will help, too.
Thanks Mark!
---
Greg
Cheers,
Mark.