[keystone] Keystone Team Update - Week of 14 October 2019
# Keystone Team Update - Week of 14 October 2019
## News
### Train Released
Keystone has been successfully released for the Train cycle! Congratulations everyone on a smooth release. Check out the release notes[1] for details on what's new in this release.
[1] https://docs.openstack.org/releasenotes/keystone/train.html
## Office Hours
When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC.
No office hours next week due to no topics.
Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics
## Recently Merged Changes
Search query: https://bit.ly/2pquOwT
We merged 21 changes this week.
## Changes that need Attention
Search query: https://bit.ly/2tymTje
There are 39 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots.
### Priority Reviews
* Roadmap Stories
- Keystone to Keystone Testing https://tree.taiga.io/project/keystone-ussuri-roadmap/us/39 + https://review.opendev.org/580041 Keystone to Keystone tests + https://review.opendev.org/689208 Use up-to-date federation job names + https://review.opendev.org/689222 Add option to disable testing against external idp + https://review.opendev.org/689223 Add voting k2k tests - Federated Attributes for Users https://tree.taiga.io/project/keystone-ussuri-roadmap/us/32 + https://review.opendev.org/448755 Add federated support for creating a user + https://review.opendev.org/448730 https://review.opendev.org/448730
* Needs Discussion
- https://review.opendev.org/687753 Drop project.id foreign keys - https://review.opendev.org/687756 Revert "Resource backend is SQL only now"
* Oldest
- https://review.opendev.org/373983 OpenID Connect improved support
* Special Requests
- https://review.opendev.org/687362 Set up for Ussuri - https://review.opendev.org/689558 Fix line-length PEP8 errors for c7fae97 - https://review.opendev.org/689559 Re-enable line-length linter
* Closes Bugs
- https://review.opendev.org/687990 Stop adding entry in local_user while updating ephemerals - https://review.opendev.org/688939 Remove group deletion for non-sql driver when removing domains. - https://review.opendev.org/685042 Fetch discovery documents with auth when needed
## Bugs
This week we opened 5 new bugs and closed 2.
Bugs opened (5) Bug #1848238 (keystone:Medium) opened by Sami Makki https://bugs.launchpad.net/keystone/+bug/1848238 Bug #1848342 (keystone:Medium) opened by Pedro Henrique Pereira Martins https://bugs.launchpad.net/keystone/+bug/1848342 Bug #1848400 (keystone:Undecided) opened by Eric Xie https://bugs.launchpad.net/keystone/+bug/1848400 Bug #1848470 (keystone:Undecided) opened by yongyi,ren https://bugs.launchpad.net/keystone/+bug/1848470 Bug #1848625 (keystone:Undecided) opened by David Coronel https://bugs.launchpad.net/keystone/+bug/1848625
Bugs closed (2) Bug #1848400 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1848400 Bug #1848625 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1848625
Bugs fixed (0)
## Milestone Outlook
https://releases.openstack.org/ussuri/schedule.html
Keystone-specific deadlines have been proposed[2].
[2] https://review.opendev.org/689549
## Shout-outs
Thanks to the whole team for making this a smooth release!
## Help with this newsletter
Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter
Hello everyone,
I think I have found a significant bug in the futurist concurrency library that is breaking for my application.
If I launch a threadpool and submit n > 1 number of tasks. If now for any n of these tasks such a task calls Condition.wait(). Than when waiters.wait_for_any is called from the main thread it will block indefinitely instead of returning the n - 1 tasks that have completed. Furthermore setting the timeout parameter in wait_for_any is subsequently ignored.
I have submitted this as a bug report on launchpad: https://bugs.launchpad.net/futurist/+bug/1848457
Any help on this is really appreciated as I think it is a significant issue.
Kind regards, Corne Lukken (Dantali0n)
PS: I also submitted this over on stackoverflow: https://stackoverflow.com/questions/58410610/calling-condition-wait-inside-t...
Hello,
Thanks for the heads up.
You are right this is related to https://bugs.python.org/issue20319 futurist implement a similar code than the cpython concurrent.future code but not fixed yet.
I just submitted a patch to fix that, feel free to review it: - https://review.opendev.org/689691
Thanks
Le sam. 19 oct. 2019 à 08:44, info@dantalion.nl info@dantalion.nl a écrit :
Hello everyone,
I think I have found a significant bug in the futurist concurrency library that is breaking for my application.
If I launch a threadpool and submit n > 1 number of tasks. If now for any n of these tasks such a task calls Condition.wait(). Than when waiters.wait_for_any is called from the main thread it will block indefinitely instead of returning the n - 1 tasks that have completed. Furthermore setting the timeout parameter in wait_for_any is subsequently ignored.
I have submitted this as a bug report on launchpad: https://bugs.launchpad.net/futurist/+bug/1848457
Any help on this is really appreciated as I think it is a significant issue.
Kind regards, Corne Lukken (Dantali0n)
PS: I also submitted this over on stackoverflow:
https://stackoverflow.com/questions/58410610/calling-condition-wait-inside-t...
participants (3)
-
Colleen Murphy
-
Herve Beraud
-
info@dantalion.nl