On 04/06/2013 12:22 AM, David Lutterkort wrote:
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
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.
I'm not familiar with DC plans (which sound really interesting) but even
with stateful DC the lib could make sense:
1) the DC lib - can be used by anyone who doesn't need any stateful feature
2) DC/CIMI stateful service - built *on top* of the lib, wraps the lib
with REST API, adds stateful features
Just curious, what is the reason to keep both stateful classic DC API
and CIMI api in future? Backward compatibility?
Similarly, there are things we'd really need a background worker
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.
The thing is that if I think about Aeolus-related components which we
talked about recently and which were planned to be integrated somehow
together (DC API, Broker, DC Tracker, Heat, a user interface app) and
also if Broker should be standalone successful community project, then
I wonder if there exists a reasonable solution.
> This lib would be also handy for the WingedMonkey project.
AFAIK, they Rack-mount DC into their app.
Winged Monkey currently doesn't integrate DC API. From what I know from
Brno guys one of the reasons is/was that Winged Moneky doesn't want to
depend on an external service. True is there is a POC patch from Michal
which uses rack-mount solution, anyway (at least Brno guys) would
appreciate lib too.