openstack team mailing list archive

["Luse, Paul E" <paul.e.luse@xxxxxxxxx>]

Thanks for the response John, see below...

Thx
Paul

-----Original Message-----
From: John Dickinson [mailto:me@xxxxxx] 
Sent: Sunday, June 02, 2013 11:29 PM
To: Luse, Paul E
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [Swift] Storage Server Redirection


On May 31, 2013, at 4:53 PM, "Luse, Paul E" <paul.e.luse@xxxxxxxxx> wrote:

> 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

correct, IMO, but see below.

>  
> 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)  

There are already some specific checks around a 5xx response from object servers that relate to failure handling. I'd assume a 3xx response would be used for redirects, with any additional info given in headers. Can you share more about why a 5xx response is more appropriate?

PL>  replied on another thread, I'm cool with 3xx

>  
> 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

yes

>  
> 4) Protection will be required to avoid endless redirection loops

Yes, but since this is handled by a single proxy worker on a per-request basis, protection should be fairly simple.

PL>  agreed, just calling it out for completeness

>  
> 5) This applies only to GET operations

Supporting this on writes can allow for less of a replication storm later if the object server knows the correct location before proxy is updated (eg during a cluster upgrade or a ring deploy).

PL>  I was just looking to simplify this but see your point.  Handling writes as well would be slightly more complex, unless I'm missing something, as the proxy would have to deal with multiple redirect responses that potentially don't match.  Is acceptable to approach it this was (GET only) and submit a 2nd blueprint to add PUT support or is that breaking it down too much?

>  
> 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.

The fun part will be figuring out what to do when the cluster is not in an internally consistent state (eg cluster upgrades or ring deployment times). You want to redirect if the object server knows best, but you don't if the proxy server knows best. It may make sense (from a usefulness perspective) to implement https://blueprints.launchpad.net/swift/+spec/send-ring-version first.

PL>  Or I could just merge them so neither contribution would be initially 'unused' when checked in - or another alternative would be that the proxy could include a new header to indicate that it is overriding any object redirection and for that request the obj server is to simply do as its told.  Or I could do both... 

>  
> Thanks
> Paul
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp