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