Open Stack

On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor <mordred at inaugust.com> wrote:

> On 07/22/2017 07:14 AM, Lance Bragstad wrote:
>
>> After a little head scratching and a Pantera playlist later, we ended up
>> figuring out the main causes. The failures can be found in the gate [0].
>> The two failures are detailed below:
>>
>> 1.) Keystoneauth version 3.0.0 added a lot of functionality and might
>> return a different url depending on discovery. Keystonemiddleware use to
>> be able to mock urls to keystone in this case because keystoneauth
>> didn't modify the url in between. Keystonemiddleware didn't know how to
>> deal with the new url and the result was a Mock failure. This is
>> something that we can fix in keystonemiddleware once we have a version
>> of keystoneauth that covers all discovery cases and does the right
>> thing. NOTE: If you're mocking requests to keystone and using
>> keystoneauth somewhere in your project's tests, you'll have to deal with
>> this. More on that below.
>>
>
> Upon further digging - this one is actually quite a bit easier. There are
> cases where keystoneauth finds an unversioned discovery endpoint from a
> versioned endpoint in the catalog. It's done for quite a while, so the
> behavior isn't new. HOWEVER - a bug snuck in that caused the url it infers
> to come back without a trailing '/'. So the requests_mock entry in
> keystonemiddleware was for http://keystone.url/admin/ and keystoneauth
> was doing a get on http://keystone.url/admin.
>
> It's a behavior change and a bug, so we're working up a fix for it. The
> short story is though that once we fix it it should not cause anyone to
> need to update requests_mock entries.


Ah - thanks for keeping me honest here. Good to know both issues will be
fixed with the same patch. For context, this was the thought process as we
worked through things earlier [0].

I appreciate the follow-up!


[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-07-21.log.html#t2017-07-21T19:57:30


>
> 2.) The other set of failures were because keystoneauth wasn't expecting
>> a URL without a path [1], causing an index error. I tested the fix [2]
>> against keystonemiddleware and it seems to take care of the issue. Eric
>> is working on a fix. Once that patch is fully tested and vetted we'll
>> roll another keystoneauth release (3.0.1) and use that to test
>> keystonemiddleware to handle the mocking issues described in #1. From
>> there we should be able to safely bump the minimum version to 3.0.1, and
>> avoid 3.0.0 all together.
>>
>
> Patch is up for this one, and we've confirmed it fixes this issue.
>
> Let me know if you see anything else suspicious with respect to
>> keystoneauth. Thanks!
>>
>>
>> [0]
>> http://logs.openstack.org/84/486184/1/check/gate-keystonemid
>> dleware-python27-ubuntu-xenial/7c079da/testr_results.html.gz
>> [1]
>> https://github.com/openstack/keystoneauth/blob/5715035f42780
>> d8979d458e9f7e3c625962b2749/keystoneauth1/discover.py#L947
>> [2] https://review.openstack.org/#/c/486231/1
>>
>> On 07/21/2017 04:43 PM, Lance Bragstad wrote:
>>
>>> The patch to blacklist version 3.0.0 is working through the moment [0].
>>> We also have a WIP patch proposed to handled the cases exposed by
>>> keystonemiddleware [1].
>>>
>>>
>>> [0] https://review.openstack.org/#/c/486223/
>>> [1] https://review.openstack.org/#/c/486231/
>>>
>>>
>>> On 07/21/2017 03:58 PM, Lance Bragstad wrote:
>>>
>>>> We have a patch up to blacklist version 3.0.0 from global-requirements
>>>> [0]. We're also going to hold bumping the minimum version of
>>>> keystoneauth until we have things back to normal [1].
>>>>
>>>>
>>>> [0] https://review.openstack.org/#/c/486223/
>>>> [1] https://review.openstack.org/#/c/486160/1
>>>>
>>>> On 07/21/2017 03:00 PM, Lance Bragstad wrote:
>>>>
>>>>> I started noticing some trivial changes failing in the
>>>>> keystonemiddleware gate [0]. The failures are in tests that use the
>>>>> keystoneauth1 library (8 tests are failing by my count), which we
>>>>> released a new version of yesterday [1]. I've proposed a patch to
>>>>> blacklist keystoneauth1 3.0.0 from keystonemiddleware until we can
>>>>> figure out what happened [2]. Status is being tracked in a bug against
>>>>> keystonemiddleware [3], but might need to be broadened if these changes
>>>>> are affecting other projects.
>>>>>
>>>>> I'll be in -keystone working through some of the issues if you need me.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lance
>>>>>
>>>>> [0] https://review.openstack.org/#/c/486184/
>>>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-July
>>>>> /119969.html
>>>>> [2] https://review.openstack.org/#/c/486213/
>>>>> [3] https://bugs.launchpad.net/keystonemiddleware/+bug/1705770
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170721/b3fc038c/attachment.html>