deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: deltacloud as a lib and broker
Date Fri, 05 Apr 2013 22:22:42 GMT
Hi Jan,

On Fri, 2013-04-05 at 14:37 +0200, Jan Provazník wrote:
> 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.

It's not the first time this has come up ;)

> 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)

This entails a _lot_ of things; it's not just the mechanics of
maintaining a little more code. That API needs to be documented, it
needs to be tested, mechanisms have to be in place to evolve the API in
a somewhat backwards-compatible manner etc.

> - 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

True, but that has been a very minor support burden so far.

> - 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.

That discussion is somewhat orthogonal to the library discussion.

There are some other downsides to using DC in process (as a library): it
also significantly changes where DC can go architecturally. So far, the
classic DC API has worked very hard to be stateless - CIMI isn't, and it
wouldn't be unreasonable to introduce state into the classic DC API.
That would be much more awkward if DC becomes a library.

Similarly, there are things we'd really need a background worker for;
again, that becomes much more complicated if DC is a library.

As far as I can tell, the one big argument for DC as a library is that
it's one less service to babysit _if_ you happen to write your app in
Ruby. Maybe the right answer here is to figure out what concretely the
big headaches around that are, and how to best address them.

> This lib would be also handy for the WingedMonkey project.

AFAIK, they Rack-mount DC into their app.


View raw message