15:00:38 <d34dh0r53> #startmeeting keystone
15:00:38 <opendevmeet> Meeting started Wed Dec 13 15:00:38 2023 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <opendevmeet> The meeting name has been set to 'keystone'
15:00:45 <d34dh0r53> #topic roll call
15:00:55 <d34dh0r53> admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla[m], lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m],mharley
15:01:45 <xek> o/
15:01:46 <d34dh0r53> o/
15:01:51 <bbobrov> o/
15:03:04 <d34dh0r53> #topic review past meeting work items
15:03:10 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-11-29-15.00.html
15:03:33 <d34dh0r53> d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:03:38 <d34dh0r53> no update on this
15:03:41 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:03:48 <d34dh0r53> d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:03:51 <d34dh0r53> nor this :/
15:03:54 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:04:01 <d34dh0r53> d34dh0r53 email gtema (artem.goncharov@gmail.com) a reviewathon invite
15:04:05 <d34dh0r53> this has been done
15:04:12 <d34dh0r53> d34dh0r53 add reviewathon information to the Keystone Meetings page on the Openstack Wiki
15:04:18 <d34dh0r53> this one is done as well
15:04:27 <d34dh0r53> That does it for the past meeting action items
15:04:28 <mharley> o/
15:04:37 <gtema> thks
15:04:48 <d34dh0r53> next up we have liaison updates
15:04:50 <d34dh0r53> #topic liaison updates
15:04:53 <zigo> Didn't know that meeting was now... so: o/
15:04:56 <d34dh0r53> nothing from release or vmt
15:05:07 <d34dh0r53> o/ zigo, welcome
15:05:49 <d34dh0r53> any other liaison updates?
15:06:06 <d34dh0r53> cool
15:06:25 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:06:36 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:06:38 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:06:40 <d34dh0r53> External OAuth 2.0 Specification
15:06:42 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554
15:06:44 <d34dh0r53> OAuth 2.0 Implementation
15:06:46 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls
15:06:48 <d34dh0r53> OAuth 2.0 Documentation
15:06:50 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108
15:06:52 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104
15:07:08 <d34dh0r53> hiromu: any updates or needs?
15:09:26 <d34dh0r53> ok, moving on
15:09:37 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:09:46 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:09:48 <d34dh0r53> 2024.1 Release Timeline
15:09:50 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:09:52 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:12:30 <dmendiza[m]> 🙋
15:12:34 <d34dh0r53> o/ dmendiza[m]
15:12:35 <dmendiza[m]> Heya!
15:13:03 <dmendiza[m]> Sorry, only half paying attention.  Currently also trying to listen to a company meeting.
15:13:25 <dmendiza[m]> Yeah, so I've been updating the policies to allow project-admin to do system things.
15:13:26 <d34dh0r53> ack, me too
15:13:41 <dmendiza[m]> I've got a patch up that is (expectedly) failing tempest because of the policy change:
15:13:56 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone/+/902730
15:14:18 <dmendiza[m]> Working on the tempest patch next, and then I'll update this to make the srbac job non-voting
15:14:31 <dmendiza[m]> then a follow up to make it voting again once the tempest patch lands
15:15:31 <d34dh0r53> sweet, thanks for the work on that and good find :)
15:16:50 <d34dh0r53> next up
15:17:00 <d34dh0r53> #topic specification Add schema version and support to "domain" attribute in mapping rules (gtema)
15:17:08 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/748042
15:17:11 <d34dh0r53> this has merged
15:17:19 <d34dh0r53> woot
15:17:23 <gtema> thanks
15:17:50 <d34dh0r53> I saw a follow on patch that I need to review
15:18:25 <gtema> yes, now that spec needs implementation and Rafael revived old change
15:18:58 <d34dh0r53> sweet, do you happen to have a link handy?
15:19:19 <gtema> https://review.opendev.org/c/openstack/keystone/+/739966
15:19:31 <d34dh0r53> thanks gtema !
15:21:00 <d34dh0r53> cool, moving on
15:21:08 <d34dh0r53> #topic open discussion
15:21:19 <d34dh0r53> domain scoping for "GET /v3/domains" (mhen)
15:21:21 <d34dh0r53> bug: #link https://bugs.launchpad.net/keystone/+bug/2041611
15:21:23 <d34dh0r53> patch: #link https://review.opendev.org/c/openstack/keystone/+/900028
15:21:25 <d34dh0r53> looking for reviewers
15:21:27 <d34dh0r53> Zuul tests fail
15:21:29 <d34dh0r53> "keystone_tempest_plugin.tests.rbac" seems to be the culprit
15:21:31 <d34dh0r53> how can patches of the keystone_tempest_plugin be integrated in a way that the patchset above incorporates it in its testing? (i.e. interlinked patchsets between keystone and keystone_tempest_plugin that depend on each other)
15:22:09 <d34dh0r53> I think this may be an old open discussion item but I wanted to raise it just in case
15:22:51 <bbobrov> i am actually not sure that it is a good thing to merge
15:23:08 <d34dh0r53> I'm not either
15:23:17 <bbobrov> it feels like a violation of an API stability contract
15:23:51 <bbobrov> this is an old broadly used endpoint, and i am sure there are deployments that use the current response
15:24:25 <bbobrov> i have a feeling that there was a discussion about this several years ago...
15:26:06 <zigo> Is it time to talk about py3.12 ? :)
15:27:10 <d34dh0r53> yeah, I think we can remove the previous topic from the open discussion list and see if mhen gets back to us on bbobrov's comments on the review
15:27:19 <bbobrov> https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-09-15.00.html - it was discussed here
15:27:53 <bbobrov> zigo: i think we shall get to it during the bug review, i have filed https://bugs.launchpad.net/keystone/+bug/2046355
15:28:02 <zigo> I tried building Keystone in Unstable, and this lead me to 2000+ unit test failures.
15:28:18 <zigo> Most seem due to the way Keystone uses datetime.
15:28:40 <zigo> For example utcfromtimestamp() is removed from Py 3.12.
15:28:46 <zigo> See https://docs.python.org/3/whatsnew/3.12.html
15:28:52 <bbobrov> previous discussion about the scope for listing domains: #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-11-09-15.00.html
15:29:05 <zigo> I unfortunately didn't have enough time to investigate it enough though ...
15:29:33 <zigo> But if there's a bunch of you with enough time to try unit testing with 3.12, that'd be super useful.
15:29:45 <zigo> See how many bugs I need to deal with: https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=team%2Bopenstack%40tracker.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done
15:29:56 <bbobrov> zigo: i think that utcfromtimestamp is not removed, but deprecated
15:29:58 <zigo> We're at 47, we were at 66 yesterday ...
15:30:14 <zigo> bbobrov: Correctly, but that makes the unit tests fail...
15:30:25 <zigo> So it got to be fixed.
15:30:30 <bbobrov> well, we can probably mute it for now somehow
15:30:47 <zigo> Why not fixing completely? It didn't seem that hard to do...
15:30:50 <dmendiza[m]> zigo we can start by adding a py312 gate, but it's not in scope for 2024.1
15:30:51 <dmendiza[m]> #link https://governance.openstack.org/tc/reference/runtimes/2024.1.html
15:31:18 <zigo> atetime.datetime.utcnow() -> datetime.datetime.now(datetime.UTC)
15:31:36 <bbobrov> zigo: well, first of all, they return different string representations
15:31:41 <zigo> (this is an example from keystone/identity/backends/sql.py line 135, but there are more ...)
15:31:52 <bbobrov> zigo: it also needs to be fixed in oslo.utils
15:32:16 <zigo> Whatever you feel like works will work for me! :)
15:32:25 <d34dh0r53> that's what I was looking for, thanks dmendiza[m]
15:32:27 <dmendiza[m]> I would think 2024.2 will have 3.12 as a tested runtime, and we'll likely run into all those issues then.
15:34:04 <zigo> Once these 2000+ failures are silenced, I believe there will be more to fix, but I have no idea what and how much.
15:34:19 <zigo> bbobrov: Are you volunteering to try fixing all py3.12 issues ? :)
15:34:57 <bbobrov> where do i find py3.12 for that...
15:35:10 <zigo> dmendiza[m]: It's always been the case that I've been annoying everyone early with interpreter versions, and fixing them early has always been good ... :)
15:35:19 <zigo> bbobrov: In Debian Unstable for example.
15:35:26 <zigo> Not sure of the Ubuntu status.
15:35:43 <zigo> In Unstable, it's as "available version", ie not the default yet.
15:35:58 <bbobrov> i am afraid to get out of my debian stable
15:36:12 <zigo> Use a chroot then.
15:36:23 <zigo> That works very well for testing.
15:36:30 <bbobrov> zigo: i am volunteering, but i cannot promise you any timelines
15:36:52 <zigo> That's very nice already. I'll see what I can do too.
15:37:02 <zigo> I need to run, bye !
15:37:12 <d34dh0r53> thanks bbobrov and zigo, we'll track this in the bug and reviews
15:37:21 <d34dh0r53> #topic bug review
15:38:42 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:40:57 <d34dh0r53> a few new bugs for keystone
15:41:12 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2044624
15:42:05 <d34dh0r53> there is a fix proposed that looks good, but it's failing the checks
15:42:09 <d34dh0r53> moving on
15:42:46 <bbobrov> (please review the fix, the checks should be repaired now)
15:43:02 <d34dh0r53> ack, will do
15:43:23 <d34dh0r53> next up
15:43:26 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2045974
15:44:14 <d34dh0r53> hmm
15:44:27 <d34dh0r53> I like option 2 but that is indeed boiling an ocean
15:45:35 <bbobrov> what if one gets a domain-manager role on a project?
15:45:57 <d34dh0r53> oops, I was commenting on the wrong link :o
15:46:45 <gtema> idea of domain-manager (domain-admin) is actually to bring roles allowing identity operations on the domain (in domain scope)
15:47:24 <gtema> I was not seeing the proposed spec, but what I wrote is a gist of discussions on the topic I was participating in
15:47:33 <gtema> it is a must for any public cloud
15:47:57 <gtema> otherwise they end up hiding keystone apis from the end user
15:48:26 <bbobrov> why not "manager" on a domain?
15:49:36 <gtema> doesn't matter what the name is. Or do I get your question wrong?
15:50:33 <d34dh0r53> the spec says manager
15:51:16 <gtema> I see in the spec domain-manager role
15:51:20 <bbobrov> i think the bugreport language could be a bit changed then:
15:51:25 <bbobrov> and maybe in the spec
15:51:38 <bbobrov> to: introduce a new "domain-manager" persona in Keystone
15:52:14 <gtema> sounds reasonable
15:52:24 <bbobrov> the specs talk about personas defined via policies, and propose to create them via a combination of a new role (manager) and a scope (project)
15:52:58 <d34dh0r53> ack, we need to move on for time, but I'll add this spec to that section of the agenda
15:53:00 <bbobrov> the bugreport kind of suggests to add "domain" as a potential scope for the role;
15:53:01 <gtema> you are talking about the "alternatives"?
15:54:03 <bbobrov> gtema: lets talk after the meeting
15:54:07 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2045995
15:54:11 <gtema> ok
15:54:24 <d34dh0r53> I prefer option 2 for this one but it's a lot of work
15:54:46 <d34dh0r53> we're definitely missing tracebacks without that patch but I think we turned the volume up too high
15:55:45 <bbobrov> although we miss them, we don't miss too many
15:56:19 <bbobrov> we send them to sentry, and there are almost none
15:56:28 <d34dh0r53> ack
15:57:19 <bbobrov> i also don't understand how to make sure, that, if option 2 is taken, i have suceeded in fixing the issue
15:57:40 <bbobrov> i could refer to tempest
15:57:47 <d34dh0r53> I think it's whack-a-mole honestly
15:57:50 <bbobrov> but how good is tempest in testing the negative scenarios?
15:58:00 <d34dh0r53> I'm not sure
15:58:07 <bbobrov> maybe we could somehow catch it in our unit tests...
15:58:58 <d34dh0r53> maybe, let's discuss in the bug
15:59:01 <bbobrov> anyway, i am experimenting with option 1 right now.
15:59:10 <d34dh0r53> I'm open to option 1
15:59:13 <d34dh0r53> let me know how it goes
15:59:24 <d34dh0r53> finally for keystone
15:59:33 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2046355
15:59:44 <bbobrov> this has been discussed earlier
15:59:45 <d34dh0r53> we discussed this already
16:00:02 <d34dh0r53> I checked the other projects and we don't have any new issues in any of them
16:00:06 <d34dh0r53> #topic conclusion
16:00:23 <d34dh0r53> Thanks for the lively discussion today, and for the heads up on py3.12
16:00:49 <d34dh0r53> we'll get to work on that
16:00:57 <d34dh0r53> anything else before we go?
16:01:21 <d34dh0r53> next week will be the last weekly meeting of the year, have a great rest of your week folks!
16:01:27 <d34dh0r53> #endmeeting