On 04/19/2011 03:57 PM, Kaleb S. KEITHLEY wrote:
Here's a summary of the frameworks I've considered for
implementing the
client-server communication pathway, along with what I see as the pros
and cons of each.
My first choice would have been #3, but after further investigation I'm
concerned that adding gsoap2 to RHEL7 could be problematic. I'm
currently leaning toward option #2.
Is it worth circulating this to a wider audience, e.g. cloudfs-devel?
1. pure web-based UI (CGI, python) and ssh, use any web browser as client
Pro: lightweight, encrypted w/ https
Con: lacks two-way SSL authentication, no CLI or hard to write one.
License: none
I'm not sure if it's any harder to write a CLI with this approach than
with any of the others. We need to separate the "view" (command line or
web) from the "controller" anyway. That already implies some sort of
library interface to do things like fan requests out to multiple servers
that need to be involved in an action, and that library should be usable
either from CGIs or inline code (e.g. in the next approach). The lack
of two-way auth in this approach worries me more.
2. python bottle-based cloudfsd and curl-based client
Pro: lightweight
Con: more difficult to debug, doesn't seem to be suited for web UI,
not directly anyway
Notes: jdarcy says it will do SSL, i.e. https, it's not clear (to
me) it will do two-way authentication, common parts could extracted
and used by both a python-based CGI web UI and bottle-based cloudfsd
accessed from a C+libcurl-based CLI
License: MIT for bottle.py
I definitely know how to do (and have in fact done) two-way auth in a
bottle-based app. Integrating that with the existing cloudfsd code is
more a matter of standardizing key management than of actually changing
code.
3. gsoap2-based cloudfsd and client(s)
Pro: high level APIs, has two way authentication
Con: possible license issue, RPMs are available for F{14,15}, not
RHEL (but it's in EPEL), some people complain that the generated
stubs code is overly large
Notes: web UI w/ CGI that invokes SOAP APIs (native python bindings
to SOAP)
License: GPL or gsoap public license (mozilla public license), wsdl
and soap2cpp require a commercial license for commercial use. I
infer that Red Hat would need a commercial license to generate use
wsdl and soap2cpp to generate the stubs.
How high-level do we need this API to be? To put it another way, what
does gsoap (or xmlrpc etc.) allow us to do or express that's not as
easily done or expressed by passing REST requests and responses through
an SSL connection?
4. xmlrpc-based cloudfsd and client
Pro: lighter than gsoap2.
Con: not as high level as gsoap2, not clear whether it does SSL
Notes: web UI w/ CGI that invokes xmlrpc APIs
License: BSD-style, Expat, ABYSS, and others for some pieces.
5. xmlrpc3-based cloudfsd and client
Pro: ?
Con: Java-based and Apache Tomcat, long list of dependencies
Notes: Web UI as with xmlrpc
License: Apache
6. Aeolus Matahari
Pro: part of Aeolus
Con: don't know much about it
Notes: but presumably there are people around who do
License: presumed good
Not a big fan of Matahari in general, plus it's a more complex kind of
dependency than e.g. xmlrpc or bottle.
7. SNIA CDMI
Pro: industry standard
Con: written in Java, working draft is "...released so that
developers can get started with integrating CDMI into their products..."
License: BSD
As far as I know, CDMI is more geared toward operations on data objects
than on managing the details of the storage system serving those
objects. For most of the operations we care about - e.g.
adding/removing tenants, starting/stopping volumes, enabling/disabling
encryption - it seems like fitting them into framework would be either
cumbersome or impossible.