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
> - At this early stage, keeping it fairly self-contained will
> 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.
> - A bunch of the code Conductor needs for handling deployables
> 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.
> - Audrey is interesting in its own right and should have its
> 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.
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
- 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.
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
> - This is a subtly different way of thinking about Audrey.
> 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
Happy to go into more detail. Maybe the best way would be for me to
flesh out orch some more?