| opendevreview | Takashi Kajinami proposed openstack/python-keystoneclient master: Replace deprecated datetime.datetime.utcnow https://review.opendev.org/c/openstack/python-keystoneclient/+/948982 | 05:55 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/python-keystoneclient master: Replace deprecated datetime.datetime.utcnow https://review.opendev.org/c/openstack/python-keystoneclient/+/948982 | 05:57 |
| opendevreview | Takashi Kajinami proposed openstack/python-keystoneclient master: Replace deprecated datetime.datetime.utcnow https://review.opendev.org/c/openstack/python-keystoneclient/+/948982 | 07:54 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Start building openapi doc https://review.opendev.org/c/openstack/keystone/+/948185 | 09:39 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: pre-commit: Bump versions https://review.opendev.org/c/openstack/keystoneauth/+/945980 | 11:28 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: Drop support for Python 3.9 https://review.opendev.org/c/openstack/keystoneauth/+/949008 | 11:28 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: Bump Python version used for linters to 3.9 https://review.opendev.org/c/openstack/keystoneauth/+/949009 | 11:28 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: Bump minimum Python version used for linters https://review.opendev.org/c/openstack/keystoneauth/+/949010 | 11:28 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Start building openapi doc https://review.opendev.org/c/openstack/keystone/+/948185 | 11:30 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: Bump Python version used for linters to 3.10 https://review.opendev.org/c/openstack/keystoneauth/+/949010 | 11:33 |
| d34dh0r53 | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Wed May 7 15:02:07 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:02 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:02 |
| d34dh0r53 | #topic roll call | 15:02 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:03 |
| gtema | o/ | 15:03 |
| dmendiza[m] | 🙋♂️ | 15:03 |
| d34dh0r53 | o/ | 15:03 |
| d34dh0r53 | #topic review past meeting work items | 15:04 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-04-23-15.02.html | 15:04 |
| d34dh0r53 | no action items from the last meeting | 15:04 |
| d34dh0r53 | #topic liaison updates | 15:04 |
| d34dh0r53 | nothing from releases | 15:05 |
| d34dh0r53 | anything from VMT? | 15:05 |
| gtema | not that I would know about | 15:05 |
| d34dh0r53 | ack, thanks | 15:06 |
| d34dh0r53 | moving on then | 15:07 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:07 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) | 15:07 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged) | 15:07 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) | 15:07 |
| d34dh0r53 | no updates | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystonemiddleware/+/899911 is waiting on dependencies in Barbican and Tacker to merge and then it's good to go. | 15:09 |
| d34dh0r53 | The others just need rebases once that is merged. | 15:09 |
| d34dh0r53 | next up | 15:09 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:09 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:09 |
| d34dh0r53 | 2024.1 Release Timeline | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:10 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:10 |
| d34dh0r53 | any updates dmendiza ? | 15:10 |
| dmendiza[m] | Negative, just getting back from PTO | 15:11 |
| d34dh0r53 | Ack, thanks, and welcome back :) | 15:11 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:11 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:11 |
| gtema | since now the os-api-ref and openstackdocstheme requirements are raised I have updated openapi build change | 15:12 |
| gtema | #link https://review.opendev.org/c/openstack/keystone/+/948185 | 15:12 |
| gtema | from my pov it can go this way, so feel free to review | 15:12 |
| gtema | and then we can start discussing what and where is missing. It will also help landing jsonschema changes since we can see the schemas easier | 15:13 |
| d34dh0r53 | cool | 15:14 |
| gtema | nothing else on that from me this week | 15:14 |
| d34dh0r53 | Looks good to me | 15:15 |
| d34dh0r53 | Thanks gtema | 15:15 |
| d34dh0r53 | That does it for specs | 15:15 |
| d34dh0r53 | #topic open discussion | 15:15 |
| d34dh0r53 | I don't really have anything | 15:15 |
| gtema | anyone has ideas or proposals wrt modifying DB schema for the new federation support? | 15:16 |
| gtema | it is explicitly about the federated_user table linking to the idp_id and protocol_id while in the new implementation those both go away and instead there are few other attrs | 15:16 |
| gtema | currently there is not_null for both of them and therefore I can't use the table without easing those constraints | 15:17 |
| gtema | I do not want to introduce new table (federated2_user) - it is going to be insane | 15:18 |
| gtema | my idea was to drop the not_null constraint so that I can leave those fields empty while adding new fields and new FK constraints | 15:18 |
| d34dh0r53 | I'm okay with dropping the constraint | 15:20 |
| gtema | I think the code is good enough to handle those properly | 15:20 |
| d34dh0r53 | Yeah, and if needed we can add some additional checks in the code | 15:21 |
| gtema | ok, I will then proceed this way | 15:21 |
| d34dh0r53 | sounds good | 15:21 |
| gtema | thks | 15:22 |
| d34dh0r53 | cool, any other open discussion topics? | 15:24 |
| gtema | not from me | 15:24 |
| d34dh0r53 | moving on | 15:25 |
| d34dh0r53 | #topic bug review | 15:25 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:25 |
| d34dh0r53 | Looks like three new bugs in keystone | 15:25 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2110084 | 15:25 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2109989 | 15:26 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2109693 | 15:26 |
| gtema | uhm | 15:28 |
| gtema | project creation is another misuse of admin at domain scope | 15:28 |
| d34dh0r53 | yeah, the first two look like they may be just configuration issues | 15:32 |
| d34dh0r53 | moving on | 15:32 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:33 |
| d34dh0r53 | no new bugs for python-keystoneclient | 15:33 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:33 |
| d34dh0r53 | keystoneauth is good as well | 15:33 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:33 |
| d34dh0r53 | no new bugs in keystonemiddleware | 15:33 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:33 |
| d34dh0r53 | pycadf is good | 15:34 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:34 |
| d34dh0r53 | so is ldappool | 15:34 |
| d34dh0r53 | #topic conclusion | 15:34 |
| d34dh0r53 | Thanks folks! | 15:34 |
| gtema | thanks Dave Wilde (d34dh0r53) | 15:34 |
| d34dh0r53 | 👍️ | 15:35 |
| d34dh0r53 | #endmeeting | 15:35 |
| opendevmeet | Meeting ended Wed May 7 15:35:11 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:35 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-05-07-15.02.html | 15:35 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-05-07-15.02.txt | 15:35 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-05-07-15.02.log.html | 15:35 |
| WiniciusAllan[m] | hi keystone team o/ | 15:35 |
| WiniciusAllan[m] | Are you who maintains the identity part of terraform provider? | 15:36 |
| gtema | nope, terraform is not maintained by anybody from the OpenStack itself | 15:37 |
| WiniciusAllan[m] | oh, I see | 15:37 |
| WiniciusAllan[m] | may I share my pain? =) | 15:38 |
| gtema | sure, but not sure whether we would be able to help. wrt TF provider you should directly open issue in github repo of it | 15:39 |
| WiniciusAllan[m] | no problem, maybe you can help with a workaround | 15:39 |
| WiniciusAllan[m] | I've configured LDAP driver for my environment and set the user_enabled_attribute to a boolean value in the LDAP schema | 15:41 |
| WiniciusAllan[m] | when I list all users from the configured domain, the "enabled" column shows "None" at one time and "True" at the other | 15:41 |
| WiniciusAllan[m] | this inconsistency is causing an error when requesting an user from API, because its receiving "enabled=true" as a filter | 15:42 |
| WiniciusAllan[m] | in practice, this does not affect the users, because the LDAP filter get the correct boolean status | 15:44 |
| WiniciusAllan[m] | this inconsistency it is a misconfiguration or an already reported bug? | 15:44 |
| WiniciusAllan[m] | s/it/could/, s/is/be/ | 15:45 |
| gtema | what is the relation to TF? | 15:45 |
| WiniciusAllan[m] | terraform uses gophercloud and it passes Enabled=true as default | 15:46 |
| WiniciusAllan[m] | I changed the code and set this value to nil (so do not append it in request params) and it works as expected | 15:46 |
| gtema | I am confused that you use TF but say "when I list all users" | 15:47 |
| WiniciusAllan[m] | oh, sorry. When I list all users using the CLI | 15:48 |
| WiniciusAllan[m] | I did that to check their status and I ended up seeing that inconsistencyt | 15:49 |
| gtema | "" the "enabled" column shows "None" at one time and "True" at the other "" - what does that mean? For different users or different invocations? | 15:51 |
| WiniciusAllan[m] | for different invocations, the same users show different values across executions | 15:52 |
| gtema | and you see that the request to the API is the same, right? | 15:52 |
| WiniciusAllan[m] | yeah. I can send the output for clarification | 15:54 |
| gtema | in such case I think there may be ldap synchronization issue. Otherwise I can't explain flaky results | 15:55 |
| gtema | maybe you can debug the ldap queries from keystone to eventually spot the issue | 15:56 |
| WiniciusAllan[m] | $ openstack user list --domain LSD -c Name -c Enabled --long | grep winicius... (full message at <https://matrix.org/oftc/media/v1/media/download/AUsz3MiiEr-8yXV1E49kxG_meKsaPaapfeZ2AZFcHjjyuT1-88JEoSMmakkiVKSplnzl2cPsjbV4Vp734KhsgtZCeW84-a7wAG1hdHJpeC5vcmcvcFZkeEdoUlNZekVDUmFnWGFHekhaV2lU>) | 15:56 |
| WiniciusAllan[m] | gtema: I'll do that and see if I get something suspicious | 15:57 |
| WiniciusAllan[m] | thanks for the attention! | 15:58 |
| gtema | you can also use --debug param to the cli to also see the raw data to exclude possibility of bug in the cli | 15:58 |
| gtema | and maybe you can focus on the single user (user show) not to deal with huge data sets | 15:59 |
| WiniciusAllan[m] | what I may search with --debug? the raw response? | 16:00 |
| gtema | the raw json that comes from the keystone api | 16:00 |
| WiniciusAllan[m] | another thing that I notice is that keystone logs show that the domain does not exists | 16:00 |
| WiniciusAllan[m] | "domain LSD not exists" | 16:00 |
| WiniciusAllan[m] | even if the CLI return the users from that domain | 16:00 |
| gtema | and check whether the "enabled" parameter is there is flaky as well | 16:01 |
| WiniciusAllan[m] | ack | 16:01 |
| *** __ministry is now known as Guest15360 | 16:06 | |
| WiniciusAllan[m] | gtema: I was comparing the logs in the two cases that I mentioned. When the output from CLI returns Enable=True the logs show these entries | 17:25 |
| WiniciusAllan[m] | https://pastebin.com/baLekdQJ | 17:25 |
| WiniciusAllan[m] | the difference is in attrs for search_s | 17:26 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!