Earlier  
Posted Nick Remark
#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
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.

Earlier   Later