Earlier  
Posted Nick Remark
#openstack-nova - 2023-09-12
16:33:55 bauzas while in C, we may debate on the optimizations we may do
16:34:13 sean-k-mooney yep im expecting the 3 patch to be masteer only
16:34:22 sean-k-mooney well calacal only
16:34:33 sean-k-mooney i would like the first to to be in bobcat
16:35:34 opendevreview Merged openstack/osc-placement stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/osc-placement/+/894066
16:35:36 sean-k-mooney i would also like us to offically deprcate supprot for SQA 1.4 in caracal and drop it in D but thats a wider discussion
16:36:09 bauzas sean-k-mooney: cool, then we have a consensus
16:36:19 bauzas any other item to discuss ?
16:36:39 sean-k-mooney not form me. although fyi ill be on pto the week after next
16:36:44 gmann that is something we discussed in TC+PTL sessions in Vancouver and moving it there is best way and hopefully in D we can remove it from requirement also but if all projects are migrated
16:37:00 gmann ++ on the plan you mentioned
16:37:08 JayF sean-k-mooney: gmann: I've done some research on that; no distros except Gentoo ship SQLA whatsoever right now
16:37:13 JayF sean-k-mooney: gmann: Including e.g. Debian SID
16:37:35 JayF sean-k-mooney: gmann: So our timing on SQLA 2.0 needs to be in line with the distros; I am personally in favor of getting there more quickly but we can't outrun the rest of the python world :D
16:37:58 gmann yeah, that is good point
16:38:07 JayF s/SQLA whatsoever/SQLA 2.0 whatsoever/
16:38:09 sean-k-mooney python3-sqlalchemy/unstable,unstable 1.4.47+ds1-1 all
16:38:13 bauzas yeah, and that's why I'm focusing only on the backref thing which is 1.4
16:38:19 sean-k-mooney ya sid has 1.4.47
16:38:31 JayF 1.4 is going to be the bridge a lot of things are on for a while; it's the release that supports both <1.4 and 2.0+ styler
16:38:41 bauzas enabling SQLA 2.0 is a way larger convo
16:38:54 JayF I'm not saying OpenStack projects should wait to move to new API; I'm saying we can't flip the requirement to actual-2.0 until distros are ready
16:39:11 bauzas cool, we are on page
16:39:12 gmann yeah, we need to wait for that
16:39:49 bauzas looks like we have a violent agreement, anything to add ?
16:40:16 bauzas if not, let's pretend I'm just giving you back 20 mins of your time
16:40:26 bauzas thanks all
16:40:28 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.log.html
16:40:28 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.txt
16:40:28 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.html
16:40:28 opendevmeet Meeting ended Tue Sep 12 16:40:28 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:40:28 bauzas #endmeeting
16:41:27 sean-k-mooney JayF: given SQLAlchemy is now up to 2.0.20
16:41:53 sean-k-mooney i wonder how much fo the disto lag is becuase openstack and other poject have not moved yet
16:42:16 JayF sean-k-mooney: Like I said; 1.4 is the release that spans both 1.3 and 2.0 supporting projects, so I suspect that's going to be the 'safe place' distros remain for a while
16:42:32 JayF sean-k-mooney: especially since, unlike with some libraries, they won't be able to patch their way into newer versions for any stragglers
16:43:08 JayF sean-k-mooney: To be clear: Ironic is 100% SQLA 2.0 compatible and I am generally a neophile so I'm all about getting on the new version; just when I did the legwork to TC-resolution it gmann and others rightfully pointed out that we can't do it until the distros do it
16:43:56 JayF so I did the legwork and found that sadly, they are correct :(
16:44:15 JayF (despite some folks asserting otherwise at the forum session about it)
16:44:27 sean-k-mooney i think that feedback we shoudl be bringing to our downstream disto contacts
16:44:33 opendevreview Merged openstack/osc-placement stable/2023.2: Update TOX_CONSTRAINTS_FILE for stable/2023.2 https://review.opendev.org/c/openstack/osc-placement/+/894067
16:45:21 sean-k-mooney currenly nova requires SQLAlchemy>=1.4.13
16:45:42 sean-k-mooney but i am hopign we can get to and stay at 2.0 compatiblity soon
16:45:54 JayF sean-k-mooney: it's tough because it cuts both directions; we have to ensure *all* openstack projects can run on 2.0 when distros move, and I'm not sure all our projects are going to be able to get there without outside help
16:46:22 JayF so on one hand, faster is better, on the other, having more time to migrate is nice (not that I have real expectation those underresourced projects will prioritize it until it becomes breaky)
16:46:29 sean-k-mooney well i think stephenfin already spend a time moving a lot of projects
16:46:47 JayF get that man a cape with "OSLO" on the back :D
16:47:22 JayF sean-k-mooney: fwiw, I assume you likely know this, but you can make 1.4 warn about 2.0-breaky things in tests: https://github.com/openstack/ironic/blob/master/tox.ini#L17
16:47:54 sean-k-mooney JayF: yep we already doo
16:48:02 JayF nice
16:48:19 sean-k-mooney https://github.com/openstack/nova/blob/master/tox.ini#L23
16:54:59 sean-k-mooney JayF: for what its worth there is an experimal 2.0.19 build in debian https://packages.debian.org/source/experimental/sqlalchemy
16:55:27 JayF zigo: ^ do you have any idea for a timeline or liklihood for sqlalchemy hitting 2 in debian?
16:57:22 sean-k-mooney fedora have this tracker https://bugzilla.redhat.com/show_bug.cgi?id=2134559 but it does not seam to be active
16:58:12 sean-k-mooney the kogi build is failing however https://koji.fedoraproject.org/koji/taskinfo?taskID=104893237
17:00:56 sean-k-mooney JayF: looks like tumbleweed are one of the first to ship it https://opensuse.pkgs.org/tumbleweed/opensuse-oss-x86_64/python311-SQLAlchemy-2.0.19-3.1.x86_64.rpm.html
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

Earlier   Later