On 04/05/2013 08:37 AM, Jan Provazník wrote:
Hi, there was a discussion in the last weeks about the proposal to reduce Conductor into a broker. Martin with Tomas wrote nice summary here: https://github.com/aeolusproject/conductor/wiki/BrokerProject
During this discussion we touched (again) the "Deltacloud as a lib" topic, Michal asked me to send a mail here if we have a feature request. If you look at the possible solutions (the link above), having this lib would be helpful in all three options.
Although the broker could be implemented using DC as a separate service or as a rack mounted app, I think it's not an optimal solution: DC consumer is then dependent on this separate service, it adds another chunk into the chain that can fail and that a user has to take care of.
If it's rack mounted into an app which uses it, then it solves the problem with setting up separate daemon, but communication between app and DC is technically same as if it was separate service (so then TCP connection from the app to the mounted DC is done anyway). And it adds another problem - a user has to take care of restricting access to the mounted DC api which is then exposed in the same way as the main app.
From what I know there are two major reasons for having DC as a standalone service:
- taking care of another API (on lib level)
- it can be used by other no-ruby projects then
I think that it wouldn't be so bad, because with DC as a lib:
- you wouldn't have to support ruby deltacloud-client
- maybe the classic DC API wouldn't be needed then and consumers who
can't use DC lib directly would be satisfied with CIMI API (which you already have). But even if you keep classic DC API, it would be just simple wrapper around this lib which converts input/output into expected format.
I think, this would also bring DC more audience. Obviously according to fog library popularity, ruby world wants a cloud lib and it's a pitty that the library is not Deltacloud. This lib would be also handy for the WingedMonkey project.
Jan
Option 3, being the closet to what we have now, may be the best path for getting a version 1 shipped.
It may also make external contribution to the individual pieces easier.
Option 2 seems to me to be a possible logical progression for second version.
Joe V.