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