Support storage servers sending redirect responses to the proxy
If the proxy server were able to properly handle redirect responses from storage nodes, then new features like https:/
This would also allow an object to redirect a request to the proper server in certain cases (eg https:/
Whiteboard
peluse> I’m looking at tackling this item:
and wanted to get some feedback on the following observations/
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_
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
Can you elaborate on this a little more wrt how you envision the sequence of events between proxy and object server in the event that the object server wants to redirect for whatever reason? For example, in the 2nd example above if you could walk through the messages/
Paul> Sure, I actually have the code in draft form available as well and a hack-UML sequence digram I can put into a JPG or something if I can figure out where to attach it. Its pretty simple though:
- when the obj service is ready to respond with NOT_FOUND because it can't really find the object, it checks to see if there is reason to believe that it knows where the object is. For example, instead of just saying NOT_FOUND, it checks the local version of the ring versus the version used by the proxy (that info is not currently available, it would be a 'user' of this feature) and if it has a new version it embeds the part,nodes in the response via 2 new headers and changes the status code to 301
- when the proxy gets a 301 response (currently not handled) it looks for the 2 new headers that the object server added and if they're there then it re-sends the GET using that info. If they're not there for whatever reason then it just responds to the caller with NOT_FOUND. The proxy will only try 3 redirects per request to avoid an endless redirection mess
+++++
June 24th, 2013
It seems that we are following a path of moving more smarts into the object servers with this kind of change. It is not clear that that path is one we want to continue down, but instead move smarts out of the object server and into the proxy server object controller layers. On the surface,this seems like a reasonable path to pursue, but we should consider this well.
-----
PL> Bailed on this following code review of changes - agree with comment above as well as review coments
Gerrit topic: https:/
Addressed by: https:/
Adds support for object server redirection responses
Addressed by: https:/
Adds support for object server redirection responses
