Open Stack

Hi,

Just before the Austin hackathon, we uploaded 5 patches related to the cluster federation blueprint

https://blueprints.launchpad.net/swift/+spec/cluster-federation

one of those patches, https://review.openstack.org/51242 dealt with the mechanics of forwarding data from a middleware component to/from a different cluster.  This patch had two goals:
1. Maximize code reuse while minimizing core code change: any new code is simple and doesn't impact connection management, or  the way the core handles data proxying between connections.
2. Refactor at the level of the ring and introduce the concept of a TargetRing to show that container-forwarding can be seen as a kind of storage policy while, again, minimizing core code change.

I have just pushed a new patch, https://review.openstack.org/55674  which presents an alternative way to achieve the code reuse objective by creating a swift/common/http_utils module that can be used by both middleware and core proxy-server code (and possibly other code as well such as backend daemons, container-sync being a possible candidate).
Like the first patch, it also includes a very basic piece of middleware that forwards all requests to a configured target cluster.

I am including more details about the patch further down so if you're interested, please keep reading.

I am interested in finding out which approach people prefer and get feedback on the patch itself.

Eric


More details
--
Most of the code complexity in http_utils comes from the fact that for object PUT data must be transferred between the client connection and the backends/target connection and, at the moment, this uses decoupling queues and extra threads to produce to / consume from the queues.  It is basically very close to the code from helper methods already in base.py and obj.py so reusing the code from http_utils in proxy-server means that the following code can be removed (only commented out for now):
base.py:  _make_app_iter
obj.py: _send_file plus a chunk of code embedded in PUT

Unlike the previous patch, this alternative patch has basic support for ssl based on the httplib.HTTPSConnection class used by bufferedhttp.py.  It may form a good basis for more generic use, in particular by the container-sync daemon which must interact with proxies from other clusters.  I understand there is a wish to remove the dependency on swiftclient in this daemon and the code in http_utils could be a good step forward towards that objective.

Both patches rely on a callback from proxy/server.py (just like already exists for calling back the authorization middleware) to give  a handle on the controller object that is created anew for each request.  The app given to a middleware at instantiation time is the next filter in the pipeline and only maps to the proxy-server application if the middleware is placed just before proxy-server in the paste-deploy config pipeline.  As far as I know, a callback from server.py is the only way a middleware can have a handle on proxy-server or a controller while being flexible about its placement in the pipeline.
In the case of the original patch, the handle on the controller is needed to be able to call reused controller methods such as make_requests, etc.  In the case of the alternative patch, only a handle on the proxy-server application is needed for http purposes so that configuration values (timeouts, queue depth, etc.) can be reused.  However, in both cases, a fully functional container-forwarding will require a handle on the controller to implement complex multi-container use cases (COPY, SLO, DLO, versioning) where forwarded containers could reside in different clusters.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131108/d65494ad/attachment.html>