On 04/05/2013 09:26 PM, Michal Fojtik wrote:
On 04/05/2013 02:37 PM, Jan Provazník wrote:
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).
This is not entirely true if you use the MockSession approach. You don't
need to do any TCP connection actually, just execute the route and
deserialize XML/JSON (which is done by client automatically).
I noticed this approach in the new ruby deltacloud-client lib. This
approach means that by requiring the client, I actually load also
deltacloud server including the whole sinatra stuff around it. The
rack's MockRequest (used for catching the http requests) was created
only for writing tests for rack apps, not as a production solution.
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.
I don't see this as an issue. You can say to Rack that the route will be
accessible only from localhost/restrict to IP address :-)
Not sure if host-level restriction is sufficient for production use (and
you still have to take care of selinux/fw).
From what I know there are two major reasons for having DC as a
standalone service:
- taking care of another API (on lib level)
Yes, I think this is the major blocker right now. As David mentioned
already, our capacities are all gone maintaining the 2 (3) different API
frontends we currently have.
However I don't think it will be a blocker if somebody is willing to
maintain the fourth API (library). (And we can help with start/arch
design).
- it can be used by other no-ruby projects then
Deltacloud API server will still be there no matter if we will have
drivers as a separate library or not :-)
I think that it wouldn't be so bad, because with DC as a lib:
- you wouldn't have to support ruby deltacloud-client
Why?
If there would be a ruby deltacloud lib, there wouldn't be any reason to
provide a ruby client lib which allows you to connect to a deltacloud
API which is just a wrapper around the ruby deltacloud lib - you could
just require the ruby deltacloud lib.
- 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).
I would not be so optimistic :-) CIMI API is build on top of Deltacloud
drivers.
But even if you keep classic DC API, it would be just
simple wrapper around this lib which converts input/output into expected
format.
This is kind of architecture I would like to have in Deltacloud API:
* deltacloud-lib.gem
(drivers code, features, error handling)
* deltacloud-server.gem
(require deltacloud-lib, use rabbit/sinatra to generate DC REST API)
* deltacloud-client.gem
(client we already have, provides interface to deltacloud-server.gem)
+ One thing I would personally like is to have a way how to write a
Deltacloud API driver as separate gem. However it is still not clear to
me how this should work ;-)
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.
The main point for Deltacloud (AFAIK) was to provide API not a cloud lib
for 'ruby world'. Since DC is a REST API it is programming language
agnostic. There are projects, like Condor/MRG which use Deltacloud API
as a service.
But I agree with you. Having and lib and be a competitor to 'fog' could
make us more attractive for ruby programmers.
You could provide both as you mentioned above - the DC lib for ruby
programmers and the DC or CIMI API service for "other-than-lib" usage.
-- Michal
Thanks for feedback, Jan
