| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-12 | |||
| 17:02:36 | sean-k-mooney | ah they aslso ship python311-SQLAlchemy1 which is 1.4 | |
| 17:02:38 | JayF | That is brand new. I checked there before abandoning my TC resolution a weekish ago | |
| 17:02:52 | JayF | but I might have been looking for sqlalchemy named packages and missed it, with that in mind | |
| 17:03:39 | sean-k-mooney | they ship 2 packages now at least | |
| 17:04:29 | sean-k-mooney | the main package python311-SQLAlchemy is now 2.0 and they have python311-SQLAlchemy1 is 1.4.46 | |
| 21:42:45 | opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Query for shards with proper, plural key https://review.opendev.org/c/openstack/nova/+/894833 | |
| 21:48:12 | JayF | Sorry about ^ that, details are in the bug and on the change. Glad I hooked it all up in CI instead of relying on my manual testing. | |
| 23:12:24 | zigo | JayF: It's simply waiting for OpenStack to be released, as Antelope is not SQLA 2.x compatible, the maintainer is waiting on me ... | |
| 23:12:58 | zigo | If you guys need it now, I can ask for an upload to Unstable right away... | |
| 23:13:13 | zigo | Though I'd prefer for the release to happen. | |
| 23:13:57 | zigo | What's the situation on Bobcat? Are we 100% SQLA 2.x compatible already? | |
| 23:14:36 | zigo | If not, it's going to be huge troubles for me (unless there's patches I can apply on top of Bobcat). | |
| #openstack-nova - 2023-09-13 | |||
| 00:51:58 | JayF | zigo: bobcat is not 2.0. If you have a need on a timeline please put that on the list, although it won't change bobcat it can help decide future priorities | |
| 07:18:26 | zigo | JayF: I thought it was 2.0. Yes, I do need SQLA 2.0 support in Bobcat, and will write about it in the list, thanks for your care! | |
| 07:28:02 | bauzas | zigo: the situation is quite simple, most projects try to support the new DSL of 1.4 | |
| 07:28:22 | bauzas | which is considered a bridge release speaking old pre-1.4 and new 2.0 style | |
| 07:29:12 | bauzas | but then we need some guidance, as for the moment, none of the distros ship SQLA 2.0 | |
| 07:29:38 | bauzas | it's then a classic chicken and eggs situation, if everyone awaits the other :D | |
| 07:36:31 | frickler | also see https://review.opendev.org/c/openstack/requirements/+/879743 for a (possibly incomplete) list of projects that still struggle | |
| 07:38:20 | zigo | Well, for Debian, you should consider that Experimental represent the next OpenStack stable, so SQLA 2.x is the way ... | |
| 07:38:39 | zigo | frickler: Where do I see it in that patch?!? | |
| 07:41:58 | frickler | zigo: look at the failing cross jobs. I just saw https://review.opendev.org/c/openstack/requirements/+/887261/comments/6b1f2573_60f48f1c has some more detailed analysis of the issues. but this is getting a bit offtopic for the nova channel | |
| 08:04:57 | zigo | frickler: So, if I read it well, we are down to only 4 packages, the biggest concern being heat, but it's probably still working, right? | |
| 08:11:55 | frickler | heat seems very strongly broken, see https://review.opendev.org/c/openstack/heat/+/886549 and also https://08a8510b7f90952cf4e9-7691b2eb12cb7f63209fe7ead2f9c479.ssl.cf1.rackcdn.com/887261/2/check/openstacksdk-functional-devstack/f9d3c13/controller/logs/screen-h-api.txt | |
| 09:10:25 | bauzas | stephenfin: please, just one again needed modification for sg associations in https://review.opendev.org/c/openstack/nova/+/860829 | |
| 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 | sean-k-mooney | they moved the main package to 2.0 and added a second package to track 1.4 | |
| 09:36:24 | zigo | sean-k-mooney: I can't, that's not how Debian works. | |
| 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 | zigo | Plus many many hacks. | |
| 09:37:19 | sean-k-mooney | you could only have one | |
| 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: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | |
| 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: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 | zigo | But the old code should still be working with the new version ... | |
| 09:54:33 | sean-k-mooney | only a few have wanted to spend time on it and done most of the work | |
| 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 | |