| *** mhen_ is now known as mhen | 01:24 | |
| opendevreview | Takashi Kajinami proposed openstack/keystone-tempest-plugin master: Remove stable/2023.2 job https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/951235 | 05:55 |
|---|---|---|
| andrewbogott_ | If anyone is feeling helpful, I could use a hand with a keystone regression that's breaking my production cloud: https://bugs.launchpad.net/keystone/+bug/2112112 | 12:10 |
| andrewbogott_ | I'm digging through the code, lots of validation refactors in there which will take me a while to grasp | 12:10 |
| andrewbogott_ | oh, looks like that was already fixed but didn't make it into the debian package... | 12:12 |
| andrewbogott_ | Hey zigo, how would you feel about rebuilding the ospo keystone debs from the latest 2025.1 branch? Looks like that might get us out of this mess. | 12:20 |
| stephenfin | gtema: Got another one for you https://review.opendev.org/c/openstack/keystoneauth/+/951183 | 12:33 |
| stephenfin | andrewbogott_: Just to help zigo, what commit have you identified as the fix? I wasn't able to reproduce it fwiw. | 12:41 |
| andrewbogott_ | I'm only 45 minutes into this issue so haven't tested yet, but I think this is the attempted fix: https://review.opendev.org/c/openstack/keystone/+/945504 | 12:41 |
| andrewbogott_ | Which I think is on the 2025.1 branch already... | 12:42 |
| stephenfin | That's my change. I didn't think that would affect that. | 12:42 |
| andrewbogott_ | oh, hm | 12:43 |
| andrewbogott_ | well then I don't know much yet. | 12:43 |
| andrewbogott_ | So https://bugs.launchpad.net/keystone/+bug/2104185 is not a duplicate of my bug? | 12:44 |
| stephenfin | I don't think so. If you're using openstackclient you shouldn't be using comparators. I think only Gophercloud was affected by that (since there are tests there for that feature) | 12:45 |
| stephenfin | Can you share the (scrubbed) output from OSC and ideally keystone in the bug? | 12:46 |
| andrewbogott_ | here's a stack trace (that i have not actually looked at) | 12:47 |
| andrewbogott_ | https://www.irccloud.com/pastebin/ADr3YwNj/ | 12:47 |
| andrewbogott_ | that's server-side obviously | 12:48 |
| stephenfin | https://github.com/openstack/keystone/blob/069fa4566b9c4835554d993780f1010362f4420b/keystone/assignment/schema.py#L316 | 12:50 |
| andrewbogott_ | does id_string mean a uuid? | 12:51 |
| stephenfin | not quite. any alphanumeric character plus hyphens | 12:52 |
| stephenfin | https://github.com/openstack/keystone/blob/069fa4566b9c4835554d993780f1010362f4420b/keystone/api/validation/parameter_types.py#L115 | 12:52 |
| andrewbogott_ | ok | 12:52 |
| stephenfin | (keystone doesn't insist on uuids, even though the IDs it uses look like uuids) | 12:52 |
| stephenfin | danny_b is a name though, so why is it hitting ID validation...? | 12:53 |
| andrewbogott_ | It's probably his ID too | 12:53 |
| andrewbogott_ | this is all coming from ldap, they aren't keystone-generated IDs. | 12:53 |
| andrewbogott_ | Was that type changed recently? | 12:53 |
| * andrewbogott_ goes back to git | 12:54 | |
| stephenfin | ah, see that's relevant :) | 12:54 |
| stephenfin | yes, this is all new code in Epoxy https://review.opendev.org/c/openstack/keystone/+/940344 | 12:55 |
| andrewbogott_ | Our cloud is old -- even in places where we don't use ldap we have lots of pre-uuid IDs in our database. It's kind of a running gag, compulsive openstack devs keep adding new uuid validation and I have to push back. | 12:55 |
| stephenfin | part of the effort to add OpenAPI schemas to various services | 12:55 |
| stephenfin | so what other IDs are coming from LDAP? | 12:55 |
| * stephenfin is not familiar with keystone with LDAP, or really LDAP (beyond basic usage as an end-user) | 12:56 | |
| andrewbogott_ | OK. Well, I will say what I always say in these cases: Not every cloud is a 0-day cloud so y'all can't just add new constraints to existing properties :) | 12:56 |
| andrewbogott_ | The ldap backend is just for users, not projects or assignments. So it's basically just username and ID (and auth) | 12:57 |
| andrewbogott_ | but ldap isn't really the issue here, the issue is that it's an already-existing cloud with already-existing data | 12:57 |
| stephenfin | ldap isn't an "issue", but it is relevant since it has different criteria for things like usernames which haven't been considered here | 13:03 |
| andrewbogott_ | true! | 13:03 |
| stephenfin | From my brief bit of research, it seems like there are no realistic limits on allowed characters or the length of an LDAP uid, right? | 13:04 |
| andrewbogott_ | Agreed! But I'm trying to make a more general point (which maybe doesn't matter in this case but might), which is that unless you read the keystone code all the way to day one and check every possible value for /any/ property, we can't impose new constraints on that property. Does that make sense? Because you don't know what might be an existing cloud's database already. | 13:05 |
| andrewbogott_ | So I think basically any new validation that's added has to be switchable with a config setting. | 13:05 |
| andrewbogott_ | So... hackwise, if I mark out the @validation.request_query_schema bits will it stop validating? | 13:05 |
| andrewbogott_ | I think you're correct that you can't make any real assumptions about the ldap uid. I don't think all of ours are ascii, for example. | 13:06 |
| stephenfin | I mean we can: that's what API version and database migrations are for. But neither of those have happened here, so that's a bug | 13:06 |
| andrewbogott_ | Oh! Yes, if there's a db migration that handles such edge cases then that's fine. But unfortunately keystone can't really do a db migration on an external provider :( | 13:07 |
| andrewbogott_ | btw stephenfin I hope I'm not coming across as grumpy with you -- you are being extremely, unnecessarily helpful and I appreciate it! If I'm curt it's mostly because I'm feeling dumb for deploying this in production + also I'm having a plumbing issue in my house at the same time. | 13:11 |
| andrewbogott_ | Earlier you asked about client logs -- is that still something that would be useful or do you have all you need from me? | 13:12 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: api: Remove constraints on user IDs https://review.opendev.org/c/openstack/keystone/+/951282 | 13:15 |
| stephenfin | it's all good :) | 13:15 |
| stephenfin | and no, the server log was what was really needed. That should put things right ^ | 13:15 |
| andrewbogott_ | oh nice, thank you! I will rig up puppet to apply that patch and see what we get. | 13:16 |
| stephenfin | please take a look and let me/someone know if there are additional resources where LDAP IDs could propagate up. From what you're saying though, it should be just users | 13:17 |
| andrewbogott_ | There are other things about users that might show up (email adddress for example?) but it really is just users. | 13:17 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: api: Remove constraints on user IDs https://review.opendev.org/c/openstack/keystone/+/951282 | 13:20 |
| stephenfin | ack | 13:21 |
| stephenfin | small tweak there too (I missed the query string). Possibly another one coming once unit tests finish running too | 13:21 |
| andrewbogott_ | ok | 13:22 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: api: Remove constraints on user IDs https://review.opendev.org/c/openstack/keystone/+/951282 | 13:23 |
| zigo | andrewbogott_: You mean osbpo ? | 14:08 |
| andrewbogott_ | zigo: yes! But it turns out that the fix isn't actually merged yet, so I need to apply manually. | 14:08 |
| andrewbogott_ | So, we don't actually need any packaging right now. Thank you for appearing though! | 14:09 |
| zigo | andrewbogott_: So, I'd need this patch, right ? https://review.opendev.org/c/openstack/keystone/+/951282 | 14:09 |
| andrewbogott_ | yep. But packaging that before it's reviewed/merged/passed CI seems premature :) | 14:10 |
| zigo | andrewbogott_: I can always add the patch to the package, even if it's not merged... | 14:10 |
| zigo | Pass the CI, of course, I'll wait for that! :) | 14:10 |
| andrewbogott_ | I'm ok with applying that locally for now, and then it'll likely show up in F | 14:10 |
| andrewbogott_ | But if you really want to backport and package it I'll take it! | 14:10 |
| zigo | Ok, thanks for the ping. | 14:11 |
| zigo | FYI, the sooner the better, because Debian 13 is in hard freeze. | 14:11 |
| andrewbogott_ | zigo: if it gets backported into 13 then that'd be a good case for repackaging and updating the packages in 13. Assuming 13 is shipping with E. | 14:14 |
| stephenfin | gtema: d34dh0r53: I'm seeing some weird behavior. I'm using v3token auth method. On one DevStack environment, I am able to auth with just with token and get a response back with the service catalog and other scope fields included. On the other, I need to also provide a project name and project domain ID | 14:26 |
| stephenfin | Same client and same keystone version on both hosts, practically the same devstack local.conf, same clouds.yaml cloud entry for the user I use to create the token etc. Any idea what might be happening? | 14:27 |
| stephenfin | I have captured tracebacks with mitmproxy too. Nothing different in the requests. It's just the responses that are different | 14:28 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: api: Use explicit ID types https://review.opendev.org/c/openstack/keystone/+/951297 | 14:29 |
| opendevreview | Stephen Finucane proposed openstack/keystoneauth master: Add .git-blame-ignore-revs file https://review.opendev.org/c/openstack/keystoneauth/+/951310 | 14:43 |
| gtema | Stephenfin, I have a public holiday today, thus not responsive. Will have a look tomorrow | 15:35 |
| stephenfin | ack | 15:47 |
| stephenfin | I got to the bottom of it: I had a default project ID set for the user on the first cloud but not the other one. | 17:09 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: api: Add log when creating unscoped token https://review.opendev.org/c/openstack/keystone/+/951327 | 17:15 |
| opendevreview | Stephen Finucane proposed openstack/keystone master: RFC: Do not consider other method types if using token auth https://review.opendev.org/c/openstack/keystone/+/951331 | 18:02 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!