deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Povolny <mpovo...@redhat.com>
Subject Re: deltacloud as a lib and broker
Date Mon, 08 Apr 2013 07:44:44 GMT
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 <mpovolny@redhat.com>
tel. +420777714458

Mime
View raw message