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