Open Stack

You’ve got it right that its internal between proxy and object…  totally transparent to the client.

Thx
Paul

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


Paul,

I might misunderstand your blueprint here. it make sense to me if redirection happens internally b/w proxy server and object server.
I have thought this redirection happens b/w client and proxy server, and a new object URL will be sent to client.

Best Regards,

________________________________
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>
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483

地址:北京市海淀区东北旺西路8号 中关村软件园28号楼 环宇大厦3层 邮编：100193
Address: 3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193

[cid:image001.png at 01CE608B.2E7010E0]







[Inactive hide details for "Luse, Paul E" ---06/03/2013 08:14:26 PM---"Luse, Paul E" <paul.e.luse at intel.com>]"Luse, Paul E" ---06/03/2013 08:14:26 PM---"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>>

06/03/2013 08:14 PM


To


Hua ZZ Zhang/China/IBM at IBMCN,


cc


"openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>, Openstack <openstack-bounces+zhuadl=cn.ibm.com at lists.launchpad.net<mailto:openstack-bounces+zhuadl=cn.ibm.com at lists.launchpad.net>>


Subject


RE: [Openstack] [Swift] Storage Server Redirection








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<mailto: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/20130604/0c373e9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1279 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 166 bytes
Desc: image003.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 105 bytes
Desc: image004.gif
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 168 bytes
Desc: image005.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 166 bytes
Desc: image006.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 168 bytes
Desc: image007.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/0c373e9c/attachment-0004.png>