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.
