openstack team mailing list archive

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

Great, thanks Edward.  I was discussing that with a colleague here and that's pretty much what we were thinking it was.  Out of curiosity, where are you at one this?

Thanks
Paul

From: Hua ZZ Zhang [mailto:zhuadl@xxxxxxxxxx]
Sent: Monday, June 03, 2013 10:51 PM
To: Luse, Paul E
Cc: openstack@xxxxxxxxxxxxxxxxxxx; Openstack; Peter Portante
Subject: Re: [Openstack] [Swift] Storage Server Redirection


Paul,

The blueprint of object-variation<https://blueprints.launchpad.net/swift/+spec/object-variation> is able to allow an object to have variant versions which are derived from the original master object. The access to the master object can be smartly adapted or redirected to matched version for different clients (web browser, mobile app,  video player). One possible solution is that you can add system metadata for master object to refer to those variant versions. When proxy server get client information from HTTP headers, it will relay it to object server so that it can determine which version is a better choice based on system metadata. If current version is not good choice, reply a redirect response to tell proxy server the right one. Another solution can be based on object versioning feature to pick up the right version for client based on its request information.

Thanks!

-Edward Zhang


[Inactive hide details for "Luse, Paul E" ---06/03/2013 08:42:04 PM---"Luse, Paul E" <paul.e.luse@xxxxxxxxx>]"Luse, Paul E" ---06/03/2013 08:42:04 PM---"Luse, Paul E" <paul.e.luse@xxxxxxxxx<mailto:paul.e.luse@xxxxxxxxx>>
"Luse, Paul E" <paul.e.luse@xxxxxxxxx<mailto:paul.e.luse@xxxxxxxxx>>
Sent by: "Openstack" <openstack-bounces+zhuadl=cn.ibm.com@xxxxxxxxxxxxxxxxxxx<mailto:openstack-bounces+zhuadl=cn.ibm.com@xxxxxxxxxxxxxxxxxxx>>

06/03/2013 08:41 PM


To


Peter Portante <peter.a.portante@xxxxxxxxx<mailto:peter.a.portante@xxxxxxxxx>>,


cc


"openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>


Subject


Re: [Openstack] [Swift] Storage Server Redirection








Hi Peter,

I'd ask that Edward may want to chime in on object variation as I may not understand that one correctly - again I'm proposing to just implement the redirect response blueprint and reference object variation as a potential user simply because John mentioned it in his original write-up of the redirect response blueprint.  Edward?

Wrt your second question, there are copies of the rings on object servers as well and they are used for lookup in various scenarios, replication for one.  As an example take a small 6 node cluster where all servers are running all services, if an admin adds/deletes a device from the ring they do so on one of the nodes and then copes the .gz file to all the others.  During the window when the first node detects the new ring file and .gz files are copied to all the other nodes and detected/brought into memory, any responses fielded by the proxy service on the other nodes will have older ring info than the first node updated.  Another case could be a larger cluster where there's a proxy tier and a capacity tier (not all services running everywhere).  The admin could update the ring on any node and copy the ring files on the nodes in any order - if any capacity node gets an update before any proxy node you can run into the same scenario.  The ring versions blueprint was John's s!
o he may have additions/corrections....

Thanks
Paul


-----Original Message-----
From: Peter Portante [mailto:peter.a.portante@xxxxxxxxx]
Sent: Monday, June 03, 2013 3:50 AM
To: Luse, Paul E
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] [Swift] Storage Server Redirection

Hi Paul,

Can you explain more about the two use cases referenced?

Object Variation seems like a nice idea, but can you clarify how the mechanism would work to get at the variations? Any examples? From the current descriptions, it seems like the LFS Patch could help here without adding anything to the object server.

Regarding the ring updates, given that rings are used by the proxy servers, and as far as I can tell, the object servers don't know about the rings, how would object servers have more up-to-date knowledge to perform the redirect?

Thanks,

-peter


On Fri, May 31, 2013 at 7:53 PM, Luse, Paul E <paul.e.luse@xxxxxxxxx<mailto:paul.e.luse@xxxxxxxxx>> wrote:
> I'm looking at tacking this item:
>
>
>
> https://blueprints.launchpad.net/swift/+spec/support-storage-server-re
> directs
>
>
>
> 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@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

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