| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-15 | |||
| 16:43:43 | artom | *Pulp Fiction | |
| 16:43:52 | gmann | yeah, i was hoping zombie but not sure why i did not pass trademark checks | |
| 16:43:58 | gibi | we could have a screening of that in Berlin :) | |
| 16:44:03 | gmann | *it did not | |
| 16:44:31 | bauzas | oh man | |
| 16:44:46 | bauzas | indeed, I remember the Zed character | |
| 16:45:06 | bauzas | anyway, will propose a patch for creating the zed directory against nova-specs | |
| 16:45:20 | bauzas | we can rename it if needed but I guess ship has sailed | |
| 16:45:57 | bauzas | for Zen, it was obvious | |
| 16:46:14 | bauzas | for Zeta, nothing comes out of my mind | |
| 16:46:28 | artom | Aren't they a violent gang somewhere? | |
| 16:46:32 | bauzas | (fwiw, Zombie was a pun when I proposed it) | |
| 16:46:43 | artom | Yup https://en.wikipedia.org/wiki/Los_Zetas | |
| 16:46:43 | bauzas | because everybody else is saying OpenStack is dead | |
| 16:46:51 | gmann | true | |
| 16:47:02 | bauzas | I just wanted to tell that if OpenStack is dead, it's still alive | |
| 16:47:15 | bauzas | hence the pun | |
| 16:47:27 | bauzas | anyway, we're diverting | |
| 16:47:46 | bauzas | #action to propose a patch against nova-specs for creating the "zed" directory | |
| 16:48:27 | bauzas | artom: you had an item | |
| 16:48:50 | artom | Yeah, so this is last minute, but I want to start socializing this strawman idea | |
| 16:49:02 | artom | The tripleo folks often have bugs that block their CI | |
| 16:49:21 | artom | Sometimes those are Nova folks, or they initially think they're Nova bugs | |
| 16:49:30 | artom | The current process for those is... well, bad | |
| 16:49:50 | bauzas | having a boot failure isn't always due to Nova, y'know :) | |
| 16:50:06 | artom | I know, I Know | |
| 16:50:10 | artom | But like the volume detach issues | |
| 16:50:16 | artom | It blocked us, it blocked them as well | |
| 16:50:53 | artom | What they currently do is file bugs against the *tripleo* component, and get us, via a *downstream internal Red Hat call*, to look at those they think are Nova | |
| 16:51:41 | artom | Would there be willingness here in this community to get bugs filed againt *Nova*, with the gate-blocker tag, and to leverage the existing upstream bug triage process (however light it is)? | |
| 16:52:15 | bauzas | anyone can report a bug against nova :) | |
| 16:52:25 | bauzas | actually this is a good point | |
| 16:52:35 | gibi | artom: I'm OK with that, if they take the time to point to the nova part of the tripleo problem as I'm not familiar with tripelo | |
| 16:52:35 | bauzas | I won't refrain anyone to do this | |
| 16:52:46 | bauzas | the only problem is the triage capacity | |
| 16:52:54 | bauzas | I do it when I have time | |
| 16:52:55 | artom | Their expectation would be, as it's a gate-blocker for them, that we would prioritize triaging those, similar to how Neutron would do it for our gate blocker, for example | |
| 16:53:15 | artom | But yeah, we can definitely ask for high bug report quality | |
| 16:53:22 | bauzas | artom: I'd say it's worth adding nova as an impacted project, I agree | |
| 16:53:25 | gibi | artom: if they need priority I suggest to ping us with the gate bug here on irc | |
| 16:53:31 | bauzas | gibi: exactly | |
| 16:53:36 | bauzas | upstream first | |
| 16:53:45 | bauzas | file a LP bug, go shout the folks on IRC | |
| 16:53:50 | bauzas | and we'll triage it | |
| 16:54:03 | artom | ooo has a very... "flexible" concept of upstream/downstream | |
| 16:54:09 | gibi | :) | |
| 16:54:10 | artom | Since they're all Red Hat folks, essentially | |
| 16:54:13 | bauzas | expect the nova folks to magically triage this LP bug isn't exactly a good recipe for success | |
| 16:55:01 | bauzas | anyway, | |
| 16:55:19 | artom | OK, so my takeaway would be "yes, do it upstream, but high quality bug reports please" | |
| 16:55:19 | bauzas | artom: feel free to tell them to file a launchpad bug against nova and ask us on IRC to look at it | |
| 16:55:27 | bauzas | artom: yes | |
| 16:55:31 | bauzas | 100% yes | |
| 16:55:33 | artom | Awesome, much thanks | |
| 16:55:34 | gibi | +1 | |
| 16:56:00 | bauzas | artom: appreciated the thought | |
| 16:56:19 | bauzas | any last item to discuss before I call it a wrap ? | |
| 16:56:47 | bauzas | looks not | |
| 16:56:50 | bauzas | thanks all | |
| 16:56:53 | bauzas | #endmeeting | |
| 16:56:53 | opendevmeet | Meeting ended Tue Feb 15 16:56:53 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:56:53 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-02-15-16.00.html | |
| 16:56:53 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-02-15-16.00.txt | |
| 16:56:53 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-02-15-16.00.log.html | |
| 16:58:13 | gibi | bauzas: thanks! | |
| 16:59:36 | elodilles | artom: about the test_tagged volume detach issue: in wallaby there is a different problem as i remember (yes, though, *everything* ends up in volume detach timeouts :)) | |
| 17:00:12 | elodilles | artom: in wallaby the volume detach issue is mostly because some kernel panic in cirros | |
| 17:01:10 | elodilles | artom: that's why there is the possibility to use in wallaby the libvirt_disable_apic workaround | |
| 17:03:03 | artom | elodilles, cool, cool - tbh I didn't look into it in a lot of depth, my hope is that merging the apic workaround will make it go away | |
| 17:05:42 | elodilles | artom: in wallaby the 'volume detach' failures have significant higher numbers than in xena, because the workaround is there in xena for some time already. at least that is what i understood / saw so far | |
| 17:06:28 | elodilles | so i think the apic workaround makes the wallaby gate more stable | |
| 17:06:31 | artom | Oh, wait, I said wallaby, didn't I? | |
| 17:06:38 | elodilles | hopefully we will see that | |
| 17:06:42 | artom | *facepalm* https://review.opendev.org/c/openstack/nova/+/828542 is against Xena | |
| 17:06:55 | artom | So wth's going on? | |
| 17:08:42 | elodilles | actually, xena is less impacted with the volume detach issue as far as i know | |
| 17:09:17 | artom | Yeah, so I'm confused | |
| 17:09:39 | elodilles | https://zuul.opendev.org/t/openstack/builds?job_name=nova-next&project=openstack%2Fnova&branch=stable%2Fxena&skip=0 | |
| 17:13:35 | artom | I mean, that's still 25% failure rate | |
| 17:13:41 | artom | Roughly | |
| 17:14:56 | elodilles | and now imagine that in wallaby it's worse :) | |
| 17:19:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248 | |
| 17:26:30 | opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Create specs directory for Zed https://review.opendev.org/c/openstack/nova-specs/+/829385 | |
| 17:26:53 | bauzas | gibi: sean-k-mooney: gmann: zed directory created ^ | |
| 17:27:29 | gibi | bauzas: cool, will check | |
| 17:28:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: trigger nova tests with the neutron fix included https://review.opendev.org/c/openstack/nova/+/829386 | |
| 17:35:15 | gmann | bauzas: thanks, will check | |
| 18:21:38 | gmann | dansmith: rbac changes are ready for review, I am +2 on your patches and pushed other policy change on top of it. I am left with couple of patches including releasenotes etc which I am working in parallel https://review.opendev.org/q/topic:bp%252Fpolicy-defaults-refresh-2 | |
| 18:23:50 | dansmith | gmann: ack, is there any hold up on my patch at the bottom? | |
| 18:24:49 | gmann | dansmith: no, all good except one comment for testing PROJECT_ADMIN for all-tenants APIs which I have pushed as separate patch in that series | |
| 18:50:33 | spatel | My vm stuck in bad state because we were running load-test now its not responding to virsh console and also not letting me reboot that VM. any other way i can force reboot vm without destroy? | |
| 18:51:07 | spatel | I have tried virsh shutdown 6 --mode acpi and signal but still no luck | |
| 19:03:14 | spatel | nevermind virsh destroy works | |
| 19:47:26 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015 | |
| 19:47:27 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add healthcheck manager to manager base https://review.opendev.org/c/openstack/nova/+/827844 | |
| 21:41:37 | opendevreview | Merged openstack/nova master: Move 'hw:pmu', 'hw_pmu' parsing to nova.virt.hardware https://review.opendev.org/c/openstack/nova/+/792364 | |
| 21:59:21 | opendevreview | melanie witt proposed openstack/nova-specs master: Amend unified limits spec to explain "API limit" enforcement https://review.opendev.org/c/openstack/nova-specs/+/829413 | |
| 22:27:52 | opendevreview | melanie witt proposed openstack/nova-specs master: Amend unified limits spec to explain "API limit" enforcement https://review.opendev.org/c/openstack/nova-specs/+/829413 | |
| #openstack-nova - 2022-02-16 | |||
| 02:51:03 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add healthcheck tracker to nova context https://review.opendev.org/c/openstack/nova/+/829468 | |
| 02:51:03 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add healthcheck utils and constants https://review.opendev.org/c/openstack/nova/+/829469 | |