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.