Hallo David and all, Wish you a productive week.
On Fri, Apr 05, 2013 at 03:22:42PM -0700, David Lutterkort wrote: > 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. Well if you want to have the bigger picture make sense, then I find this context relevant. > > 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. Could you, please, elaborate a bit on the problems of being a library? Both "having a state" and "having a worker" are features that can be addressed in a library and those concepts are nothing new to be afraid of. But as Jan suggested, you can separate the project into two components: * the library, * the stateful daemon with workers. > > 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. Write an app in Ruby is what we are trying to do here. But let's turn the problem around. __Even_if__ you are a developer writing app in Ruby you are most likely __not_using_Deltacloud__ (see githup, ruby-toolbox, gitstats, articles on the web. So we should probably ask: "Why is that?" Lets try to guess: a) Deltacloud is not a library but average Joe Developer wants one. b) Deltacloud does not provide the features Joe Developer wants. What are those features? c) What other reasons might be? > > > This lib would be also handy for the WingedMonkey project. > > AFAIK, they Rack-mount DC into their app. > No. They don't use Deltacloud. > David > > -- Martin Povolny <mpovo...@redhat.com> tel. +420777714458
