[dev][keystone] Keystone Team Update - Week of 11 February 2019
# Keystone Team Update - Week of 11 February 2019
## News
### Blueprints Overhaul
After someone inquired about a very old Launchpad blueprint that was not aligned with reality, we started a campaign to clean up all of the keystone blueprints. Lance described the proposed plan[1] which is to stop using Launchpad blueprints for tracking feature work and to consolidate everything into specs and RFE bug reports. The plan is also in discussion in our spec template[2]. Once we have our backlog cleaned up, it will hopefully be a little more straightforward to port all of our tracked work into Storyboard when the time comes. There are also quite a few open blueprints that we need to discuss as a team to reaffirm whether they are moving in the right direction and still worthwhile[3].
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002672.... [2] https://review.openstack.org/625282 [3] https://etherpad.openstack.org/p/keystone-blueprint-cleanup
### OpenStack User Survey
Since the Foundation is working on this year's user survey, we talked about what we want included on it[4]. We've found the current keystone question is not really detailed enough to give us concrete feedback, but unfortunately we're limited to two questions. We decided to add one additional question[5] and the Foundation has also offered to help collect more fine-grained feedback via a Surveymonkey survey.
[4] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-02-12-16... [5] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-ke...
## Recently Merged Changes
Search query: https://bit.ly/2pquOwT
We merged 16 changes this week.
## Changes that need Attention
Search query: https://bit.ly/2RLApdA
There are 68 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots.
## Bugs
This week we opened 6 new bugs and closed 3.
Bugs opened (6) Bug #1815539 (keystone:High) opened by Guang Yee https://bugs.launchpad.net/keystone/+bug/181553 Bug #1815771 (keystone:Medium) opened by Jose Castro Leon https://bugs.launchpad.net/keystone/+bug/1815771 Bug #1815810 (keystone:Low) opened by Drew Freiberger https://bugs.launchpad.net/keystone/+bug/1815810 Bug #1815966 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815966 Bug #1815971 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815971 Bug #1815972 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815972
Bugs fixed (3) Bug #1804446 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804446 Bug #1805372 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805372 Bug #1813739 (keystonemiddleware:Undecided) fixed by Yang Youseok https://bugs.launchpad.net/keystonemiddleware/+bug/1813739
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
## Help with this newsletter
Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter
On 2/15/19 11:23 AM, Colleen Murphy wrote:
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
Reading this, it occurred to me that we probably shouldn't be applying Oslo feature freeze to co-owned libraries. Most of those function more as non-client libraries than the oslo.* libs, so there's no need to freeze early.
I've proposed https://review.openstack.org/637588 to reflect that in the Oslo policy. If you have an opinion on it please vote!
-Ben
On Mon, Feb 18, 2019, at 6:11 PM, Ben Nemec wrote:
On 2/15/19 11:23 AM, Colleen Murphy wrote:
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
Reading this, it occurred to me that we probably shouldn't be applying Oslo feature freeze to co-owned libraries. Most of those function more as non-client libraries than the oslo.* libs, so there's no need to freeze early.
I've proposed https://review.openstack.org/637588 to reflect that in the Oslo policy. If you have an opinion on it please vote!
-Ben
Thanks for mentioning that, I didn't even notice that Oslo had an earlier freeze date. Arguably oslo.policy should be held to the same standard as the other Oslo libraries since it has such far reach. Oslo.limit not so much yet.
Colleen
On 2/18/19 3:19 PM, Colleen Murphy wrote:
On Mon, Feb 18, 2019, at 6:11 PM, Ben Nemec wrote:
On 2/15/19 11:23 AM, Colleen Murphy wrote:
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
Reading this, it occurred to me that we probably shouldn't be applying Oslo feature freeze to co-owned libraries. Most of those function more as non-client libraries than the oslo.* libs, so there's no need to freeze early.
I've proposed https://review.openstack.org/637588 to reflect that in the Oslo policy. If you have an opinion on it please vote!
-Ben
Thanks for mentioning that, I didn't even notice that Oslo had an earlier freeze date. Arguably oslo.policy should be held to the same standard as the other Oslo libraries since it has such far reach. Oslo.limit not so much yet.
Oh, hmm. I forgot we had oslo.* libraries that were co-owned too. I agree those should probably be kept to the Oslo feature freeze date. I'll update the policy change to reflect that, and maybe make a note that the policy is a guideline, not a hard and fast rule. If it makes sense to freeze a library earlier then we should do that regardless of what the policy says. I'm just trying to avoid stepping on other teams' toes unnecessarily.
Note that oslo.limit falls under the "not released yet" exception (unfortunately) so feature freeze doesn't apply to it at all.
Colleen
On 2/18/19 3:38 PM, Ben Nemec wrote:
On 2/18/19 3:19 PM, Colleen Murphy wrote:
On Mon, Feb 18, 2019, at 6:11 PM, Ben Nemec wrote:
On 2/15/19 11:23 AM, Colleen Murphy wrote:
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
Reading this, it occurred to me that we probably shouldn't be applying Oslo feature freeze to co-owned libraries. Most of those function more as non-client libraries than the oslo.* libs, so there's no need to freeze early.
I've proposed https://review.openstack.org/637588 to reflect that in the Oslo policy. If you have an opinion on it please vote!
-Ben
Thanks for mentioning that, I didn't even notice that Oslo had an earlier freeze date. Arguably oslo.policy should be held to the same standard as the other Oslo libraries since it has such far reach. Oslo.limit not so much yet.
Oh, hmm. I forgot we had oslo.* libraries that were co-owned too. I agree those should probably be kept to the Oslo feature freeze date. I'll update the policy change to reflect that, and maybe make a note that the policy is a guideline, not a hard and fast rule. If it makes sense to freeze a library earlier then we should do that regardless of what the policy says. I'm just trying to avoid stepping on other teams' toes unnecessarily.
Note that oslo.limit falls under the "not released yet" exception (unfortunately) so feature freeze doesn't apply to it at all.
++
This will apply once we get a 1.0 release, I think? We could release oslo.limit after feature freeze and still make changes to it up until we release a 1.0... then we're are the point of no return (dun dun dun!).
Colleen
On 2/18/19 4:28 PM, Lance Bragstad wrote:
On 2/18/19 3:38 PM, Ben Nemec wrote:
On 2/18/19 3:19 PM, Colleen Murphy wrote:
On Mon, Feb 18, 2019, at 6:11 PM, Ben Nemec wrote:
On 2/15/19 11:23 AM, Colleen Murphy wrote:
## Milestone Outlook
https://releases.openstack.org/stein/schedule.html
Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP.
Reading this, it occurred to me that we probably shouldn't be applying Oslo feature freeze to co-owned libraries. Most of those function more as non-client libraries than the oslo.* libs, so there's no need to freeze early.
I've proposed https://review.openstack.org/637588 to reflect that in the Oslo policy. If you have an opinion on it please vote!
-Ben
Thanks for mentioning that, I didn't even notice that Oslo had an earlier freeze date. Arguably oslo.policy should be held to the same standard as the other Oslo libraries since it has such far reach. Oslo.limit not so much yet.
Oh, hmm. I forgot we had oslo.* libraries that were co-owned too. I agree those should probably be kept to the Oslo feature freeze date. I'll update the policy change to reflect that, and maybe make a note that the policy is a guideline, not a hard and fast rule. If it makes sense to freeze a library earlier then we should do that regardless of what the policy says. I'm just trying to avoid stepping on other teams' toes unnecessarily.
Note that oslo.limit falls under the "not released yet" exception (unfortunately) so feature freeze doesn't apply to it at all.
++
This will apply once we get a 1.0 release, I think? We could release oslo.limit after feature freeze and still make changes to it up until we release a 1.0... then we're are the point of no return (dun dun dun!).
I think it's more about when a library has consumers than a strict version. Castellan technically just went 1.0 this cycle, but we've observed feature freeze for it because it had consumers (and really should have been 1.0). Ideally we want "has consumers" and "declared 1.0" to happen fairly close together so we aren't breaking people, but if the latter doesn't happen in a timely fashion we still need to not break people. :-)
And just to tie a bow on the policy change discussion, I'm planning to abandon it. I discovered that both my examples were used in other non-client libraries, which means the rationale for freezing them early still applies. Maybe there is an Oslo library that doesn't need to, but we have the FFE process precisely for such exceptional cases. It seems I jumped the gun a bit on wanting to change the policy. Sorry for subjecting everyone to the noise of my train of thought, but hey, we are going back to Denver! ;-)
Colleen
participants (3)
-
Ben Nemec
-
Colleen Murphy
-
Lance Bragstad