| 19 Apr 2024 |
 corvus | and... the database migration is failing due to a bad foreign key | 20:56:20 |
 Clark | another db combo we didn't anticipate may cause issues? | 20:57:35 |
| corvus | maybe, or maybe just randomly corrupt data in this particular dataset | 20:57:58 |
| corvus | i've stopped zuul, i'll work on getting a db shell now | 20:58:24 |
| corvus | kubectl -n mariadb exec -it mariadb-mariadb-0 -- mysql -u zuul -n zuul -p works for that | 21:03:40 |
| corvus | Server version: 10.3.20-MariaDB-1:10.3.20+maria~stretch-log mariadb.org binary distribution
for the record | 21:03:52 |
|  Paladox none joined the room. | 21:04:02 |
| Paladox none | Oh, we should probably upgrade the OS to bullseye from stretch. (Although another time if it's time consuming) | 21:05:00 |
| Paladox none | also hi | 21:05:12 |
| corvus | hi! i think that's the google-semi-managed mariadb thing; so i think that's getting updated according to googles schedules | 21:05:34 |
| Paladox none | ah | 21:05:45 |
| corvus | i'm... not sure that's the way i would set it up today from scratch, but it's what i did so many years ago... so... :) | 21:05:59 |
| corvus | probably taking it under our full control is a better plan, but i don't think it's urgent | 21:06:22 |
| Paladox none | yeh that's not urgent. | 21:06:39 |
| corvus | ERROR 1823 (HY000): Failed to add the foreign key constraint 'zuul/zuul_build_new_buildset_id_fkey' to system tables
| 21:14:49 |
| corvus | that's where it's failing... | 21:14:56 |
| corvus | oh nope that's a red herring sorry | 21:17:15 |
| corvus | MariaDB [zuul]> alter table zuul_build
-> rename index zuul_build_new_buildset_id_idx
-> to zuul_build_buildset_id_idx;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'index zuul_build_new_buildset_id_idx
to zuul_build_buildset_id_idx' at line 2
| 21:19:22 |
| corvus | that's the problem | 21:19:25 |
| corvus | so i think we are looking at a too-old mariadb for this sql | 21:19:33 |
| corvus | i think the best way through this is for me to manually finish the migration with whatever syntax this mariadb wants; then i guess maybe we really should upgrade it | 21:20:06 |
| Clark | I think there was a path to add a new key and delete the old key in those migrations | 21:20:11 |
| Clark | ++ | 21:20:16 |
| corvus | https://mariadb.com/kb/en/alter-table/#rename-indexkey | 21:21:57 |
| corvus | that was added in 10.5 | 21:22:01 |
| Paladox none | Is there anyway to select a mariadb version or is it google forces you to use x version as it's managed by them | 21:24:25 |
| corvus | i'm honestly not sure | 21:25:02 |
| corvus | i'm starting to get the feeling that "managed" may be a generous term | 21:25:25 |
| corvus | and probably what we should do is just copy the mariadb config we use in opendev and translate it to some k8s, then we'll all be in the same boat :) | 21:25:53 |
| corvus | Clark: did some research and we decided that we should run mariadb container images with the "auto-upgrade" flag set, so we can easily periodically bump mariadb versions and it will handle the upgrade | 21:26:36 |
