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
