Tuesday, 2025-12-09

*** mhen_ is now known as mhen02:13
opendevreviewMerged openstack/keystone master: Import LOG where it is used  https://review.opendev.org/c/openstack/keystone/+/96995504:19
*** darmach3 is now known as darmach04:26
opendevreviewMerged openstack/keystone master: Fix role assignment cache for federated users  https://review.opendev.org/c/openstack/keystone/+/96704811:54
opendevreviewMerged openstack/keystone master: Remove unused bandit target  https://review.opendev.org/c/openstack/keystone/+/96283911:58
opendevreviewMerged openstack/keystone master: Use native hook of bashate  https://review.opendev.org/c/openstack/keystone/+/96284211:58
opendevreviewIvan Anfimov proposed openstack/keystone master: Drop flake8-docstrings  https://review.opendev.org/c/openstack/keystone/+/96284312:12
opendevreviewIvan Anfimov proposed openstack/keystone master: Drop flake8-docstrings  https://review.opendev.org/c/openstack/keystone/+/96284312:12
opendevreviewIvan Anfimov proposed openstack/keystone master: Drop flake8-docstrings  https://review.opendev.org/c/openstack/keystone/+/96284312:12
opendevreviewIvan Anfimov proposed openstack/keystone master: Cap hacking  https://review.opendev.org/c/openstack/keystone/+/90696512:14
opendevreviewIvan Anfimov proposed openstack/keystone master: Cap hacking  https://review.opendev.org/c/openstack/keystone/+/90696512:15
opendevreviewIvan Anfimov proposed openstack/keystone master: Cap hacking  https://review.opendev.org/c/openstack/keystone/+/90696512:15
opendevreviewIvan Anfimov proposed openstack/keystone master: Cap hacking  https://review.opendev.org/c/openstack/keystone/+/90696512:16
opendevreviewStephen Finucane proposed openstack/oslo.limit master: typing: Accept None project ID  https://review.opendev.org/c/openstack/oslo.limit/+/97024713:01
opendevreviewStephen Finucane proposed openstack/oslo.limit master: typing: Be looser in what we accept  https://review.opendev.org/c/openstack/oslo.limit/+/97024813:01
opendevreviewTakashi Kajinami proposed openstack/pycadf master: ruff: Enable missing E5 check  https://review.opendev.org/c/openstack/pycadf/+/97025513:18
cardoegtema: 15:12
cardoeshould we backport https://review.opendev.org/c/openstack/keystone/+/967048 ?15:12
cardoesorry for splitting the message up premature enter key15:13
gtemaI think it would make sense15:13
lajoskatonaHi, I got a question from on of our downstream teams, which they sent out to openstack-discuss also: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3T5VDI23TZDBFNZLBVDOUGUQCRLCOL2N/15:26
lajoskatonaThey tried using user_additional_attribute_mapping like this one: user_additional_attribute_mapping = passwordExpirationTime:password_expires_at15:27
gtemalajoskatona - ack. I have seen that question but hoping somebody with ldap experience to jump in. I am very curious since ldap is considered a read-only backend with no possibility to change password through keystone, so I am confused with the question15:28
lajoskatonabut on keystone API the user's password_expires_at filed is still empty, do yo have perhaps any tips what should be a next step to integrate their ldap server (389ds) with keystone?15:28
lajoskatonagtema: to tell the truth I am totally dumb for this topic so I had to read keystone and ldap docs half a day to understand the basics of the question :-)15:29
gtemaI feel you15:30
lajoskatonaperhaps I answer to the mail with the findings with the cfg option user_additional_attribute_mapping, and hope that it will hit a memory for somebody15:31
gtemaI really do not understand the question properly, since as I wrote - you are not expected to do anything with the password rotation through Keystone15:32
lajoskatonamy understanding is that they expect  keystone to know about the ldap server password expiration time15:35
gtema"Is it not possible for keystone to respond token with minimum scope to only change password?" - this part of the message is what confuses me15:36
opendevreviewDoug Goldstein proposed openstack/keystone stable/2025.2: Fix role assignment cache for federated users  https://review.opendev.org/c/openstack/keystone/+/97028417:04
cardoegtema: ^ so that's my backport17:04
cardoeDid you happen to see my federation mapping docs update as well?17:05
gtemaoh, that looks huge. And I am not sure in at least one thing and need to verify first17:05
cardoegtema: well its suppose to capture all the issues I've run into18:19
gtemaAnd you are sure with local account pre-existence requirement? I was sure  it is not the case. Would need to dig the code18:20
cardoegtema: yes... https://opendev.org/openstack/keystone/src/commit/a71b056a5b3f776c23abf0e840f942cc4945bc3b/keystone/auth/plugins/mapped.py#L23922:00
cardoeSo that causes the user context to be created not from the ephemeral data but from the user_name or user_id in the domain_name or domain_id. It will call a get_user() from the appropriate domain and if that user doesn't exist then it won't create the context.22:01
cardoeThe result is that users won't be able to login when they are type=local cause they won't already be in the database.22:02
opendevreviewDoug Goldstein proposed openstack/keystoneauth master: Add v3websso OpenID Connect Web SSO authentication plugin  https://review.opendev.org/c/openstack/keystoneauth/+/97032823:15
cardoemnaser: ^ that's the websso plugin integrated. I've used it so far today and it works fine. Claude wrote up some docs for me and the tests.23:17
cardoeI had to rewrite it from multipart to WebOb since multipart is not in global requirements.23:17
mnaserThats neat. The only concern I would have is the pace of maintainability...23:19
mnaser[@_oftc_cardoe:matrix.org](https://matrix.to/#/@_oftc_cardoe:matrix.org) why not add this as a dependency of keystoneauth instead of add it natively ?  It can allow us to keep moving this thing at a good pace. 23:20
mnaserKeystone stuff takes forever to merge.23:20

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!