Re: [openstack-dev] [keystone] [all] keystoneauth version discovery is here

[Lance Bragstad]

There is a new release of keystoneauth1 available (3.0.1) that includes
some fixes that broke various projects. Full context is available in
another thread [0]. Please use keystoneauth1 3.0.1 instead of 3.0.0, which
we've blacklisted [1].

Thanks!


[0] http://lists.openstack.org/pipermail/openstack-dev/2017-July/120012.html
[1] https://review.openstack.org/#/c/486223/

On Thu, Jul 20, 2017 at 5:41 PM, Lance Bragstad  wrote:

> Happy Thursday,
>
> We just released keystoneauth 3.0.0 [0], which contains a bunch of
> built-in functionality to handle version discovery so that you don't
> have to! Check out the documentation for all the details [1].
>
> Big thanks to Eric and Monty for tackling this work, along with all the
> folks who diligently reviewed it.
>
>
> [0] https://review.openstack.org/#/c/485688/
> [1] https://docs.openstack.org/keystoneauth/latest/using-sessions.html
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

[Davanum Srinivas]

Thanks Eric. Shipping it.

On Sat, Jul 22, 2017 at 2:28 PM, Eric Fried  wrote:
> dims-
>
> SHA was good; just hadn't merged yet.  It has now.  All greens.
> Assuming lbragstad/morgan/mordred are on board, let's do it.
>
> Thanks,
> efried
>
> On 07/22/2017 10:06 AM, Davanum Srinivas wrote:
>> Lance,
>>
>> Ack. SHA needs to be fixed (https://review.openstack.org/#/c/486279/)
>>
>> Thanks,
>> Dims
>>
>> On Sat, Jul 22, 2017 at 10:24 AM, Lance Bragstad  wrote:
>>> Thanks Dims,
>>>
>>> Looks like Morgan and Monty have it working through the gate now.
>>>
>>> On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas  wrote:

 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 
 wrote:
>
>
> On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor 
> 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/

Re: [openstack-dev] [docs][neutron] doc-migration status

[Kevin Benton]

Could we just put a placeholder in those subprojects /admin directories
that redirects to the networking guide?

On Sat, Jul 22, 2017 at 10:50 AM, Doug Hellmann 
wrote:

> Excerpts from Akihiro Motoki's message of 2017-07-23 02:13:40 +0900:
> > Hi,
> >
> > I have a question on admin/ document related to the networking guide
> > and would like to have advices from the documentation experts.
> >
> > It seems the check site by Doug expect all project have admin/ page.
> > In the case of neutron the situation is a bit special. We have the
> > networking guide as admin/ document
> > in the neutron repo and it covers not only neutron itself but also
> > neutron stadium projects.
> > It means the neutron stadium projects sometimes (often?) have no
> > admin/ directory in their own repos
> > in favor of adding contents to the networking guide in neutron.
> >
> > Should Individual neutron stadium projects have their own admin guide
> > in their repositories,
> > or is it better to keep the networking guide which covers all
> > networking stuff in a single guide?
> >
> > What is the suggested way on the networking guide as the document expert?
>
> If the admin guides for all of those repos are combined, then I can
> modify the burndown chart generator to not count those as needed. Let me
> know if that's the best approach.
>
> Doug
>
> >
> > Thanks,
> > Akihiro
> >
> > 2017-07-22 3:26 GMT+09:00 Doug Hellmann :
> > > We've made huge progress, and are launching the updated landing
> > > pages for docs.openstack.org as I write this. Thanks to all of the
> > > contributors who have stepped up to write nearly 1,000 patches to
> > > improve the health of our documentation!
> > >
> > > We still have around 70 URLs we expected to see after the migration
> > > was complete but that produce a 404. I know some of the patches to
> > > produce those pages are in progress, but please check the list at
> > > https://doughellmann.com/doc-migration/ if your team is listed below
> > > to ensure that nothing has been missed.
> > >
> > >   cinder
> > >   cloudkitty
> > >   congress
> > >   designate
> > >   heat
> > >   ironic
> > >   karbor
> > >   keystone
> > >   magnum
> > >   manila
> > >   murano
> > >   neutron
> > >   nova
> > >   sahara
> > >   senlin
> > >   swift
> > >   tacker
> > >   telementry
> > >   tricircle
> > >   trove
> > >   vitrage
> > >   watcher
> > >   zaqar
> > >   zun
> > >
> > > Reply here or ping me in #openstack-docs if you have questions or need
> a
> > > hand.
> > >
> > > Doug
> > >
> > > ___
> > > OpenStack-docs mailing list
> > > openstack-d...@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

[Eric Fried]

dims-

SHA was good; just hadn't merged yet.  It has now.  All greens.
Assuming lbragstad/morgan/mordred are on board, let's do it.

Thanks,
efried

On 07/22/2017 10:06 AM, Davanum Srinivas wrote:
> Lance,
> 
> Ack. SHA needs to be fixed (https://review.openstack.org/#/c/486279/)
> 
> Thanks,
> Dims
> 
> On Sat, Jul 22, 2017 at 10:24 AM, Lance Bragstad  wrote:
>> Thanks Dims,
>>
>> Looks like Morgan and Monty have it working through the gate now.
>>
>> On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas  wrote:
>>>
>>> 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 
>>> wrote:


 On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor 
 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
 

Re: [openstack-dev] [docs][neutron] doc-migration status

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2017-07-23 02:13:40 +0900:
> Hi,
> 
> I have a question on admin/ document related to the networking guide
> and would like to have advices from the documentation experts.
> 
> It seems the check site by Doug expect all project have admin/ page.
> In the case of neutron the situation is a bit special. We have the
> networking guide as admin/ document
> in the neutron repo and it covers not only neutron itself but also
> neutron stadium projects.
> It means the neutron stadium projects sometimes (often?) have no
> admin/ directory in their own repos
> in favor of adding contents to the networking guide in neutron.
> 
> Should Individual neutron stadium projects have their own admin guide
> in their repositories,
> or is it better to keep the networking guide which covers all
> networking stuff in a single guide?
> 
> What is the suggested way on the networking guide as the document expert?

If the admin guides for all of those repos are combined, then I can
modify the burndown chart generator to not count those as needed. Let me
know if that's the best approach.

Doug

> 
> Thanks,
> Akihiro
> 
> 2017-07-22 3:26 GMT+09:00 Doug Hellmann :
> > We've made huge progress, and are launching the updated landing
> > pages for docs.openstack.org as I write this. Thanks to all of the
> > contributors who have stepped up to write nearly 1,000 patches to
> > improve the health of our documentation!
> >
> > We still have around 70 URLs we expected to see after the migration
> > was complete but that produce a 404. I know some of the patches to
> > produce those pages are in progress, but please check the list at
> > https://doughellmann.com/doc-migration/ if your team is listed below
> > to ensure that nothing has been missed.
> >
> >   cinder
> >   cloudkitty
> >   congress
> >   designate
> >   heat
> >   ironic
> >   karbor
> >   keystone
> >   magnum
> >   manila
> >   murano
> >   neutron
> >   nova
> >   sahara
> >   senlin
> >   swift
> >   tacker
> >   telementry
> >   tricircle
> >   trove
> >   vitrage
> >   watcher
> >   zaqar
> >   zun
> >
> > Reply here or ping me in #openstack-docs if you have questions or need a
> > hand.
> >
> > Doug
> >
> > ___
> > OpenStack-docs mailing list
> > openstack-d...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][neutron] doc-migration status

[Akihiro Motoki]

Hi,

I have a question on admin/ document related to the networking guide
and would like to have advices from the documentation experts.

It seems the check site by Doug expect all project have admin/ page.
In the case of neutron the situation is a bit special. We have the
networking guide as admin/ document
in the neutron repo and it covers not only neutron itself but also
neutron stadium projects.
It means the neutron stadium projects sometimes (often?) have no
admin/ directory in their own repos
in favor of adding contents to the networking guide in neutron.

Should Individual neutron stadium projects have their own admin guide
in their repositories,
or is it better to keep the networking guide which covers all
networking stuff in a single guide?

What is the suggested way on the networking guide as the document expert?

Thanks,
Akihiro

2017-07-22 3:26 GMT+09:00 Doug Hellmann :
> We've made huge progress, and are launching the updated landing
> pages for docs.openstack.org as I write this. Thanks to all of the
> contributors who have stepped up to write nearly 1,000 patches to
> improve the health of our documentation!
>
> We still have around 70 URLs we expected to see after the migration
> was complete but that produce a 404. I know some of the patches to
> produce those pages are in progress, but please check the list at
> https://doughellmann.com/doc-migration/ if your team is listed below
> to ensure that nothing has been missed.
>
>   cinder
>   cloudkitty
>   congress
>   designate
>   heat
>   ironic
>   karbor
>   keystone
>   magnum
>   manila
>   murano
>   neutron
>   nova
>   sahara
>   senlin
>   swift
>   tacker
>   telementry
>   tricircle
>   trove
>   vitrage
>   watcher
>   zaqar
>   zun
>
> Reply here or ping me in #openstack-docs if you have questions or need a
> hand.
>
> Doug
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

[Davanum Srinivas]

Lance,

Ack. SHA needs to be fixed (https://review.openstack.org/#/c/486279/)

Thanks,
Dims

On Sat, Jul 22, 2017 at 10:24 AM, Lance Bragstad  wrote:
> Thanks Dims,
>
> Looks like Morgan and Monty have it working through the gate now.
>
> On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas  wrote:
>>
>> 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 
>> wrote:
>> >
>> >
>> > On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor 
>> > 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 

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

[Lance Bragstad]

Thanks Dims,

Looks like Morgan and Monty have it working through the gate now.

On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas  wrote:

> 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 
> wrote:
> >
> >
> > On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor 
> 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 

Re: [openstack-dev] [nova] placement/resource providers update 29

[Matt Riedemann]

On 7/21/2017 6:54 AM, Chris Dent wrote:

## Custom Resource Classes for Ironic

A spec for custom resource classes is being updated to reflect the
need to update the flavor and allocations of a previously allocated
ironic node that how has a custom resource class (such as
CUSTOM_SILVER_IRON):

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

The implementation of those changes has started at:

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

That gets the flavor adjustment. Do we also need to do allocation
cleanups or was that already done at some point in the past?


That's done:

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

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Queens PTG Planning

[Matt Riedemann]

I wanted to get some things documented for the Queens PTG so I've 
started an etherpad:


https://etherpad.openstack.org/p/nova-ptg-queens

Feel free to put down things you'd like to discuss. We'll shape it up later.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

[Davanum Srinivas]

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  wrote:
>
>
> On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor  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]
>>