| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-13 | |||
| 09:32:04 | sean-k-mooney | zingo so timeline wise caracal (2024.1) will still be based on ubuntu 22.04 and the D cycle 2024.2 shoudl be based on 24.04 | |
| 09:32:43 | sean-k-mooney | zigo: ^ for nova i woudl liek to merge the final patches so that we can run on 2.0 and im hoping the rest of openstack catches up in caracal | |
| 09:33:04 | sean-k-mooney | but im not exepcting it to become our default until D | |
| 09:33:41 | sean-k-mooney | althoguh i woudl be fine with nova runing most of our jobs with 2.0 provided we still had 1.4 coverage in at least one job | |
| 09:34:21 | sean-k-mooney | right now we have the opisite situation where we run most of our jobs on 1.4 but have a singel job testing 2.0 and we enabel all the wranings in yoru unit/funcitonal tests | |
| 09:34:55 | sean-k-mooney | once we are 2.0 comptaible it woudl be really nice if we could make that warning an error by the way | |
| 09:36:01 | sean-k-mooney | zigo: i dont know if you can take the same approch tumbleweed did nan have a second package for SQLA | |
| 09:36:24 | zigo | sean-k-mooney: I can't, that's not how Debian works. | |
| 09:36:24 | sean-k-mooney | they moved the main package to 2.0 and added a second package to track 1.4 | |
| 09:36:45 | zigo | There would be a path clash ... | |
| 09:37:08 | zigo | "import sqlalchemy" would need to be rewritten to "import sqlalchemy1" or something ... | |
| 09:37:16 | sean-k-mooney | sure on any one system | |
| 09:37:19 | sean-k-mooney | you could only have one | |
| 09:37:19 | zigo | Plus many many hacks. | |
| 09:37:37 | sean-k-mooney | but you could declare one package as conflicting with the other | |
| 09:38:01 | zigo | First, that's forbidden by the Debian policy to do that. Second, I'm not packaging for chroot or venvs... packages are supposed to be co-installable. | |
| 09:38:25 | sean-k-mooney | well tere are packages on debian that do that | |
| 09:38:33 | sean-k-mooney | and yes i know they are ment ot be co installable | |
| 09:38:58 | sean-k-mooney | i was just giving you options since bobcat wont be 2.0 compatiable in its entirity | |
| 09:39:04 | sean-k-mooney | althoguh caracal should be | |
| 09:39:51 | zigo | It's packages that are supposed to be different implementation of the same functionality, like gawk vs mawk. This is *NOT* for having multiple versions of the *SAME* package. | |
| 09:40:06 | zigo | So, your option is unfortunately not an option ... :/ | |
| 09:40:29 | zigo | sean-k-mooney: Really, my only viable option is to have patches backported from master ... | |
| 09:40:31 | sean-k-mooney | ya where i saw it was differnt pipewire backend plugins | |
| 09:42:17 | sean-k-mooney | zigo: so it was not a comunity goal to get this done this cycle | |
| 09:42:23 | sean-k-mooney | so they may or may not be written | |
| 09:42:49 | sean-k-mooney | that said several of us really wanted to get to that point since it was discussed as a possibel goal a few times | |
| 09:42:50 | zigo | This fact (that it was not a comunity goal) doesn't change anything to the situation, unfortunately ... | |
| 09:43:30 | zigo | I can live with a broken heat package in Unstable for some time, that's ok-ish, the backport will probably work. | |
| 09:43:35 | sean-k-mooney | well the question is do you need bobcat to run with 2.0 for debian or is the 2.0 change going to happen later | |
| 09:43:48 | zigo | But it has to be taken seriously and it'd be best if we have a patch soon. | |
| 09:44:05 | zigo | I'd have to discuss with the SQLAlchemy maintainer... | |
| 09:44:21 | zigo | Though he's pressing to have the package migrate to Unstable ... | |
| 09:44:23 | sean-k-mooney | what im really getting at is what was your orgianl plan and timeline | |
| 09:44:39 | sean-k-mooney | ya so i think it woudl be goood to get it in unstable | |
| 09:44:50 | sean-k-mooney | so that we can hopefuly get it in ubuntu 24.04 | |
| 09:44:53 | zigo | My original plan was to have Bobcat support 2.0, and upload it together with OpenStack when Bobcat is released. | |
| 09:45:02 | sean-k-mooney | ack | |
| 09:45:19 | zigo | I may follow that path even with a broken heat package in Unstable... | |
| 09:45:32 | sean-k-mooney | for what its worth i was really really hoping all openstack whoudl have got to 2.0 compatibliy in bobcat too | |
| 09:45:57 | zigo | FYI, that's ortogonal to maintaining the unofficial bookworm-bobcat backport repository that most Debian users will consume instead of unstable/testing. | |
| 09:46:27 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Replace use of backref https://review.opendev.org/c/openstack/nova/+/860829 | |
| 09:46:28 | opendevreview | Stephen Finucane proposed openstack/nova master: objects: Stop fetching from security_groups table https://review.opendev.org/c/openstack/nova/+/860850 | |
| 09:46:28 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | |
| 09:46:31 | zigo | Also, the real question we should ask zzzeek about: how come he's breaking everyone ?!? | |
| 09:46:53 | zigo | The Linux kernel is *never* breaking userland, I don't see why this must happen every weekend in the Python ecosystem. :( | |
| 09:47:05 | sean-k-mooney | zigo: this is not zzzeek fault | |
| 09:47:22 | zigo | I admit I don't have the details (didn't have time to look). | |
| 09:47:30 | sean-k-mooney | zigo: in fact the 1.4 bridge release is them going well out of there way to provide a smooth upgrade path | |
| 09:48:01 | WJeffs | Hey all, is anyone running AMD genoa cpus, that I could query some stuff to them? | |
| 09:48:06 | zigo | Well, there should be no need for an upgrade path, there should be backward compat forever, that's the point I'm making. | |
| 09:48:38 | sean-k-mooney | zigo: right which as a software maintainer you hsould knwo woudl be unresable ot continue in a supprot way | |
| 09:48:48 | sean-k-mooney | he coudl freeze the old apis | |
| 09:49:02 | sean-k-mooney | but there were fundemetal changes to the core | |
| 09:49:14 | sean-k-mooney | to use and adpat to new python changes | |
| 09:49:25 | zigo | How do you explain the Linux kernel does it the proper way then? | |
| 09:49:29 | sean-k-mooney | and to solve some correctness issues that needed the api to change | |
| 09:49:58 | zigo | And the kernel is a *WAY* bigger and complicated... | |
| 09:50:01 | sean-k-mooney | zigo: by letting the old api bit rot | |
| 09:50:25 | zigo | Well, the current situation shows it was the way to go... :) | |
| 09:51:01 | sean-k-mooney | im not really sure it does | |
| 09:51:16 | sean-k-mooney | we are not going to be droping 1.4 support in openstack for some time | |
| 09:51:56 | sean-k-mooney | and i dont think zzzeek plans ot dicontinue it for some tiem either | |
| 09:52:08 | sean-k-mooney | yes the fact breakign changes are required is unfortunet | |
| 09:52:24 | sean-k-mooney | that does not mean we shoudl never do them just in frequesntly when its the best option | |
| 09:53:23 | zigo | Don't get me wrong, I do love SQLAlchemy, though in the past, every upgrade to a minor version has broke all of OpenStack. The switch from 1.4 to 2.x is kind of very painful, as we're discussing. Well, that's *very* bad practice that zzzeek should learn to *not* reproduce ever again. | |
| 09:54:07 | sean-k-mooney | its actully not that painful to adapt too | |
| 09:54:16 | sean-k-mooney | but it was not a priorty for most of the maintainers | |
| 09:54:33 | sean-k-mooney | only a few have wanted to spend time on it and done most of the work | |
| 09:54:33 | zigo | But the old code should still be working with the new version ... | |
| 09:54:53 | sean-k-mooney | it is in 1.4 which is a long term supprot branch to make it work | |
| 09:55:01 | zigo | Doesn't work for me... | |
| 09:55:07 | sean-k-mooney | zigo: to be clear some of the api had diffent behavior on diffent backend due to bugs | |
| 09:55:11 | zigo | Only a single version will live in the distro, as we discussed... | |
| 09:55:15 | sean-k-mooney | that coudl not be fixed without breakign changes | |
| 09:55:22 | zigo | Ok. | |
| 09:55:34 | zigo | :) | |
| 09:55:40 | zigo | This makes a lot more sence then. | |
| 09:55:56 | sean-k-mooney | its becasue theere is no one SQL | |
| 09:56:08 | sean-k-mooney | thers is TSQL PSQL and what ever mariadb calls it | |
| 09:56:15 | zigo | Maybe zzzeek can help fixing Heat and oslo.db? | |
| 09:56:29 | sean-k-mooney | oslo.db i think basically works | |
| 09:56:39 | sean-k-mooney | heat im not sure about | |
| 09:56:59 | zigo | Oh, btw, should I revert my packaging to oslo.db 12.3.2 ? | |
| 09:57:24 | sean-k-mooney | stephenfin: ^ | |
| 09:57:28 | zigo | (ie: leave 14.0.0 in Experimental, and just bump to 12.3.2 in unstable...) | |
| 09:58:31 | zigo | Anyways thanks a lot for discussing the mater with me, that's very helpful. | |
| 09:58:45 | zigo | At least, I know what's going on. | |
| 09:58:50 | sean-k-mooney | https://review.opendev.org/q/topic:sqlalchemy-20+status:open | |
| 09:58:59 | sean-k-mooney | that is the topic wiht all the pending packages | |
| 09:59:13 | sean-k-mooney | which unfortunelly still has nova and placement in it | |
| 10:09:30 | zigo | stephenfin: Most patches are from you, so I have to thank you as well ! :) | |
| 10:10:15 | sean-k-mooney | yep stephenfin went out of there way to try and update proejct that did nto have peopel steping up to do it | |
| 10:10:32 | sean-k-mooney | unfortuetly that still needs that projects core team to review it | |
| 10:25:27 | bauzas | sean-k-mooney: again, please understand that we have review priorities | |
| 10:25:42 | bauzas | and sqla 2.0 isn't really a prio | |
| 10:26:37 | sean-k-mooney | bauzas: it really was ment to be | |
| 10:26:48 | sean-k-mooney | and i find the fact you didnt consider it to be one a probelm | |
| 10:27:41 | sean-k-mooney | it means we are not comunicating what our priorites are as a team properly | |
| 10:44:32 | stephenfin | bauzas: I struggle to see how adapting to the new major version of a critical library is anything but a priority, especially when it's being treated as such by every other project team | |