Open Stack

Lance, other keystone cores,

there's a request for 3.0.1, but one of the reviews that it needs is
not merged yet

https://review.openstack.org/#/c/486231/


Thansk,
Dims

On Fri, Jul 21, 2017 at 11:40 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
>
>
> 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-keystonemiddleware-python27-ubuntu-xenial/7c079da/testr_results.html.gz
>>> [1]
>>>
>>> https://github.com/openstack/keystoneauth/blob/5715035f42780d8979d458e9f7e3c625962b2749/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:unsubscribe
>>> 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
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims