deltacloud as a lib and broker

jvlcek jvlcek at redhat.com
Fri Apr 5 14:59:32 UTC 2013


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.




More information about the aeolus-devel mailing list