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.