16:00:42 <bauzas> #startmeeting nova
16:00:42 <opendevmeet> Meeting started Tue Feb  8 16:00:42 2022 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:42 <opendevmeet> The meeting name has been set to 'nova'
16:00:51 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:56 <gibi> o/
16:00:59 <dansmith> o/
16:01:02 <gmann> o/
16:01:02 <chateaulav> \o
16:01:15 <bauzas> sorry I was late, someone pinged me at house
16:01:23 <elodilles> o/
16:02:19 <bauzas> ok, let's start
16:02:25 <bauzas> #topic Bugs (stuck/critical)
16:02:30 <bauzas> #info One Critical bug
16:02:35 <bauzas> #link https://bugs.launchpad.net/nova/+bug/1959899 this is the critical bug for nova-next
16:02:45 <bauzas> do we want to discuss this one ?
16:03:17 <gibi> my last info
16:03:34 <gibi> that artom and sean-k-mooney figured out that this is a q35 machine type related issue
16:03:46 <gibi> then we turned off the test on master to unblock the gate
16:03:59 <gibi> I don't know if there is any fix in the works
16:04:16 <bauzas> oh shit
16:05:20 <bauzas> ok, so maybe we should put it to High ?
16:05:34 * bauzas looked at the bug
16:05:50 <gibi> yeah we can decrease it to High as the gate is not blocked now
16:05:52 <gibi> as we skip
16:05:56 <bauzas> as this test is executed in other jobs
16:06:06 <sean-k-mooney> we dont have a fix yet
16:06:21 <sean-k-mooney> artom speculated it might be related to a state tracking but with qemu
16:06:27 <bauzas> I'm only afraid of the fact it means we would have problems when upgrading
16:06:31 <sean-k-mooney> that is still pending
16:07:05 <bauzas> sean-k-mooney: at least this is blocking q35 to be the next machine type, right ?
16:07:13 <artom> The only data point I have is that it passed without q35... once
16:07:34 <artom> But it also passed intermittently *with* q35 on other patches
16:07:35 <bauzas> ah, this is different then
16:07:39 <sean-k-mooney> yes so q35 and pc use difffernt hotplug code paths
16:07:42 <artom> So... more testing needed?
16:07:50 <bauzas> I guess
16:07:57 <bauzas> anyway, let's punt the bug report to High
16:08:07 <sean-k-mooney> bauzas: we als think the way the device is presented in teh guest might change based on q35 or pc
16:08:09 <bauzas> but we need to fix this bug
16:08:21 <sean-k-mooney> so we shoudl keep looking into it and try and fix it
16:08:29 <sean-k-mooney> yep
16:08:37 <sean-k-mooney> it may not be fixable in nova
16:08:47 <sean-k-mooney> but we have nto figure that out yet
16:09:02 <opendevreview> Alexey Stupnikov proposed openstack/nova master: Fix clean-up process for aborted queued live migrations  https://review.opendev.org/c/openstack/nova/+/828374
16:09:09 <gibi> artom: this test runs in tempest-integrated-compute job with pc machine type
16:09:19 <gibi> artom: and it appears to be green there
16:10:03 <bauzas> could we create another job for testing ?
16:10:18 <bauzas> non-voting, of course
16:10:20 <sean-k-mooney> this is the qemu bug we think might be relevent https://bugzilla.redhat.com/show_bug.cgi?id=2007129
16:11:17 <sean-k-mooney> bauzas: i htink we have enough test coverage with teh integrated job
16:11:29 <gibi> agree ^
16:11:31 <bauzas> OK
16:11:33 <sean-k-mooney> so i think we can move on for now and just monitor/investigate
16:11:41 <bauzas> cool then, we can moveo n
16:11:45 <bauzas> move on, even
16:11:57 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 39 new untriaged bugs (+0 since the last meeting)
16:12:01 <bauzas> #help Nova bug triage help is appreciated https://wiki.openstack.org/wiki/Nova/BugTriage
16:12:09 <bauzas> I triaged a few evident bugs
16:12:57 <bauzas> #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement
16:13:02 <bauzas> that's it for bugs
16:13:06 <bauzas> any ones to tell ?
16:14:14 <bauzas> looks not
16:14:20 <bauzas> #topic Gate status
16:14:24 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:14:34 <bauzas> we discussed the critical one
16:14:39 <gibi> besides the one we discussed
16:14:39 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status
16:14:48 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:14:58 <gibi> the nova-specs doc build is broken due to sphinx 4.4.0
16:15:04 <gibi> fix is here https://review.opendev.org/c/openstack/nova-specs/+/828368
16:15:20 <gibi> and here https://github.com/sphinx-doc/sphinx/pull/10178 (thanks to stephenfin)
16:15:23 <bauzas> saw it, had no time to vote yet
16:15:34 <bauzas> vote coming up after the meeting
16:15:38 <gibi> cool
16:15:39 <gibi> thanks
16:15:59 <stephenfin> please pile on the latter bug (+1) if you can :)
16:15:59 <gmann> +A, 4.4.0 has caused on ext link other repo too
16:16:16 <gmann> in governance doc etc
16:16:21 <bauzas> damn, you beat me
16:16:26 <gibi> gmann: is there a global requiremnet fix up for it or should I push?
16:16:39 <stephenfin> and indicate on the bug if there are other failures other than nova-specs. Sounds like there are
16:16:49 <gmann> gibi: that was different i fixed few on governance repo but removed ext_link from election repo as thre were many to fix
16:17:18 <gmann> example #link https://review.opendev.org/c/openstack/governance/+/825257
16:17:29 <bauzas> stephenfin: I'm afraid we would need to modify our specs and docs in order to make them compliant with a foreseenable future of sphinx ?
16:17:45 <gmann> but that was for extlink in conf
16:17:47 <stephenfin> I don't think so. I think it's a bug
16:17:49 <sean-k-mooney> i think in this cae there was only 1 duplicate link
16:17:50 <bauzas> stephenfin: or does sphinx team said sorry it was an unwanted regression?
16:17:57 <gibi> gmann: ohh OK, so that is different
16:18:09 <gmann> there were many change in 4.4.0 which broke our existing doc
16:18:11 <stephenfin> doing e.g. [1] style referencing is a perfectly reasonable thing to do
16:18:13 <bauzas> stephenfin: ok, so bug it was, not a feature
16:18:36 <bauzas> stephenfin: we'll propose you a full-time job for fixing our docs then
16:18:40 <stephenfin> Both. It was a feature that was a breaking change
16:18:43 <sean-k-mooney> yep within a singel doc it shoudl be fine
16:18:46 <gibi> sean-k-mooney: nope, there are many, sphinx gave up parsing at the first duplicate
16:18:52 <sean-k-mooney> ah ok
16:19:07 <sean-k-mooney> so the "feature" was treating them a global link targets
16:19:12 <sean-k-mooney> not local to the current doc?
16:19:14 <gibi> sean-k-mooney: something like that
16:19:22 <sean-k-mooney> that would be a problem ya
16:19:48 <stephenfin> shouldn't have happened in minor release or arguably at all. Context in the upstream bug https://github.com/sphinx-doc/sphinx/issues/10177
16:19:58 <bauzas> just to make it clear, that means we have homework before accepting 4.4.x, right?
16:19:58 <sean-k-mooney> ack
16:20:11 <sean-k-mooney> well or we can see if we can get this reverted
16:20:14 <sean-k-mooney> or made configurable
16:20:15 <bauzas> stephenfin: ah I see
16:20:24 <gibi> sean-k-mooney: yepp, stephenfin proposed the revert :)
16:20:42 <sean-k-mooney> if we need too its proably scriptable to make them unique
16:20:55 <sean-k-mooney> but ya lets see what happens with stephenfin pr
16:21:23 <gmann> another gate failure we discussed in QA meeting is about failure in devstack-platform-centos-9-stream job which seems 100 % #link https://zuul.openstack.org/builds?job_name=devstack-platform-centos-9-stream&skip=0
16:21:37 <gmann> rescue server test failing on volume detach #link https://a886e0e70a23f464643f-7cd608bf14cafb686390b86bc06cde2a.ssl.cf1.rackcdn.com/827576/6/check/devstack-platform-centos-9-stream/53de74e/testr_results.html
16:21:57 <gmann> I have not checked log yet, in case anyone aware of it?
16:22:42 <gibi> that feels new
16:22:48 <gibi> at least to me
16:24:11 <gmann> ok, let me see if I get any info in logs and then will report bug
16:24:22 <gibi> thanks
16:24:22 <bauzas> the error seems weird
16:24:59 <bauzas> InvalidVolume
16:25:20 <bauzas> but a timeout
16:25:46 <bauzas> which indicates something bad happening on the cinder side
16:26:50 <gibi> affraid it is libvirt device detach issue again
16:26:51 <gibi> https://zuul.openstack.org/build/3e24d977991d4536b6279afd7f3b5d56/log/controller/logs/screen-n-cpu.txt?severity=4#49433
16:28:21 <bauzas> gibi: on centos then ?
16:28:53 <gibi> for some reason it is hitting only that centos job but hitting it hard
16:29:03 <gmann> yeah
16:29:59 <bauzas> ok, I guess we need to investigate more, next
16:30:07 <bauzas> #topic Release Planning
16:30:12 <bauzas> #link https://releases.openstack.org/yoga/schedule.html#y-ff FeatureFreeze in 2.5 weeks
16:30:17 <bauzas> #link https://etherpad.opendev.org/p/nova-yoga-blueprint-status Etherpad for blueprints tracking
16:30:30 <bauzas> thanks gibi for having made a couple of insighful reviews
16:30:36 <bauzas> I started to review as well
16:31:14 <bauzas> folks, just a reminder to use this etherpad for coordinating review requests and comments
16:31:41 <bauzas> any particular BP someone wanting to address by now ? (provided this is not about asking reviews)
16:32:32 <gmann> added link for policy refresh 2 BP and moved up for review section #link https://etherpad.opendev.org/p/nova-yoga-blueprint-status#L40
16:32:49 <gmann> It is not complete yet, I am working on system_reader conversion
16:33:00 <gmann> but existing patches is up for review
16:33:12 <gmann> dansmith: ^^ I am +2 on your patches for server policy
16:33:17 <opendevreview> Merged openstack/nova-specs master: Avoid Sphinx 4.4.0 to fix specs doc build  https://review.opendev.org/c/openstack/nova-specs/+/828368
16:33:24 <bauzas> gmann: thanks
16:33:36 <dansmith> gmann: ack, I've been wondering when that was going to go
16:33:41 <bauzas> anyone wanting to discuss now about priorities ?
16:33:47 <dansmith> bauzas: want a note on the quotas stuff?
16:33:54 <gmann> dansmith: lot of test to fix so taking time but I am working on remaining policies
16:33:58 <bauzas> dansmith: I started looking at your comment
16:34:07 <bauzas> on the next patch I wanted to review
16:34:22 <dansmith> bauzas: well,
16:34:28 <bauzas> dansmith: those are reasonable concerns but I started reviewing this patch too
16:34:41 <dansmith> melwitt and I discussed a few refactoring changes
16:34:50 <dansmith> after my first review, and we're still working on hammering those out
16:35:20 <bauzas> dansmith: given the series, do you feel she needs to rebase his change or can she work on a follow-up patch ?
16:35:30 <bauzas> (well, can ping melwitt actually for the answer)
16:35:33 <dansmith> I'm working on the rebase now,
16:35:44 <dansmith> but yeah, we're actually going to drop the latest PS, back to the previous and iterate from there
16:35:52 <dansmith> I'm almost done with that actually,
16:36:03 <dansmith> but want to sync with her when she's around this morning before I push that major change up :)
16:36:14 <bauzas> dansmith: ok, then I'll look at other bps tonight and I'll look back at the unified limits one tomorrow
16:36:28 <bauzas> thanks for the notice
16:36:56 <dansmith> aye
16:37:14 <bauzas> fwiw, I thought about a simple thing for giving ourselves visibility during the last 3-week sprint
16:37:46 <bauzas> if cores don't disagree, I'd recommend cores to mark their IRC nicks on the BPs they'd like to review this week
16:37:52 <bauzas> no obligation
16:38:07 <bauzas> just a matter of giving a bit of visibility for the people who want
16:38:37 <bauzas> feel it like it's runways or whatever name it is
16:39:12 <bauzas> it's just about adding a bullet point below each blueprint on the blueprint etherpad for people willing to mark their names
16:39:30 <bauzas> another option could be the Review-Priority flag :)
16:40:11 <bauzas> what folks think about it ? maybe this is a bit early ?
16:40:35 <gibi> I can do both
16:41:38 <gmann> either is fine, I will review tenant-id series this week
16:41:38 <bauzas> I don't want to ask for duplicate things
16:42:12 <bauzas> I feel we can use the review-prio flag then
16:42:24 <bauzas> but that means we need to clean it up first
16:43:41 <gibi> there is not much marked with review priority at the moment
16:43:56 <bauzas> ok, then let's jump straight to the next topîc
16:44:22 <bauzas> #topic Review priorities
16:44:28 <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
16:45:02 <gibi> pack and spread, remote-manged and unified limits are all has core review attention so they are good having the prio label
16:45:19 <bauzas> right
16:45:24 <gibi> the other patches in that list feels less important now
16:45:58 <bauzas> pack-n-spread doesn't match a bp
16:46:35 <bauzas> but I'm ok with treating it as some kind of feature request
16:46:50 <bauzas> anyway, let's overthink that
16:47:24 <bauzas> sean-k-mooney: can you drop r-p flag on https://review.opendev.org/c/openstack/os-vif/+/765912 and https://review.opendev.org/c/openstack/os-vif/+/765970
16:47:41 <bauzas> those are old patches that fail CI, hence meaningless to be 'priorities'
16:48:17 <sean-k-mooney> yes
16:48:20 <bauzas> https://review.opendev.org/c/openstack/os-resource-classes/+/819207 will be tonight's priority for me
16:48:29 <bauzas> so hopefully we could merge it
16:48:46 <sean-k-mooney> done
16:48:56 <bauzas> that would leave the other changes having r-p matching blueprints
16:49:00 <opendevreview> Dmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0  https://review.opendev.org/c/openstack/nova/+/826675
16:49:01 <opendevreview> Dmitrii Shcherbakov proposed openstack/nova master: Add supports_remote_managed_ports capability  https://review.opendev.org/c/openstack/nova/+/827839
16:49:01 <opendevreview> Dmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early  https://review.opendev.org/c/openstack/nova/+/812111
16:49:02 <opendevreview> Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_REMOTE_MANAGED  https://review.opendev.org/c/openstack/nova/+/824835
16:50:22 <bauzas> let's finish this discussion next week and make the r-p flag be the tool for coordinating review priorities for this feature freeze
16:50:34 <bauzas> agreed ?
16:50:48 <gibi> works for me
16:51:22 <bauzas> anyway, moving on, time is flying
16:51:37 <bauzas> #topic Stable Branches
16:51:41 <bauzas> elodilles: your turn
16:51:50 <elodilles> #info stable/queens and stable/pike gates are blocked by docs job (details: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027106.html )
16:52:17 <elodilles> i'm planning to propose some patch to unblock the gate
16:52:48 <elodilles> probably just removing the doc job (if i cannot make the sphinx job to work)
16:52:57 <elodilles> #info other stable gates are not blocked, but hard to merge patches due to intermittent failures
16:53:11 <elodilles> probably Lee's patches, that would disable guest's apic in CI, could eliminate some part of the problem for wallaby and older branches: https://review.opendev.org/q/topic:workaround-disable-apic
16:53:36 <elodilles> so if any stable core has some time to review ^^^ that would be nice
16:53:57 <elodilles> and that's all i think :X
16:54:01 <dmitriis> sean-k-mooney, gibi: resubmitted with the VNIC type change and other stuff included.
16:54:18 <bauzas> dmitriis: we're in a meeting, please
16:54:31 <bauzas> elodilles: thanks elod
16:54:31 <dmitriis> bauzas: apologies
16:54:55 <bauzas> dmitriis: no worries, that's one of the issues we have with meetings running at the existing channel
16:55:08 <bauzas> elodilles: will promise a few reviews if I have time
16:55:12 <bauzas> last topic
16:55:24 <bauzas> #topic Open discussion
16:55:24 <elodilles> bauzas: thanks in advance! \o/
16:55:34 <bauzas> (skipping the subteam topic meaningless)
16:55:42 <bauzas> Z release name should be known in 1 or 2 weeks
16:55:58 <bauzas> let's hold until we know which Zen or Zombie we'll have
16:56:37 * bauzas imagines the Foundation lawyers scratching their heads trying to guess whether Zen is trademarked
16:57:08 <bauzas> not saying some chip company used that word
16:57:13 <DHilsbos> Maybe they'll meditate on it...
16:57:27 <bauzas> anyway
16:57:37 <bauzas> any other business before we close ?
16:58:10 <DHilsbos> Is now a good time to ask for assistance with a feature for Z?
16:58:27 <bauzas> DHilsbos: nothing prevents you to get assistance
16:58:37 <bauzas> DHilsbos: this is just a matter of priorities
16:59:00 <DHilsbos> My question is more along the lines of process.
16:59:02 <bauzas> the Z specs repo isn't yet created but you can work on WIP patchers
16:59:06 <bauzas> patches*
16:59:22 <bauzas> DHilsbos: then, let's close this meeting and we'll discuss this right after
16:59:32 <bauzas> thanks all
16:59:34 <bauzas> #endmeeting