| *** bauzas_ is now known as bauzas | 00:40 | |
| *** bauzas_ is now known as bauzas | 04:59 | |
| *** bauzas_ is now known as bauzas | 05:08 | |
| *** bauzas_ is now known as bauzas | 05:50 | |
| *** bauzas_ is now known as bauzas | 06:06 | |
| *** bauzas_ is now known as bauzas | 06:51 | |
| elodilles | sean-k-mooney bauzas : oslo.log upper bump patch's tests are passing now \o/ https://review.opendev.org/c/openstack/requirements/+/892928 | 07:00 |
|---|---|---|
| elodilles | thanks sean-k-mooney o/ | 07:00 |
| bauzas | good to hear | 07:26 |
| frickler | ack, thx for fixing this. sean-k-mooney would you reconsider your -1 on 892928 then? | 07:36 |
| stephenfin | bauzas: around now | 08:00 |
| bauzas | stephenfin: wrapping a few things now, but to;dr: would like to discuss any performance hit on https://review.opendev.org/c/openstack/nova/+/860829 | 08:02 |
| bauzas | stephenfin: read above my comments | 08:02 |
| bauzas | my only concern is to make sure that if land quite late in the cycle this change, we wouldn't see any performance change in terms of SQL execution plan | 08:03 |
| stephenfin | ah, so that won't actually bump us to SQLAlchemy 2.x: it only prepares us for it | 08:03 |
| bauzas | since most of the calls are changing queries against instances or instance extras | 08:03 |
| bauzas | stephenfin: yeah yeah gotcha | 08:04 |
| bauzas | it's a new 1.4 feature | 08:04 |
| bauzas | and I've done my homework | 08:04 |
| stephenfin | and there should be no impact to the SQL actually generated for 1.4 as it's merely a different way to describe the same thing | 08:04 |
| bauzas | the objects relationships diffezr | 08:04 |
| stephenfin | the relationships haven't changed. All that has changed is how we describe them | 08:04 |
| bauzas | but the docs don't tell anything about the executed JOINs | 08:04 |
| bauzas | stephenfin: that's my natural first thoughts, but then I wonder if the description change may arise some query modification | 08:05 |
| stephenfin | this model is preferred because it's more explicit and iiuc allows for type hinting without a separate plugin | 08:05 |
| bauzas | since relationships are now both-ways | 08:05 |
| stephenfin | they were always both ways | 08:06 |
| stephenfin | for example: look at the first thing we modified in https://review.opendev.org/c/openstack/nova/+/860829/1/nova/db/api/models.py | 08:06 |
| stephenfin | sorry, https://review.opendev.org/c/openstack/nova/+/860829/1/nova/db/api/models.py#b150 (with anchor) | 08:06 |
| stephenfin | that's saying the local side is called 'host_mapping' and the remote side is called 'cell_mapping' | 08:07 |
| stephenfin | as defined by the backref | 08:07 |
| stephenfin | now, instead of declaring both of these on one side, we declare it on both sides | 08:07 |
| stephenfin | so if anything it's a bit more duplication but for the advantage of explicitness and readability/parseability | 08:08 |
| stephenfin | bauzas: here, compare the output of these. First, with backref: https://paste.opendev.org/show/bD4K8pJoSl212q37kvEZ/ | 08:16 |
| stephenfin | then, with back_populates: https://paste.opendev.org/show/bonhcuiyNJtYmM0wITE0/ | 08:16 |
| bauzas | excellent, that's what I was testing | 08:17 |
| stephenfin | they're modified versions of my examples from https://that.guru/blog/sqlalchemy-relationships-without-foreign-keys/ | 08:17 |
| stephenfin | spoiler: it's the same SQL | 08:17 |
| bauzas | so the main thing to doublecheck is that the implicit relationship that was given by the other way is now explicit in the object | 08:18 |
| bauzas | right? | 08:18 |
| bauzas | because if not, we regress by loosing a JOIN | 08:18 |
| stephenfin | yeah, that makes sense | 08:19 |
| opendevreview | Merged openstack/os-vif stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/os-vif/+/894060 | 08:50 |
| bauzas | stephenfin: I may have spotted a problem with bdms.deleted https://review.opendev.org/c/openstack/nova/+/860829 | 09:44 |
| bauzas | stephenfin: I need to go off the keyboard for gym reasons but I'll be back in the afternoon | 09:45 |
| * bauzas drops now | 09:46 | |
| kashyap | Hehe, "gym reasons" | 09:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | 10:56 |
| bauzas | kashyap: I don't know how to call what I do :) let's say physical prep :) | 12:25 |
| kashyap | Heh, I was just joking, dont' worry :) | 13:01 |
| stephenfin | bauzas: you saw my reply, I assume? | 13:34 |
| stephenfin | i can squash if you'd like but it's much of a muchness given it's "dead code" | 13:35 |
| bauzas | stephenfin: I was literally seconds before pinging you | 13:35 |
| bauzas | stephenfin: my only concern is that I need to check why we have this bdm relationship and I don't trust our test coverage for saying whether it's unused or not | 13:36 |
| bauzas | at least I certainly understand why the backref was limiting to existing BDMs and not the deleted ones | 13:36 |
| bauzas | stephenfin: wouldn't be easier to change the relationship in your first change to continue querying the non-deleted BDMs, and *then* remove the relationship later ? | 13:37 |
| stephenfin | it would but then I need to rebase and lose the +2s :) | 13:38 |
| bauzas | so, we could somehow merge the first one in Bobcat while the latter would be in Caracal | 13:38 |
| bauzas | stephenfin: if this is just about a +2, we can ping sean-k-mooney :) | 13:38 |
| stephenfin | Okay, once I know it won't take many months before it's looked at again :) I'll respin shortly after my current meeting | 13:44 |
| bauzas | sure, I'll look | 13:48 |
| bauzas | again, matter of priorities, y'know< | 13:49 |
| opendevreview | Merged openstack/nova-specs master: Create specs directory for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/889177 | 14:14 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Replace use of backref https://review.opendev.org/c/openstack/nova/+/860829 | 14:30 |
| opendevreview | Stephen Finucane proposed openstack/nova master: objects: Stop fetching from security_groups table https://review.opendev.org/c/openstack/nova/+/860850 | 14:30 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | 14:30 |
| stephenfin | bauzas: sean-k-mooney: ^ | 14:30 |
| bauzas | reminder : nova meeting in 10 mins | 15:50 |
| bauzas | stephenfin: saw your update, thanks, but I need to continue reviewing it | 15:50 |
| bauzas | shit | 16:03 |
| bauzas | #startmeeting nova | 16:03 |
| opendevmeet | Meeting started Tue Sep 12 16:03:33 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:03 |
| opendevmeet | The meeting name has been set to 'nova' | 16:03 |
| bauzas | sorry folks about the late start :) | 16:03 |
| auniyal | o/ | 16:03 |
| gibi | o/ | 16:03 |
| elodilles | o/ | 16:03 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:03 |
| Uggla | o/ | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info One Critical bug | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1983863 | 16:04 |
| bauzas | but iiuc, the fix is now merged | 16:04 |
| bauzas | so, will be closed soon-ish | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 49 new untriaged bugs (+0 since the last meeting) | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:05 |
| bauzas | #info bug baton is bauzas | 16:05 |
| bauzas | taking the baton for this week again | 16:05 |
| bauzas | any bug to discuss ? | 16:05 |
| auniyal | bauzas, ci bug https://bugs.launchpad.net/nova/+bug/2035095 | 16:05 |
| bauzas | I've seen an excerpt of this | 16:06 |
| bauzas | basically the port doesn't become active | 16:06 |
| bauzas | let's discuss this gate failure in the next topic | 16:06 |
| bauzas | #topic Gate status | 16:06 |
| auniyal | ack, | 16:06 |
| gibi | is it a duplicate of https://bugs.launchpad.net/neutron/+bug/1940425 ? | 16:06 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:06 |
| bauzas | so | 16:06 |
| bauzas | auniyal: yes indeed, could you please mark it dup ? | 16:07 |
| auniyal | yes | 16:07 |
| gmann | o/ | 16:07 |
| bauzas | cool | 16:07 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:07 |
| bauzas | #info nova-emulation is still b0rked | 16:08 |
| bauzas | #info https://zuul.openstack.org/build/d2ddbb3f307549aaa0575b9ee0f1daab | 16:08 |
| bauzas | lots of keystone failures this time | 16:08 |
| bauzas | so I guess this is unfortunate | 16:08 |
| bauzas | moving on then ? | 16:11 |
| bauzas | shall we discuss any other gate failure ? | 16:11 |
| bauzas | looks not | 16:12 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:12 |
| bauzas | #topic Release Planning | 16:12 |
| bauzas | #link https://releases.openstack.org/bobcat/schedule.html | 16:12 |
| bauzas | #info Nova deadlines are set in the above schedule | 16:12 |
| bauzas | #info 2 days before RC1 | 16:12 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bobcat-rc-potential Etherpad for tracking RCs | 16:12 |
| bauzas | basically all the needed changes are approved now, | 16:12 |
| bauzas | the cycle highlights got a correct round of reviews | 16:12 |
| bauzas | so I'll prepare the reno prelude patch based on the highlights tomorrow morning | 16:13 |
| bauzas | ok, let's jump then | 16:14 |
| bauzas | #topic Review priorities | 16:15 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | 16:15 |
| bauzas | #info As a reminder, people eager to review changes can +1 to indicate their interest, +2 for asking cores to also review | 16:16 |
| bauzas | #topic Stable Branches | 16:16 |
| bauzas | elodilles: please help me by stopping my monolog :) | 16:16 |
| elodilles | :) | 16:16 |
| elodilles | #info first stable/2023.2 branches were cut (libraries & client libraries), rest will be cut this week with rc1 patches | 16:16 |
| elodilles | #info all stable gates should be OK, though not much activity on stable branches these days | 16:16 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:16 |
| elodilles | that's all from me | 16:17 |
| auniyal | #info Please{10} *review* these backport patches of stable 2023.1, zed and yoga for next minor release | 16:17 |
| auniyal | #info most of these already have one +2. | 16:17 |
| auniyal | #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview | 16:17 |
| bauzas | cool, I'll do a round of reviews | 16:17 |
| bauzas | #topic Open discussion | 16:17 |
| bauzas | I have one | 16:18 |
| bauzas | (bauzas) Can't chair next meeting, who else ? | 16:18 |
| bauzas | (I'll need to attend a parent-teacher meeting for my daughter's class next week) | 16:18 |
| bauzas | so, any volunteer ? | 16:19 |
| gibi | if nobody else then I will | 16:19 |
| bauzas | 1.. | 16:19 |
| sean-k-mooney | i have i have one or two topics to bring up quickly. thanks gibi | 16:19 |
| bauzas | sean-k-mooney: you mean, you appreciate gibi for chairing next week ? :) | 16:20 |
| sean-k-mooney | yes | 16:20 |
| bauzas | cool | 16:20 |
| bauzas | 2.. | 16:20 |
| bauzas | 3.. | 16:20 |
| bauzas | sold | 16:20 |
| bauzas | #info gibi will chair next week's meeting | 16:20 |
| sean-k-mooney | i could proably do it if he is not around for any reason i just dont want too :) | 16:20 |
| gibi | sure I will do it | 16:20 |
| bauzas | sean-k-mooney: shoot your own topics (even if I can guess one) | 16:20 |
| sean-k-mooney | first one is this stable only patch that we agreed to do a year ago | 16:20 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/828979 | 16:21 |
| sean-k-mooney | im reviewing it now | 16:21 |
| sean-k-mooney | and it looks ok | 16:21 |
| sean-k-mooney | so just wanted to highlight it to others | 16:21 |
| sean-k-mooney | the second quetion is semi procedural | 16:21 |
| bauzas | want it for Bobcat ? | 16:21 |
| bauzas | nvm, stupid me | 16:21 |
| sean-k-mooney | its for victoria | 16:22 |
| bauzas | yeah, hence me stupid | 16:22 |
| sean-k-mooney | so second question is we were discussing on the mailing list about removing the hyperv driver | 16:22 |
| sean-k-mooney | and vmeare next cycle | 16:22 |
| bauzas | yeah and I provided my humble guts | 16:22 |
| sean-k-mooney | we can chat about that in the ptg if needed | 16:22 |
| sean-k-mooney | but i was wondering do we need a spec | 16:22 |
| bauzas | which are, unless extremely necessary, avoid any virt driver deprecation this cycle | 16:23 |
| sean-k-mooney | or just come to agreement and specless blueprint | 16:23 |
| bauzas | s/deprecation/removal | 16:23 |
| bauzas | for removing those from our tree ? | 16:23 |
| sean-k-mooney | we deprecated them in antileop and marked them experimental | 16:23 |
| sean-k-mooney | so in caracal i want to remove them form the nova tree | 16:23 |
| bauzas | yeah I know hence my sedf | 16:23 |
| gibi | I don't think we need a spec to delete things | 16:24 |
| bauzas | yeah, so, procedurally, I'd say "mail ML ops" wins against any other paperwork | 16:24 |
| bauzas | I just want the ops to be aware of the cut | 16:24 |
| bauzas | and yeah, it doesn't require a blueprint | 16:24 |
| bauzas | a relnote, for sure | 16:24 |
| gmann | bauzas: sean-k-mooney I am planning the hyperv removal and other os-win cleanup/retirement in 2024.1 only | 16:25 |
| bauzas | this is just a removal patch | 16:25 |
| sean-k-mooney | ok well we can chat about it more in the ptg i guess and send a mail to that list | 16:25 |
| bauzas | but yeah, communication matters | 16:25 |
| gmann | this is whole stack #link https://review.opendev.org/q/topic:retire-winstackers | 16:25 |
| sean-k-mooney | gmann: yep this is all in the context of 2024.1 | 16:25 |
| gmann | yeah | 16:25 |
| sean-k-mooney | i just wanted to know how to track this | 16:25 |
| gmann | and I need to add a spec also as it impact one API too | 16:25 |
| gmann | so all those we can discuss together in PTG | 16:26 |
| bauzas | when we removed nova-net, this wasn't tracked by a blueprint | 16:26 |
| gmann | sean-k-mooney: yeah, will add BP and spec | 16:26 |
| bauzas | and this was having API implications | 16:26 |
| sean-k-mooney | im not sure what api impact this will have | 16:26 |
| gmann | I will propose that, its rdp console I think | 16:27 |
| bauzas | tbc, I don't want us to paperwork any removal | 16:27 |
| sean-k-mooney | ah rdp | 16:27 |
| bauzas | a deprecation for sure, but this was communicated way in advance | 16:27 |
| sean-k-mooney | i think that kind of seperate | 16:27 |
| gmann | spec is worth here so that we do not miss anything | 16:27 |
| sean-k-mooney | it should be sperate commits at least but ok | 16:27 |
| gmann | especially API change point of view | 16:27 |
| bauzas | then, I defer this discussion to the PTG | 16:27 |
| sean-k-mooney | i think we can wrap the meeting there | 16:28 |
| bauzas | we need more contact | 16:28 |
| bauzas | context | 16:28 |
| bauzas | doh | 16:28 |
| gmann | sure, will propose the spec meanhwile and can discuss in PTG | 16:28 |
| bauzas | sean-k-mooney: wanted to discuss the SQLA 1.4 backref thing ? | 16:28 |
| sean-k-mooney | am i kind of forgot | 16:28 |
| bauzas | to be frank, I already made a round of reviews | 16:28 |
| sean-k-mooney | so stephen has updated the patchs to address the comment you raised | 16:28 |
| bauzas | so, yeah, this is best effort, but I have some space for this | 16:29 |
| bauzas | if we can have this quickwin, let's aim it | 16:29 |
| bauzas | but we absolutely need to be on par with the existing | 16:29 |
| bauzas | that's why I'm OK with changing our description of the relationships in B, but not drop anything until C | 16:30 |
| 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 |
| sean-k-mooney | but stephen has updated it | 16:30 |
| sean-k-mooney | there are no drops in the serises | 16:31 |
| bauzas | sean-k-mooney: well, instance.block_device_mapping may have returned the deleted BDMs after this patch | 16:31 |
| sean-k-mooney | no | 16:31 |
| bauzas | sean-k-mooney: there are, last patch of 34 | 16:31 |
| bauzas | 3* | 16:31 |
| sean-k-mooney | i think stephen was correct that tnat version of the relaation was unused | 16:31 |
| sean-k-mooney | but again that has been fixed in the current version | 16:31 |
| sean-k-mooney | and stephen added a 3rd patch to remove the possible unused relationship mapping | 16:32 |
| sean-k-mooney | in any case lets just review it as normal | 16:32 |
| bauzas | that's what I'm saying | 16:32 |
| bauzas | I don't bet on things we may not use | 16:32 |
| bauzas | particularly by relying on our CI to claim whether this is in use or not | 16:32 |
| bauzas | so, I'm OK with doing this kind of dumb rewriting of the relationships we have | 16:33 |
| bauzas | without touching them or asserting anything | 16:33 |
| bauzas | in B | 16:33 |
| bauzas | while in C, we may debate on the optimizations we may do | 16:33 |
| sean-k-mooney | yep im expecting the 3 patch to be masteer only | 16:34 |
| sean-k-mooney | well calacal only | 16:34 |
| sean-k-mooney | i would like the first to to be in bobcat | 16: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 |
| 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:35 |
| bauzas | sean-k-mooney: cool, then we have a consensus | 16:36 |
| bauzas | any other item to discuss ? | 16:36 |
| sean-k-mooney | not form me. although fyi ill be on pto the week after next | 16:36 |
| 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:36 |
| gmann | ++ on the plan you mentioned | 16:37 |
| JayF | sean-k-mooney: gmann: I've done some research on that; no distros except Gentoo ship SQLA whatsoever right now | 16:37 |
| JayF | sean-k-mooney: gmann: Including e.g. Debian SID | 16:37 |
| 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 |
| gmann | yeah, that is good point | 16:37 |
| JayF | s/SQLA whatsoever/SQLA 2.0 whatsoever/ | 16:38 |
| sean-k-mooney | python3-sqlalchemy/unstable,unstable 1.4.47+ds1-1 all | 16:38 |
| bauzas | yeah, and that's why I'm focusing only on the backref thing which is 1.4 | 16:38 |
| sean-k-mooney | ya sid has 1.4.47 | 16:38 |
| 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 |
| bauzas | enabling SQLA 2.0 is a way larger convo | 16:38 |
| 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:38 |
| bauzas | cool, we are on page | 16:39 |
| gmann | yeah, we need to wait for that | 16:39 |
| bauzas | looks like we have a violent agreement, anything to add ? | 16:39 |
| bauzas | if not, let's pretend I'm just giving you back 20 mins of your time | 16:40 |
| bauzas | thanks all | 16:40 |
| bauzas | #endmeeting | 16:40 |
| 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 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.html | 16:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.txt | 16:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-12-16.03.log.html | 16:40 |
| sean-k-mooney | JayF: given SQLAlchemy is now up to 2.0.20 | 16:41 |
| sean-k-mooney | i wonder how much fo the disto lag is becuase openstack and other poject have not moved yet | 16:41 |
| 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 |
| 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:42 |
| 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 |
| JayF | so I did the legwork and found that sadly, they are correct :( | 16:43 |
| JayF | (despite some folks asserting otherwise at the forum session about it) | 16:44 |
| sean-k-mooney | i think that feedback we shoudl be bringing to our downstream disto contacts | 16:44 |
| 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:44 |
| sean-k-mooney | currenly nova requires SQLAlchemy>=1.4.13 | 16:45 |
| sean-k-mooney | but i am hopign we can get to and stay at 2.0 compatiblity soon | 16:45 |
| 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:45 |
| 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 |
| sean-k-mooney | well i think stephenfin already spend a time moving a lot of projects | 16:46 |
| JayF | get that man a cape with "OSLO" on the back :D | 16:46 |
| 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 |
| sean-k-mooney | JayF: yep we already doo | 16:47 |
| JayF | nice | 16:48 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/tox.ini#L23 | 16:48 |
| 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:54 |
| JayF | zigo: ^ do you have any idea for a timeline or liklihood for sqlalchemy hitting 2 in debian? | 16:55 |
| 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:57 |
| sean-k-mooney | the kogi build is failing however https://koji.fedoraproject.org/koji/taskinfo?taskID=104893237 | 16:58 |
| 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:00 |
| sean-k-mooney | ah they aslso ship python311-SQLAlchemy1 which is 1.4 | 17:02 |
| JayF | That is brand new. I checked there before abandoning my TC resolution a weekish ago | 17:02 |
| JayF | but I might have been looking for sqlalchemy named packages and missed it, with that in mind | 17:02 |
| sean-k-mooney | they ship 2 packages now at least | 17:03 |
| sean-k-mooney | the main package python311-SQLAlchemy is now 2.0 and they have python311-SQLAlchemy1 is 1.4.46 | 17:04 |
| opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Query for shards with proper, plural key https://review.opendev.org/c/openstack/nova/+/894833 | 21:42 |
| 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. | 21:48 |
| 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 |
| zigo | If you guys need it now, I can ask for an upload to Unstable right away... | 23:12 |
| zigo | Though I'd prefer for the release to happen. | 23:13 |
| zigo | What's the situation on Bobcat? Are we 100% SQLA 2.x compatible already? | 23:13 |
| zigo | If not, it's going to be huge troubles for me (unless there's patches I can apply on top of Bobcat). | 23:14 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!