| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 06:15 |
|---|---|---|
| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 06:18 |
| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 08:09 |
| opendevreview | Monty Taylor proposed openstack/project-config master: Add inaugust/wandertracks repo https://review.opendev.org/c/openstack/project-config/+/920616 | 08:59 |
| Guest6802 | New repo from me- should I split those out into their own tenant? I notice a few more top-level tenants since the original ones were added. | 08:59 |
| frickler | Guest6802: mordred? that you? hardly recognizing you after all this time ;) I'm fine with using the opendev tenant, doing a dedicated tenant is a lot of extra work and some of those we have could like get retired again if somebody wanted to clean up | 09:10 |
| Guest6802 | frickler: it is indeed! :) ... awesome, less work is the thing we want here for sure. | 09:10 |
| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 09:17 |
| Guest6802 | frickler: thanks - fixing up those comments. I still have use-storyboard: False on other repos - want me to clean those up either in this commit or a followup? Or just leave them? | 09:22 |
| opendevreview | Monty Taylor proposed openstack/project-config master: Add inaugust/wandertracks repo https://review.opendev.org/c/openstack/project-config/+/920616 | 09:35 |
| opendevreview | Monty Taylor proposed openstack/project-config master: Add inaugust/wandertracks repo https://review.opendev.org/c/openstack/project-config/+/920616 | 09:36 |
| frickler | Guest6802: Guest6802: this only place I currently see "use-storyboard: false" is for airshipctl? I think we can ignore that for now | 09:46 |
| Guest6802 | oh! you're right - it's set to true for the other inaugust repos. silly me. thanks again! | 09:48 |
| oschwart | hey folks, I have uploaded a patch and I don't see it on the zuul status queue. Anyone can tell why? | 11:36 |
| oschwart | the patch: https://review.opendev.org/c/openstack/designate-tempest-plugin/+/920653 | 11:36 |
| oschwart | I don't see it here https://zuul.opendev.org/t/openstack/status#920653 | 11:36 |
| frickler | oschwart: the dependency is not mergeable since it is based on an outdated ps https://review.opendev.org/c/openstack/designate/+/857978 ( see the "not current" on the relation chain) | 11:39 |
| oschwart | frickler: so because the tempest plugin patch depends on a patch that uses another commit with a non-current version, the check pipeline won't even run? | 11:43 |
| fungi | oschwart: correct. zuul is unable to | 12:11 |
| fungi | er | 12:11 |
| fungi | zuul is told by gerrit that the change cannot merge | 12:11 |
| fungi | the outdated patch will need to be rebased onto a valid branch history | 12:12 |
| fungi | right now it has one or more parent commits that will never be in the branch | 12:12 |
| oschwart | ok yes, I have just rebased 857978 on top of its parent's patch and now I do see the tempest patch running on the zuul status queue | 12:14 |
| oschwart | thanks frickler fungi | 12:14 |
| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 13:11 |
| opendevreview | Lukas Kranz proposed openstack/diskimage-builder master: Fix setting apt mirror for noble https://review.opendev.org/c/openstack/diskimage-builder/+/920466 | 13:17 |
| dansmith | clarkb: this is the thing I found when I was running into the problem as stated: https://github.com/ansible/ansible/issues/81946 | 13:33 |
| dansmith | clarkb: specifically "ansible-core 2.16 will be the earliest version to support Python 3.12" | 13:33 |
| dansmith | that said, if it's just six deps that were the problem, then perhaps some distro package has patched that out... | 13:34 |
| fungi | or if those deps aren't in the codepaths we commonly traverse | 13:50 |
| tonyb | dansmith: clarkb: It looks like Noble ships ansible-core 2.16 so it should be fine right? | 14:11 |
| dansmith | tonyb: my case was trying to run ansible from jammy to configure a noble node, which wasn't working.. if you're running ansible *on* noble then I'm sure you're fine | 14:12 |
| tonyb | dansmith: Ah okay. | 14:13 |
| fungi | frickler: were you putting together a py312 testing fix for pbr yet? if not, i've got it passing locally and am happy to push it up for review | 14:47 |
| fungi | just need to split it up into a couple of changes since there's more than one thing to fix | 14:49 |
| fungi | the good news is pbr itself doesn't seem to need any fixing, just some slight adjustments to the test environment | 14:50 |
| clarkb | dansmith: interesting. We're running zuul + ansible from bookworm with python3.11 and that seems to work fine against our noble nodes. I think with ansible core 2.15 | 14:50 |
| frickler | fungi: I didn't look at the actual failure yet, so please go ahead with that | 14:50 |
| fungi | cool, i'll have it up in a few minutes | 14:51 |
| dansmith | clarkb: idk, I just know it wasn't working from my jammy on 3.10... | 14:51 |
| clarkb | https://zuul.opendev.org/t/zuul/build/56eb0954d8ab4a1cb4a94c958a3960dd/log/job-output.txt#35 | 14:51 |
| dansmith | do you have six installed from package maybe? perhaps that'd be enough to make it work | 14:52 |
| clarkb | dansmith: maybe? I thought we had confined most of that to virtualenvs at this point but it is possible something is not isolated yet | 14:52 |
| clarkb | https://104.130.74.99:3081/opendev/system-config is the held gitea running 1.22.0. Later today after all my meetings I'll have to see if I can figure out how to run the doctor command on that node | 16:16 |
| clarkb | in the mean time we can all poke at the web ui and ensure it looks happy | 16:16 |
| clarkb | actually doing the upgrade and running the doctor command is probably a post gerrit upgrade activity though so not a rush | 16:17 |
| clarkb | the new gitea theme applies an off white background to the file view when using the light theme | 16:41 |
| fungi | odd | 16:41 |
| tonyb | It looks fine in dark mode (although) it looks like different fonts get selected | 16:41 |
| clarkb | there seemed to be a bit of a css refactoring based on some of the deltas in the template files | 16:43 |
| clarkb | this does seem to be generally functional though | 16:44 |
| tonyb | Oh 'code search' came back | 17:16 |
| tonyb | https://usercontent.irccloud-cdn.com/file/UYXjVbUv/Screenshot%20from%202024-05-28%2012-19-52.png https://usercontent.irccloud-cdn.com/file/SqLkTbAx/Screenshot%20from%202024-05-28%2012-19-59.png | 17:21 |
| tonyb | For the mediawiki update/restructure there are several extensions and a theme that we need to grab from git. | 17:23 |
| tonyb | in the case of gerrit we have googlesource as a source and the container build requires those repos. | 17:24 |
| tonyb | I don't know if we want to do that for mediawiki or clone them directly at (container) build time. | 17:25 |
| clarkb | tonyb: the main reason to add them to zuul directly would be if you expect to use depends on | 17:26 |
| tonyb | If we're doing the latter is it better to clone them into first and then COPY them into place or do the clone directly in the Dockerfile? | 17:26 |
| tonyb | clarkb: At this point I can't really see us needing to do that. | 17:26 |
| tonyb | once we get closer to mainline I'd expect us to stay on "latest stable" | 17:27 |
| clarkb | tonyb: I think its fine to clone in the dockerfile just use a multi stage build if possible to throw out the extra content when done | 17:30 |
| tonyb | Okay I'll see what I can do. | 17:31 |
| clarkb | altering tables for collations is probably safe to do online with the gitea service running but altering data from utf8 to utf8mb4 is probably not? I guess I need to figure out running this gitea doctor command while gitea is offline | 21:11 |
| clarkb | I'm going to turn off services on the held gitea node now while I figure that out | 21:12 |
| fungi | i don't immediately see why it would be a problem. all the migration does is expand the column's representation by an empty byte | 21:12 |
| clarkb | fungi: I think that may cause it to need to create new tables though | 21:14 |
| clarkb | not sure how seemless the handover is | 21:14 |
| clarkb | fwiw the convert seemed to run with gitea offline just fine. I had to figure out the right docker-compose incantation. I also took db backups before and after so I should be able to compare better now There is a deprecated config setting that we should address as part of this upgrade. | 21:18 |
| clarkb | things are back on the held node and seem to work as well | 21:18 |
| fungi | but yeah since it's already highly redundant, we could probably orchestrate rotating through offline updates | 21:19 |
| clarkb | heh ok that confirms one of my fears. We're actually starting from a good point already on the held test node | 21:20 |
| clarkb | so the doctor is basically a noop | 21:20 |
| fungi | oh, alls the better | 21:20 |
| clarkb | well except that it invalidates the testing :) | 21:20 |
| clarkb | I can probably manually upgrade a held 1.21.11 node and then see if that works. | 21:20 |
| clarkb | Or fall back to taking a db dump on one of our nodes and testing against that | 21:21 |
| tonyb | I feel like deploying 1.21.11 and holding it would be the 'least hassle' | 21:22 |
| clarkb | ya I'm going to rebase my hold a gitea node change back to master so that it can build against 1.21.11 and then manually upgrade and run the doctor stuff and see if that shows any more improvements | 21:24 |
| clarkb | side note I just rechecked https://review.opendev.org/c/openstack/project-config/+/919630 to finish up the d-g cleanup | 21:25 |
| tonyb | clarkb: Thanks. | 21:25 |
| corvus | clarkb: yeah that's going to be a new table behind the scenes; would hold a table lock for that time, so certainly no writes there. i'm not sure if it would block reads. | 21:25 |
| clarkb | corvus: ack I think in that case since we have the ability to do these in a rolling fashion with gitea offline we should just do that. Its a bit more effort but should make it more transparent if anything goes sideways as we won't be actively servicing any requests | 21:26 |
| clarkb | its also a one time thing | 21:27 |
| clarkb | `docker-compose run -T --rm gitea-web gitea doctor convert` is the command fwiw | 21:27 |
| clarkb | and it should report things like Converted successfully, please confirm your database's character set is now utf8mb4 | 21:27 |
| opendevreview | Clark Boylan proposed opendev/system-config master: DNM intentional gitea failure to hold a node https://review.opendev.org/c/opendev/system-config/+/848181 | 21:28 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update Gitea to version 1.22 https://review.opendev.org/c/opendev/system-config/+/920580 | 21:32 |
| clarkb | that new ps updates our config to drop the deprecated config option | 21:33 |
| opendevreview | Merged openstack/project-config master: Retire devstack-gate https://review.opendev.org/c/openstack/project-config/+/919630 | 21:52 |
| clarkb | ok the 1.21.11 uses a case insensitive collation but its str type is already utf8mb4 | 23:33 |
| clarkb | this means I should be able to use that node to test the collation update but not the data conversion. However, the data conversion should also be straightforward and can backup the db on a node before doing it so risks are low without having this all perfectly tested | 23:34 |
| clarkb | https://104.130.74.189:3081/opendev/system-config is the manually upgraded test node now running 1.22.0 with a converted db | 23:41 |
| clarkb | diffing the dumps there shows everything using COLLATE=utf8mb4_uca1400_as_cs after the doctor tool is run | 23:43 |
| clarkb | previous value was COLLATE=utf8mb4_general_ci (which again doesn't quite match prod because of how old the prod db is, but I think this shows the tool generally works and should do what it says on the tin ) | 23:43 |
| tonyb | clarkb: \o/ | 23:44 |
| clarkb | I think our general plan should be to upgrade gitea to 1.22.x in the naer future. Historically they've always had a .1 or even .3 release not long after the .0 release | 23:44 |
| clarkb | Then once we've upgraded we can do the db conversion instance by instance and address any problems if they arise. The upside to waiting for gerrit's upgrade is that gives them time to produce the .1 release :) | 23:45 |
| tonyb | Sounds like a plan to me. | 23:46 |
| clarkb | `docker-compose run -T --rm gitea-web gitea doctor convert` is the command I ran and it is given a unique enough container name that it won't interfere with the normal service container (I was worried about this using docker-compose run but all is well) | 23:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
