Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
Le 30/05/2014 14:00, Sylvain Bauza a écrit : Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain The bug by itself... [1] https://bugs.launchpad.net/keystone/+bug/1324861 -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza sba...@redhat.com wrote: Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
Le 30/05/2014 14:07, Dina Belova a écrit : I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? Got the Ironic patch as well : https://review.openstack.org/#/c/96576/1/ironic/tests/api/utils.py Will provide a patch against Blazar. Btw, I'll close the bug. -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza sba...@redhat.com mailto:sba...@redhat.com wrote: Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
The auth_token middleware changed recently[1] to check if tokens retrieved from the cache are expired based on the expiration time in the token. The unit tests for Blazar, Ceilometer, and Ironic are all using a copy-pasted fake memcache implementation that's supposed to simulate what auth_token stores in the cache, but the tokens that it had stored weren't valid. Tokens have an expiration time in them and these ones didn't. I don't think that it's safe for test code to make assumptions about how the auth_token middleware is going to store data in its cache. The format of the cached data isn't part of the public interface. It's changed before, when expiration times changed from *nix timestamps to iso 8601 formatted dates. After looking at this, I proposed a couple of changes to the auth_token middleware. One is to have auth_token use the expiration time it has cached and fail the auth request if the token is expired according to the cache. It doesn't have to check the token's expiration time because it was stored as part of the cache data. The other is to make cached token handling more efficient by not checking the token expiration time if the token was cached. [1] http://git.openstack.org/cgit/openstack/python-keystoneclient/commit/keystoneclient/middleware/auth_token.py?id=8574256f9342faeba2ce64080ab5190023524e0a [2] https://review.openstack.org/#/c/96786/ - Brant On Fri, May 30, 2014 at 7:11 AM, Sylvain Bauza sba...@redhat.com wrote: Le 30/05/2014 14:07, Dina Belova a écrit : I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? Got the Ironic patch as well : https://review.openstack.org/#/c/96576/1/ironic/tests/api/utils.py Will provide a patch against Blazar. Btw, I'll close the bug. -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza sba...@redhat.com wrote: Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
Would it make sense to provide a test fixture in the middleware library for projects who want or need to test with token management? Doug On Fri, May 30, 2014 at 12:49 PM, Brant Knudson b...@acm.org wrote: The auth_token middleware changed recently[1] to check if tokens retrieved from the cache are expired based on the expiration time in the token. The unit tests for Blazar, Ceilometer, and Ironic are all using a copy-pasted fake memcache implementation that's supposed to simulate what auth_token stores in the cache, but the tokens that it had stored weren't valid. Tokens have an expiration time in them and these ones didn't. I don't think that it's safe for test code to make assumptions about how the auth_token middleware is going to store data in its cache. The format of the cached data isn't part of the public interface. It's changed before, when expiration times changed from *nix timestamps to iso 8601 formatted dates. After looking at this, I proposed a couple of changes to the auth_token middleware. One is to have auth_token use the expiration time it has cached and fail the auth request if the token is expired according to the cache. It doesn't have to check the token's expiration time because it was stored as part of the cache data. The other is to make cached token handling more efficient by not checking the token expiration time if the token was cached. [1] http://git.openstack.org/cgit/openstack/python-keystoneclient/commit/keystoneclient/middleware/auth_token.py?id=8574256f9342faeba2ce64080ab5190023524e0a [2] https://review.openstack.org/#/c/96786/ - Brant On Fri, May 30, 2014 at 7:11 AM, Sylvain Bauza sba...@redhat.com wrote: Le 30/05/2014 14:07, Dina Belova a écrit : I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? Got the Ironic patch as well : https://review.openstack.org/#/c/96576/1/ironic/tests/api/utils.py Will provide a patch against Blazar. Btw, I'll close the bug. -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza sba...@redhat.com wrote: Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
+1 to a fixture for the middleware if this is a common practice to do unit testing in this manner. The main issue here was mocking out the cache and using a hand-crafted “valid” token. We have a mechanism provided in the keystone client library that allows for creating a valid token (all the required fields, etc): https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/fixture/v3.py#L48 for example. — Morgan Fainberg From: Doug Hellmann doug.hellm...@dreamhost.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: May 30, 2014 at 14:08:16 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0 Would it make sense to provide a test fixture in the middleware library for projects who want or need to test with token management? Doug On Fri, May 30, 2014 at 12:49 PM, Brant Knudson b...@acm.org wrote: The auth_token middleware changed recently[1] to check if tokens retrieved from the cache are expired based on the expiration time in the token. The unit tests for Blazar, Ceilometer, and Ironic are all using a copy-pasted fake memcache implementation that's supposed to simulate what auth_token stores in the cache, but the tokens that it had stored weren't valid. Tokens have an expiration time in them and these ones didn't. I don't think that it's safe for test code to make assumptions about how the auth_token middleware is going to store data in its cache. The format of the cached data isn't part of the public interface. It's changed before, when expiration times changed from *nix timestamps to iso 8601 formatted dates. After looking at this, I proposed a couple of changes to the auth_token middleware. One is to have auth_token use the expiration time it has cached and fail the auth request if the token is expired according to the cache. It doesn't have to check the token's expiration time because it was stored as part of the cache data. The other is to make cached token handling more efficient by not checking the token expiration time if the token was cached. [1] http://git.openstack.org/cgit/openstack/python-keystoneclient/commit/keystoneclient/middleware/auth_token.py?id=8574256f9342faeba2ce64080ab5190023524e0a [2] https://review.openstack.org/#/c/96786/ - Brant On Fri, May 30, 2014 at 7:11 AM, Sylvain Bauza sba...@redhat.com wrote: Le 30/05/2014 14:07, Dina Belova a écrit : I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? Got the Ironic patch as well : https://review.openstack.org/#/c/96576/1/ironic/tests/api/utils.py Will provide a patch against Blazar. Btw, I'll close the bug. -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza sba...@redhat.com wrote: Hi Keystone developers, I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches are failing due to a new release in Keystone client which seems to regress on midleware auth. Do you have any ideas on if it's quick to fix, or shall I provide a patch to openstack/global-requirements.txt to only accept keystoneclient 0.9.0 ? Thanks, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
