Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-09-12
16:26:21 bauzas when we removed nova-net, this wasn't tracked by a blueprint
16:26:25 gmann sean-k-mooney: yeah, will add BP and spec
16:26:37 bauzas and this was having API implications
16:26:50 sean-k-mooney im not sure what api impact this will have
16:27:03 gmann I will propose that, its rdp console I think
16:27:08 bauzas tbc, I don't want us to paperwork any removal
16:27:20 sean-k-mooney ah rdp
16:27:27 bauzas a deprecation for sure, but this was communicated way in advance
16:27:30 sean-k-mooney i think that kind of seperate
16:27:34 gmann spec is worth here so that we do not miss anything
16:27:54 sean-k-mooney it should be sperate commits at least but ok
16:27:55 gmann especially API change point of view
16:27:56 bauzas then, I defer this discussion to the PTG
16:28:01 sean-k-mooney i think we can wrap the meeting there
16:28:05 bauzas we need more contact
16:28:08 bauzas context
16:28:10 bauzas doh
16:28:12 gmann sure, will propose the spec meanhwile and can discuss in PTG
16:28:22 bauzas sean-k-mooney: wanted to discuss the SQLA 1.4 backref thing ?
16:28:35 sean-k-mooney am i kind of forgot
16:28:51 sean-k-mooney so stephen has updated the patchs to address the comment you raised
16:28:51 bauzas to be frank, I already made a round of reviews
16:29:14 bauzas so, yeah, this is best effort, but I have some space for this
16:29:35 bauzas if we can have this quickwin, let's aim it
16:29:45 bauzas but we absolutely need to be on par with the existing
16:30:26 bauzas that's why I'm OK with changing our description of the relationships in B, but not drop anything until C
16:30:36 sean-k-mooney ack. i would be sad if this isnt included as to me it was a cycle priroty but yes. i belive the issue you raised was not actully something we needed to adress
16:30:44 sean-k-mooney but stephen has updated it
16:31:03 sean-k-mooney there are no drops in the serises
16:31:06 bauzas sean-k-mooney: well, instance.block_device_mapping may have returned the deleted BDMs after this patch
16:31:20 sean-k-mooney no
16:31:21 bauzas sean-k-mooney: there are, last patch of 34
16:31:24 bauzas 3*
16:31:43 sean-k-mooney i think stephen was correct that tnat version of the relaation was unused
16:31:52 sean-k-mooney but again that has been fixed in the current version
16:32:11 sean-k-mooney and stephen added a 3rd patch to remove the possible unused relationship mapping
16:32:21 sean-k-mooney in any case lets just review it as normal
16:32:23 bauzas that's what I'm saying
16:32:34 bauzas I don't bet on things we may not use
16:32:55 bauzas particularly by relying on our CI to claim whether this is in use or not
16:33:20 bauzas so, I'm OK with doing this kind of dumb rewriting of the relationships we have
16:33:30 bauzas without touching them or asserting anything
16:33:36 bauzas in B
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

Earlier   Later