+++ This bug was initially created as a clone of Bug #1213999 +++ Description of problem: tokens are not cached How reproducible: always Steps to Reproduce: 1. Configure rgw with keystone server for authentication 2. Send a request that will be authenticated through keystone 3. Send another request with the same token Actual results: Second request is going through keystone Expected results: Second request should not go through keystone Additional info: Fixed upstream
It looks like the patch we will want to incorporate downstream for this is https://github.com/ceph/ceph/pull/4414
When rgw receives a token that is not cached, it goes to keystone to validate it. Then it's supposed to cache it. A subsequent request using the same token will not require rgw to go to keystone again, therefore reduce the response time and reduce the load on the keystone server. The bug is about rgw not caching tokens so that rgw validates the tokens again, even if tokens were supposed to be cached.
(In reply to Yehuda Sadeh from comment #5) > When rgw receives a token that is not cached, it goes to keystone to > validate it. Then it's supposed to cache it. A subsequent request using the > same token will not require rgw to go to keystone again, therefore reduce > the response time and reduce the load on the keystone server. The bug is > about rgw not caching tokens so that rgw validates the tokens again, even if > tokens were supposed to be cached. Ok thanks understood. I would verify this by looking at rgw logs while doing the first and subsequent requests using the same token. First request: # curl -X PUT -i -H "X-Auth-Token: 8e0b7bf72f984275a957111527163913" -T RECIPE.TXT "http://10.x.x.x/swift/v1/third_container/RECIPE.TXT" Logs from rgw host: 2015-06-18 11:50:06.276918 7f0ba7fc7700 1 ====== starting new request req=0x7f0c2c004220 ===== 2015-06-18 11:50:06.358077 7f0ba7fc7700 0 validated token: swift-tenant:swift expires: 1434646181 2015-06-18 11:50:06.446830 7f0ba7fc7700 1 ====== req done req=0x7f0c2c004220 http_status=201 ====== 2015-06-18 11:50:06.446998 7f0ba7fc7700 1 civetweb: 0x7f0c2c0088c0: 10.12.27.41 - - [18/Jun/2015:11:50:06 -0400] "PUT /swift/v1/third_container/NETBOOT_METHOD.TXT HTTP/1.1" -1 0 - curl/7.29.0 Second line in the above logs shows the token validation. Second request with the same token: # curl -X GET -i -H "X-Auth-Token: 8e0b7bf72f984275a957111527163913" "http://10.x.x.x/swift/v1/third_container/RECIPE.TXT" HTTP/1.1 200 OK Logs from host: 2015-06-18 11:51:48.319990 7f0ba6fc5700 1 ====== starting new request req=0x7f0c380172c0 ===== 2015-06-18 11:51:48.427717 7f0ba6fc5700 1 ====== req done req=0x7f0c380172c0 http_status=201 ====== 2015-06-18 11:51:48.427881 7f0ba6fc5700 1 civetweb: 0x7f0c3800c6d0: 10.12.27.41 - - [18/Jun/2015:11:51:48 -0400] "PUT /swift/v1/third_container/RECIPE.TXT HTTP/1.1" -1 0 - curl/7.29.0 Shows it did not validate the token from keystone server the second time. Moving this to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1183