| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-15 | |||
| 16:37:39 | artom | Anecdotally it seems that we do? But as I said, no hard data | |
| 16:37:53 | gmann | elodilles: is this ready? https://review.opendev.org/c/openstack/devstack/+/805632 | |
| 16:37:59 | gmann | I can check devstack backports | |
| 16:38:33 | elodilles | gmann: i think yes, we can remove the Workflow label *when* the nova part has merged | |
| 16:38:48 | elodilles | gmann: i'll ping you | |
| 16:39:02 | artom | And yeah, if it's fixed by the apic workaround we can abandon | |
| 16:39:02 | gmann | elodilles: ack, thanks | |
| 16:39:12 | elodilles | gmann: thanks too :) | |
| 16:40:27 | bauzas | ok, done with that ? | |
| 16:40:36 | elodilles | sorry, yes | |
| 16:40:41 | elodilles | i don't have any other update | |
| 16:41:39 | bauzas | cool | |
| 16:41:41 | bauzas | , | |
| 16:41:42 | artom | elodilles, it's most likely related to our volume detachment woes | |
| 16:41:55 | artom | So I'm like 90% sure the apic workaround will make it go away | |
| 16:42:13 | bauzas | #topic Open discussion | |
| 16:42:17 | elodilles | artom: ack | |
| 16:42:22 | bauzas | Z release name should be known in 1 week-ish | |
| 16:42:30 | bauzas | that's it, we exhausted the agenda | |
| 16:42:30 | artom | Err, it's official Zed now? | |
| 16:42:49 | artom | And I have a last minute thing for the open discussion | |
| 16:43:04 | gmann | yes, its final. I will reply in email soon after meeting or so | |
| 16:43:06 | bauzas | oh damn, missed it | |
| 16:43:13 | bauzas | there it goes | |
| 16:43:22 | gmann | I do not think we can change it at this stage | |
| 16:43:23 | bauzas | #info Next release is named "Zed" | |
| 16:43:28 | gibi | Zed, boring, but at least short. | |
| 16:43:40 | artom | Also, name of the, err, chopper dude in Pul Fiction | |
| 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? | |