16:00:16 <gibi> #startmeeting nova
16:00:16 <openstack> Meeting started Thu Jul 23 16:00:16 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <gibi> o/
16:00:19 <openstack> The meeting name has been set to 'nova'
16:00:45 <elod> o/
16:02:06 <gibi> what a crowd
16:02:10 <gibi> anyhow
16:02:13 <bauzas> \o
16:02:22 <gibi> #topic Bugs (stuck/critical)
16:02:31 <gibi> No Critical bugs
16:02:34 <gmann> o/
16:02:36 <gibi> #link 32 new untriaged bugs (-2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:42 <gibi> please look at the untriaged bug list and try to push some bugs forward
16:02:59 <gibi> is there any bug we need to discuss?
16:05:04 <gibi> #topic Runways
16:05:08 <gibi> etherpad #link https://etherpad.opendev.org/p/nova-runways-victoria
16:05:12 <gibi> the bp/use-pcpu-and-vcpu-in-one-instance has been completed. \o/
16:05:19 <gibi> the bp/add-emulated-virtual-tpm moved to a slot and the bottom part of that has already +2 from me
16:05:34 <gibi> the slot for bp/provider-config-file expiring today. tony_su got feedback on the patch series and I'm +2 on the bottom patch. tony_su working on the rest of the series based on the feedback.
16:05:44 <gibi> the cyborg patches #link https://review.opendev.org/#/q/(topic:bp/nova-cyborg-interaction+OR+topic:bp/cyborg-rebuild-and-evacuate)+status:open also got feedback and the bottom has a +2. the rest of the series need some work from brinzhang_
16:05:56 <bauzas> fwiw, I'm reviewing the vTPM series with an upgrade concerned eye
16:06:04 <gibi> bauzas: thanks!
16:06:15 <stephenfin> and I've a -1 on the bottom patch in the provider-config-file series
16:06:23 <stephenfin> and most of the other patches
16:06:27 <gibi> stephenfin: ahh correct. I saw it but forget it
16:06:33 <gibi> stephenfin: thanks for checking it
16:06:36 <bauzas> looks like we haven't discussed in the spec about upgrade implications, so this necessarly has to be addressed at review time
16:07:07 <gibi> bauzas: do you see upgrade issues?
16:07:20 <bauzas> not really, just considering the upgrade case
16:07:27 <bauzas> and what would happen in one year
16:08:34 <gibi> OK
16:08:45 <stephenfin> Can keep the discussion ongoing in openstack-nova, but I think we've covered ourselves sufficiently (by way of traits and API checks)
16:09:06 <gibi> cool, please continue it on #openstack-nova
16:09:08 <gibi> if needed
16:09:28 <gibi> anything else to be discussed regarding the features in the runway slots?
16:10:03 <stephenfin> not from me
16:10:53 <gibi> #topic Release Planning
16:11:01 <gibi> next weeks is Victoria M2 which will be the spec freeze
16:11:08 <gibi> os-vif does not need a release as we did not merge any commit since the previous release
16:11:14 <gibi> we released python-novaclient for M2 #link https://review.opendev.org/#/c/742378/
16:12:03 <gibi> I will not be here next week for the M2 but bauzas and dansmith has the power do anything needed. I don't foresee anything to be done next week
16:12:34 <gibi> I will make the spec freeze announcment on the Monday after the M2 when I'm back
16:13:29 <gibi> anything else related to the coming M2 ?
16:14:26 <gibi> #topic Stable Branches
16:14:32 <bauzas> roger .
16:15:05 <elod> if lyarwood is not here, then some info from me:
16:15:07 <gibi> elod: do you have any new from stable side as lyarwood cannot make it today
16:15:33 <elod> stable gate was in a good shape, so quite many backported bugfixes landed
16:16:03 <elod> also, a stein release is planned:
16:16:05 <elod> https://review.opendev.org/#/c/741760/
16:16:28 <elod> maybe this should be updated as some patch got merged already
16:16:59 <elod> I think that's it
16:17:04 <gibi> elod: thanks!
16:17:30 <gibi> #topic Sub/related team Highlights
16:17:37 <gibi> API (gmann)
16:17:50 <gmann> progress on deprecated APIs policy work
16:17:52 <gmann> #link https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh-deprecated-apis+(status:open+OR+status:merged)
16:18:07 <gmann> these are ready to review, 2-3 APIs left which i will be completing in this week.
16:18:26 <gmann> i added this in runway queue also
16:18:29 <gibi> ack, I saw that it is now in the runway queue
16:18:51 <gmann> that's all from me today on API
16:19:11 <gibi> thanks
16:19:19 <gibi> Libvirt (bauzas)
16:19:43 <bauzas> nothing to report, two bugs open (I need to do my duty), reviews there
16:19:52 <gibi> OK, thanks
16:19:53 <bauzas> #link https://etherpad.opendev.org/p/nova-libvirt-subteam
16:20:31 <gibi> #topic Stuck Reviews
16:20:38 <gibi> nothing on the agenda
16:20:48 <gibi> is there any review we need to unstuck today?
16:21:53 <gibi> #topic Open discussion
16:22:02 <gibi> (stephenfin) Is there any reason we shouldn't split the code paths for resize and (cold) migrate? https://review.opendev.org/#/c/741624/
16:22:38 <stephenfin> So I was hoping there'd be more people here for this
16:22:48 <gibi> I think the reason is historical
16:23:10 <gibi> but I'm not sure about the impact of untangling that
16:23:26 <gibi> is there any upgrade impact?
16:24:05 <stephenfin> my initial investigation suggests not, assuming we keep things tangled in the RPC API
16:24:06 <gibi> do we also want create a confirm migrate action?
16:24:19 <stephenfin> That's an open too. I'm not sure
16:24:36 <gibi> also we have the VERIFY_RESIZE state for cold migration today too
16:24:49 <stephenfin> I've added a 'server migration confirm' command to OSC, but that's just using the resizeConfirm action
16:25:05 <stephenfin> i.e. it's a mirror of 'server resize confirm'
16:25:37 <gmann> is it just internal code path split or + its usage via API way too ?
16:25:41 <gibi> if we now only do a code refactoring without impacting interface then I think it is OK
16:25:47 <gibi> gmann: ++
16:26:16 <stephenfin> Just internal for now
16:26:17 <stephenfin> So we can reduce the horrific amount of conditional in the affected code paths present right now
16:26:17 <gibi> for the interface impacts we would need a spec anyhow
16:26:33 <gibi> stephenfin: then I'm totally OK to do it
16:26:50 <stephenfin> Sweet. I'll keep working at that patch and others like it so
16:27:00 <stephenfin> Specless BP if there aren't API changed?
16:27:02 <stephenfin> *changes
16:27:12 <gibi> specless bp for tracking, yes please
16:27:15 <stephenfin> cool
16:27:16 <gmann> yeah, for interface it might not be much benefits but doing internal code split will be helpful from complexity and avoid-regression point of view.
16:27:25 <bauzas> I'd opiniate for a spec
16:27:40 <bauzas> because there are RPC implications
16:27:48 <stephenfin> bauzas: No, no RPC changes yet
16:27:58 <bauzas> stephenfin: only in the conductor then ?
16:27:59 <stephenfin> I explicitly want to avoid those _for now_
16:28:06 <stephenfin> Conductor and virt driver
16:28:25 <bauzas> I'd then recommend extreme caution
16:28:29 <stephenfin> virt driver changes just need an email to the list for out-of-tree maintainers (it's not a contract, as dansmith likes to point out)
16:28:47 <bauzas> it would be like changing your electric meter while it's still running
16:29:04 <bauzas> doable but at high risks
16:29:16 <bauzas> and then, if no RPC changes, specless I agree
16:29:25 <stephenfin> Let me investigate things. If it turns out to be riskier than I think so right now, I'll bring this up again and possibly file a spec
16:29:51 <bauzas> *in theory* it's all conditionals
16:30:02 <bauzas> but that's so fuckingly tangled
16:30:14 <bauzas> I do remember mriedem yelling
16:30:17 <stephenfin> Right, that's my point
16:30:18 * gibi approves the bauzas' wording
16:30:20 <gmann> +1
16:30:45 <stephenfin> Unnecessarily so, I'm hoping
16:30:47 <stephenfin> TBD
16:30:56 <gibi> OK I think this is agreed for now
16:31:03 <gibi> anything else for today/
16:31:04 <gibi> ?
16:31:05 <bauzas> I'd at least raise this to operators
16:31:18 <bauzas> like a tl;dr: you could feel the breeze
16:31:30 <bauzas> it's surgery
16:31:39 <stephenfin> Fair point. Let me see what needs to be done
16:31:44 <bauzas> cool
16:31:52 <stephenfin> gibi: not from me
16:32:00 <bauzas> this IMHO would require a decent amount of new methods
16:32:08 <bauzas> and decoupling
16:32:27 <bauzas> but let's figure this out, we have a volunteer for dirty work \o/
16:33:40 <gibi> \o/
16:34:23 <gibi> if nothing else then thank you for joining
16:35:01 <gibi> #endmeeting