RFC: The Broker

David Lutterkort lutter at redhat.com
Fri Apr 5 22:31:17 UTC 2013


On Fri, 2013-04-05 at 15:45 +0200, Tomas Sedovic wrote:
> > - As I read the bit about cloud broker, having not been involved in the
> > conversation for a little bit, it occurs to me that it sounds a lot
> > closer to what Deltacloud does than Conductor did. It almost sounds more
> > like an extension to Deltacloud than a stand-alone app, at least at a
> > high level.
> 
> Remember that under ideal circumstances, Deltacloud as a code base need 
> not exist because everyone implemented the Deltacloud (or CIMI or any 
> open standard) API.
> 
> Also, you can have Deltacloud without the broker and you can have the 
> broker without Deltacloud. To me, that seems a reason enough not to 
> merge them (though there's still opportunity to share code).

I keep going back and forth in my head what the right combination is
there - clearly, for the public/pool API there might be some value in
implementing that as a DC driver (it would save the broker from worrying
about the minutiae of dealing with the web side of API's)

Just as clearly, on the administration side, the broker is a DB-backed
web service, and needs to do what's best for such an app; the mechanics
of implementing a RESTful API are a much smaller concern on that side
compared to the overall work involved.

> But if the Deltacloud community (and Apache) are okay with having the 
> broker under the Deltacloud banner, I'm fine with it. Might help us with 
> community involvement and visibility.

I think that's something to consider very seriously: the broker could
definitely be its own Deltacloud subproject, with separate code base
etc. We'd need to weigh the pros and cons carefully.

David




More information about the aeolus-devel mailing list