[Openstack] [Swift] Storage Server Redirection

Luse, Paul E paul.e.luse at intel.com
Mon Jun 3 12:14:43 UTC 2013


Hi Edward,

Can you explain a little more about you mean (example maybe) with “I'm also curious about how could this happen if the object URL is the unique identity. How does the server exactly know what client request is another object? Based on what kind of information?”

Thanks
Paul

From: Hua ZZ Zhang [mailto:zhuadl at cn.ibm.com]
Sent: Monday, June 03, 2013 2:50 AM
To: Luse, Paul E
Cc: openstack at lists.launchpad.net; Openstack
Subject: Re: [Openstack] [Swift] Storage Server Redirection


>> 2) The basic idea is that an object server (via middleware or otherwise) will be given the ability to respond to a request to indicate ‘not me but I know who should handle this’.  I’m thinking this makes more sense as a 5xx response with additional information (partition, nodes) about the route included in the response body (as opposed to a 3xx code)

My concern is that 5xx response is a kind of error that occurs on server side. The server can't handle the client request
due to internal error (500), not implemented (501), bad gateway(502), service unavailable(503), gateway timeout(504)
or http version not supported(505).  It doesn't make much sense to use it in your context of 'not me but I know who should handle this’.

I'm also curious about how could this happen if the object URL is the unique identity. How does the server exactly know what client
request is another object? Based on what kind of information?
Edward Zhang(张华)
Advisory Software Engineer
Software Standards & Open Source Software
Emerging Technology Institute(ETI)
IBM China Software Development Lab
e-mail: zhuadl at cn.ibm.com<mailto:zhuadl at cn.ibm.com>




[Inactive hide details for "Luse, Paul E" ---2013-06-01 上午 07:53:21---"Luse, Paul E" <paul.e.luse at intel.com>]"Luse, Paul E" ---2013-06-01 上午 07:53:21---"Luse, Paul E" <paul.e.luse at intel.com<mailto:paul.e.luse at intel.com>>
"Luse, Paul E" <paul.e.luse at intel.com<mailto:paul.e.luse at intel.com>>
Sent by: "Openstack" <openstack-bounces+zhuadl=cn.ibm.com at lists.launchpad.net<mailto:openstack-bounces+zhuadl=cn.ibm.com at lists.launchpad.net>>

2013-06-01 上午 07:53


To


"openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>,


cc




Subject


[Openstack] [Swift] Storage Server Redirection








I’m looking at tacking this item:



https://blueprints.launchpad.net/swift/+spec/support-storage-server-redirects



and wanted to get some feedback on the following observations/thoughts:



1) This is a capability that would be checked in independent of other blueprints that might use it (2 are mentioned in the link above) and unit test code would be the only way to initially exercise it; it essentially enables other activities at this point



2) The basic idea is that an object server (via middleware or otherwise) will be given the ability to respond to a request to indicate ‘not me but I know who should handle this’.  I’m thinking this makes more sense as a 5xx response with additional information (partition, nodes) about the route included in the response body (as opposed to a 3xx code)



3) The proxy server will be modified to process the response accordingly but using the partition, nodes info from the response as opposed to object_ring.get_nodes() to determine which nodes to use



4) Protection will be required to avoid endless redirection loops



5) This applies only to GET operations



Appreciate any thoughts/feedback.,  In addition to the two usages of this capability referenced in the blueprint I think there’s applicable to another Tiering blueprint which interests me as well.



Thanks

Paul

 _______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130603/973e85b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130603/973e85b6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 105 bytes
Desc: image003.gif
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130603/973e85b6/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 168 bytes
Desc: image004.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130603/973e85b6/attachment-0001.png>


More information about the Openstack mailing list