[Openstack] [Swift] Storage Server Redirection
Hua ZZ Zhang
zhuadl at cn.ibm.com
Tue Jun 4 01:33:15 UTC 2013
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(张华) 地址:北京市海淀区东北旺西路8号 中关村
Advisory Software Engineer 软件园28号楼 环宇大厦3层 邮编:100193
Software Standards & Open Source Address: 3F Ring, Building 28
Software Zhongguancun Software Park, 8
Emerging Technology Institute(ETI) Dongbeiwang West Road, Haidian
IBM China Software Development Lab District, Beijing, P.R.C.100193
e-mail: zhuadl at cn.ibm.com
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483
"Luse, Paul E"
<paul.e.luse at inte
l.com> To
Hua ZZ Zhang/China/IBM at IBMCN,
06/03/2013 08:14 cc
PM "openstack at lists.launchpad.net"
<openstack at lists.launchpad.net>,
Openstack <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; 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
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>
"Luse, Paul E" <
paul.e.luse at intel.com>
Sent by: "Openstack" <
openstack-bounces
+zhuadl=cn.ibm.com at lists.launch
pad.net>
To
2013-06-01 上午 07:53
"
openstack at lists.la
unchpad.net" <
openstack at lists.la
unchpad.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
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/d818539d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 46565267.gif
Type: image/gif
Size: 1279 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic06973.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 46495782.gif
Type: image/gif
Size: 166 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 46022436.gif
Type: image/gif
Size: 168 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130604/d818539d/attachment-0005.gif>
More information about the Openstack
mailing list