16:03:33 <bauzas> #startmeeting nova
16:03:33 <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:33 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:33 <opendevmeet> The meeting name has been set to 'nova'
16:03:39 <bauzas> sorry folks about the late start :)
16:03:44 <auniyal> o/
16:03:46 <gibi> o/
16:03:47 <elodilles> o/
16:03:49 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:03:50 <Uggla> o/
16:03:59 <bauzas> #topic Bugs (stuck/critical)
16:04:04 <bauzas> #info One Critical bug
16:04:09 <bauzas> #link https://bugs.launchpad.net/nova/+bug/1983863
16:04:18 <bauzas> but iiuc, the fix is now merged
16:04:32 <bauzas> so, will be closed soon-ish
16:04:54 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 49 new untriaged bugs (+0 since the last meeting)
16:05:00 <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:05 <bauzas> #info bug baton is bauzas
16:05:13 <bauzas> taking the baton for this week again
16:05:19 <bauzas> any bug to discuss ?
16:05:28 <auniyal> bauzas, ci bug https://bugs.launchpad.net/nova/+bug/2035095
16:06:04 <bauzas> I've seen an excerpt of this
16:06:11 <bauzas> basically the port doesn't become active
16:06:18 <bauzas> let's discuss this gate failure in the next topic
16:06:26 <bauzas> #topic Gate status
16:06:27 <auniyal> ack,
16:06:31 <gibi> is it a duplicate of https://bugs.launchpad.net/neutron/+bug/1940425 ?
16:06:32 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:06:43 <bauzas> so
16:07:03 <bauzas> auniyal: yes indeed, could you please mark it dup ?
16:07:11 <auniyal> yes
16:07:18 <gmann> o/
16:07:50 <bauzas> cool
16:07:57 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:08:01 <bauzas> #info nova-emulation is still b0rked
16:08:05 <bauzas> #info https://zuul.openstack.org/build/d2ddbb3f307549aaa0575b9ee0f1daab
16:08:40 <bauzas> lots of keystone failures this time
16:08:47 <bauzas> so I guess this is unfortunate
16:11:16 <bauzas> moving on then ?
16:11:24 <bauzas> shall we discuss any other gate failure ?
16:12:07 <bauzas> looks not
16:12:14 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:12:18 <bauzas> #topic Release Planning
16:12:22 <bauzas> #link https://releases.openstack.org/bobcat/schedule.html
16:12:25 <bauzas> #info Nova deadlines are set in the above schedule
16:12:28 <bauzas> #info 2 days before RC1
16:12:32 <bauzas> #link https://etherpad.opendev.org/p/nova-bobcat-rc-potential Etherpad for tracking RCs
16:12:44 <bauzas> basically all the needed changes are approved now,
16:12:55 <bauzas> the cycle highlights got a correct round of reviews
16:13:08 <bauzas> so I'll prepare the reno prelude patch based on the highlights tomorrow morning
16:14:53 <bauzas> ok, let's jump then
16:15:30 <bauzas> #topic Review priorities
16:15:59 <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:16:04 <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:08 <bauzas> #topic Stable Branches
16:16:20 <bauzas> elodilles: please help me by stopping my monolog :)
16:16:26 <elodilles> :)
16:16:33 <elodilles> #info first stable/2023.2 branches were cut (libraries & client libraries), rest will be cut this week with rc1 patches
16:16:44 <elodilles> #info all stable gates should be OK, though not much activity on stable branches these days
16:16:51 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:17:02 <elodilles> that's all from me
16:17:32 <auniyal> #info Please{10} *review* these backport patches of stable 2023.1, zed and yoga for next minor release
16:17:32 <auniyal> #info most of these already have one +2.
16:17:32 <auniyal> #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview
16:17:47 <bauzas> cool, I'll do a round of reviews
16:17:55 <bauzas> #topic Open discussion
16:18:00 <bauzas> I have one
16:18:04 <bauzas> (bauzas) Can't chair next meeting, who else ?
16:18:37 <bauzas> (I'll need to attend a parent-teacher meeting for my daughter's class next week)
16:19:04 <bauzas> so, any volunteer ?
16:19:18 <gibi> if nobody else then I will
16:19:33 <bauzas> 1..
16:19:37 <sean-k-mooney> i have i have one or two topics to bring up quickly. thanks gibi
16:20:00 <bauzas> sean-k-mooney: you mean, you appreciate gibi for chairing next week ? :)
16:20:06 <sean-k-mooney> yes
16:20:10 <bauzas> cool
16:20:12 <bauzas> 2..
16:20:14 <bauzas> 3..
16:20:16 <bauzas> sold
16:20:25 <bauzas> #info gibi will chair next week's meeting
16:20:29 <sean-k-mooney> i could proably do it if he is not around for any reason i just dont want too :)
16:20:36 <gibi> sure I will do it
16:20:42 <bauzas> sean-k-mooney: shoot your own topics (even if I can guess one)
16:20:58 <sean-k-mooney> first one is this stable only patch that we agreed to do a year ago
16:21:00 <sean-k-mooney> https://review.opendev.org/c/openstack/nova/+/828979
16:21:07 <sean-k-mooney> im reviewing it now
16:21:10 <sean-k-mooney> and it looks ok
16:21:20 <sean-k-mooney> so just wanted to highlight it to others
16:21:38 <sean-k-mooney> the second quetion is semi procedural
16:21:42 <bauzas> want it for Bobcat ?
16:21:50 <bauzas> nvm, stupid me
16:22:01 <sean-k-mooney> its for victoria
16:22:05 <bauzas> yeah, hence me stupid
16:22:22 <sean-k-mooney> so second question is we were discussing on the mailing list about removing the hyperv driver
16:22:29 <sean-k-mooney> and vmeare next cycle
16:22:36 <bauzas> yeah and I provided my humble guts
16:22:46 <sean-k-mooney> we can chat about that in the ptg if needed
16:22:55 <sean-k-mooney> but i was wondering do we need a spec
16:23:02 <bauzas> which are, unless extremely necessary, avoid any virt driver deprecation this cycle
16:23:07 <sean-k-mooney> or just come to agreement and specless blueprint
16:23:08 <bauzas> s/deprecation/removal
16:23:27 <bauzas> for removing those from our tree ?
16:23:35 <sean-k-mooney> we deprecated them in antileop and marked them experimental
16:23:45 <sean-k-mooney> so in caracal i want to remove them form the nova tree
16:23:47 <bauzas> yeah I know hence my sedf
16:24:17 <gibi> I don't think we need a spec to delete things
16:24:21 <bauzas> yeah, so, procedurally, I'd say "mail ML ops" wins against any other paperwork
16:24:40 <bauzas> I just want the ops to be aware of the cut
16:24:52 <bauzas> and yeah, it doesn't require a blueprint
16:24:55 <bauzas> a relnote, for sure
16:25:17 <gmann> bauzas: sean-k-mooney I am planning the hyperv removal and other os-win cleanup/retirement in 2024.1 only
16:25:18 <bauzas> this is just a removal patch
16:25:20 <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:29 <bauzas> but yeah, communication matters
16:25:38 <gmann> this is whole stack #link https://review.opendev.org/q/topic:retire-winstackers
16:25:39 <sean-k-mooney> gmann: yep this is all in the context of 2024.1
16:25:45 <gmann> yeah
16:25:51 <sean-k-mooney> i just wanted to know how to track this
16:25:58 <gmann> and I need to add a spec also as it impact one API too
16:26:17 <gmann> so all those we can discuss together in PTG
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 <bauzas> to be frank, I already made a round of reviews
16:28:51 <sean-k-mooney> so stephen has updated the patchs to address the comment you raised
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 <bauzas> #endmeeting