15:00:53 <d34dh0r53> #startmeeting keystone
15:00:53 <opendevmeet> Meeting started Wed Jan 17 15:00:53 2024 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:53 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:53 <opendevmeet> The meeting name has been set to 'keystone'
15:01:05 <d34dh0r53> #topic roll call
15:01:19 <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,jph
15:01:26 <d34dh0r53> o/
15:01:54 <dmendiza[m]> 🙋
15:03:18 <d34dh0r53> #topic liaison updates
15:03:28 <d34dh0r53> nothing from VMT nor Release Management
15:04:42 <d34dh0r53> #topic review past meeting work items
15:04:54 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-01-10-15.01.html
15:05:16 <d34dh0r53> no updates, still a WIP to add these sections to the docs
15:05:25 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation
15:05:34 <d34dh0r53> #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation
15:05:53 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:06:03 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:06:05 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:06:07 <d34dh0r53> External OAuth 2.0 Specification
15:06:09 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554
15:06:11 <d34dh0r53> OAuth 2.0 Implementation
15:06:13 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls
15:06:15 <d34dh0r53> OAuth 2.0 Documentation
15:06:17 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108
15:06:19 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104
15:08:26 <d34dh0r53> looks like hiromu isn't around today
15:08:28 <d34dh0r53> moving on
15:08:46 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:08:56 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:08:58 <d34dh0r53> 2024.1 Release Timeline
15:09:00 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:09:02 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:09:04 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/902730
15:09:06 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/903713
15:09:09 <dmendiza[m]> Still loking for reviews on the Phase 1 patch: ^^^^
15:09:40 <dmendiza[m]> Working on the tempest test changes, but it's a bit messy since I have to reorganize some large classes. 😒
15:10:12 <d34dh0r53> I'll review the phase 1 patch today, on my list of ToDo's
15:10:23 <dmendiza[m]> thanks d34dh0r53
15:12:27 <d34dh0r53> np
15:12:32 <d34dh0r53> next up
15:12:44 <d34dh0r53> #topic specification Add schema version and support to "domain" attribute in mapping rules (gtema)
15:12:52 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/748042 (merged)
15:12:54 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/739966
15:13:31 <gtema> pls reviews
15:13:42 <d34dh0r53> ack, I'll add that to my list
15:13:44 <gtema> we are ready for next steps and need that change to be processed
15:13:50 <d34dh0r53> thanks gtema
15:15:07 <d34dh0r53> #topic open discussion
15:15:19 <d34dh0r53> I don't have anything
15:16:56 <bbobrov> i have
15:17:08 <bbobrov> i would like to talk about project tags and access to them by various actors. Today project tags are there for project admins. They can change them, via a separate API or via a project update API.
15:17:41 <bbobrov> We would like to have project tags, that would be writeable only by "system admins". It will allow our system admins to enable certain features for projects based on existence (or nonexistence) of the tags.
15:18:32 <bbobrov> the tags are also company-specific and probably should not be done by adding new resource options
15:19:06 <bbobrov> would adding tag prefixes or tag namespaces be an option?
15:19:26 <bbobrov> would this change be even in scope of keystone, or should it rather be implemented elsewhere?
15:21:49 <gtema> tags are not only writable by admins - there are clouds where domain admins can manage project tags
15:22:30 <bbobrov> yes, that is true. But i would like to designate certain tags to be writeable only by system admins.
15:22:50 <d34dh0r53> ahh, I see, a permissions flag for certain tags
15:25:16 <d34dh0r53> dmendiza[m]: would this be possible with a custom policy?
15:27:58 <dmendiza[m]> Hmm...  it would be tough to do, I think ...  the policy engine works on an endpoint (URL) and can possibly use metadata about the object to make a decision.
15:28:28 <dmendiza[m]> Not sure what could be done in a tag to differentiate it from other tags
15:28:34 <bbobrov> they only way to do it via policies is to delegate the decision to a remote server (via http: rule)
15:29:59 <d34dh0r53> hmm, ok
15:30:50 <bbobrov> another way to implement this would be via a new endpoint, something like /v3/projects/project_id/system-tags/, but it is a stretch, because it asks for a /domain-tags/ after that :)
15:31:10 <d34dh0r53> right
15:31:49 <d34dh0r53> I think this needs a spec as it's an API change as proposed here
15:32:24 <bbobrov> honestly, i am not even sure that it should be in scope of keystone; maybe i should just go with yet another microservice
15:32:54 <bbobrov> which is also not great, because i have to protect it with all the oslo stuff
15:34:49 <jrosser> could i ask if it would be possible to merge the fix here https://bugs.launchpad.net/keystone/+bug/2030061?
15:38:17 <d34dh0r53> jrosser: I'll take a closer look at the fix for that later today, it does need tests though
15:38:59 <jrosser> ok so on that, andrew works on my team and we put a bunch of time to debug and make the bug / example fix
15:39:13 <jrosser> however we certainly do not have the skills to make a test for it
15:40:03 <d34dh0r53> bbobrov: yeah, it's a grey area
15:42:11 <d34dh0r53> jrosser: ack
15:42:49 <d34dh0r53> moving on for the sake of time
15:43:17 <d34dh0r53> bbobrov: it's up to you, we're certainly willing to look at a spec for adding that ability
15:43:25 <d34dh0r53> #topic bug review
15:43:46 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:44:02 <d34dh0r53> looks like a new bug for keystone
15:44:05 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2049559
15:45:02 <d34dh0r53> any volunteers to look at that one?
15:45:36 <bbobrov> i think it was a deliberate decision to hide the error message from the user
15:46:05 <d34dh0r53> I think so too, but I'd have to check
15:46:37 <bbobrov> and that the reason is transmitted only via notifications
15:47:36 <d34dh0r53> yeah, this is by design, just found the release note stating that
15:47:41 <d34dh0r53> I'll update the bug
15:49:19 <d34dh0r53> next up
15:49:30 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:49:40 <d34dh0r53> no new bugs for python-keystoneclient
15:49:54 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:50:10 <d34dh0r53> keystoneauth has no new issues
15:50:21 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:50:37 <d34dh0r53> keystonemiddleware is also goo
15:50:39 <d34dh0r53> d
15:50:50 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:51:02 <d34dh0r53> nothing new in pycadf
15:51:13 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:51:24 <d34dh0r53> ldappool is good to go
15:51:28 <d34dh0r53> #topic conclusion
15:51:41 <d34dh0r53> Thanks folks!
15:51:48 <d34dh0r53> I don't have anything
15:52:14 <d34dh0r53> #endmeeting