| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-16 | |||
| 10:15:08 | bauzas | I should create bugfixes with the same gerrit topic than the feature | |
| 10:15:08 | gibi | no worries I made my one fair share of mess in it | |
| 10:15:26 | bauzas | instead of using the bug number topic | |
| 10:15:40 | gibi | I prefer bug number topics | |
| 10:15:57 | bauzas | yeah I understand | |
| 10:16:02 | bauzas | this is a tradeoff | |
| 10:16:18 | bauzas | then I should mention some changeid in the commit msg, so gerrit could possibly link it | |
| 10:17:02 | bauzas | tbc, I don't trust my memory and that one is another evidence | |
| 10:17:38 | bauzas | the series was small and there were only two bugfixes, despite that I failed to remember about that | |
| 10:17:52 | bauzas | my brain is so fcked | |
| 10:19:43 | opendevreview | Merged openstack/nova stable/zed: Do not untrack resources of a server being unshelved https://review.opendev.org/c/openstack/nova/+/904375 | |
| 10:24:40 | gibi | bauzas: I don't know how to avoid this via automation | |
| 10:25:22 | gibi | elodilles: do I need to backport a revert, or I can do a revert on the stable branch independently of a revert on master? | |
| 10:26:55 | gibi | elodilles: i.e can I do git revert on stable, or do I need to do git cherry-pick -x on the revert commit from master to stable? | |
| 10:32:58 | gibi | elodilles: I will go with the cherry-pick as I affraid of the stable backport script will not allow an independent revert :/ | |
| 10:33:30 | Uggla | @bauzas you said we store only the shortname for compute name in the db right ? | |
| 10:33:37 | bauzas | nope | |
| 10:33:49 | bauzas | I said we store what libvirt gives us | |
| 10:34:24 | bauzas | if after an upgrade libvirt is giving us something else, then now with 2023.1 we fail | |
| 10:34:56 | bauzas | previously, we were blindly recreating duplicate resource providers leading to inconsistencies | |
| 10:35:43 | Uggla | yep it means that when the compute was registered he got the shortname and after upgrade or something else libvirt supply the fqdn. | |
| 10:36:21 | Uggla | @bauzas, note I understand the patch goal. | |
| 10:47:33 | elodilles | gibi: we usually simply backport reverts if it is needed all the way from master branch to multiple stable branches. if only needed for some older branches, then [stable-only] is fine. and of course if the bug is superimportant highly critical ultimate fix is needed, then also mark them as [stable-only] and merge them parallel in all stable branches :) | |
| 10:48:17 | elodilles | these are my memories from the past ^^^ :) | |
| 10:49:56 | gibi | not super critical | |
| 10:50:09 | gibi | going with the cherry-picks | |
| 10:50:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: Revert "[pwmgmt]ignore missin governor when cpu_state used" https://review.opendev.org/c/openstack/nova/+/905671 | |
| 10:51:02 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: Revert "[pwmgmt]ignore missin governor when cpu_state used" https://review.opendev.org/c/openstack/nova/+/905672 | |
| 10:51:03 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: cpu: make governors to be optional https://review.opendev.org/c/openstack/nova/+/905673 | |
| 10:51:16 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.1: Revert "[pwmgmt]ignore missin governor when cpu_state used" https://review.opendev.org/c/openstack/nova/+/905674 | |
| 10:51:17 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.1: cpu: fix the privsep issue when offlining the cpu https://review.opendev.org/c/openstack/nova/+/905675 | |
| 10:51:18 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.1: cpu: make governors to be optional https://review.opendev.org/c/openstack/nova/+/905676 | |
| 10:51:36 | gibi | elodilles, bauzas, sean-k-mooney ^^ | |
| 10:52:52 | gibi | it is complicated as on master we only need to revert, on 2023.2 we revert and backport the proper fix from master, on 2023.1 we revert, backport a related fix from 2023.2 and then backport the original good fix from master->2023.2 | |
| 10:52:57 | bauzas | gibi: ++ | |
| 11:06:59 | Uggla | do we agree that there is no "proper" way to rename a compute node. And that we need to stop the compute service, remove the compute from the configuration, and restart the compute to have it registered with the new name ? | |
| 11:07:00 | zigo | kashyap: For Ubuntu stuff, please ask jamespage or coreycb_ please, I have no idea about #ubuntu-kernel on Libera at all, and I honestly don't know anything about the Ubuntu kernel in general. | |
| 11:07:46 | kashyap | zigo: Thans for the contacts :) In the past I had a couple of chats on #ubuntu-kernel, while it used to be still on FN :) | |
| 11:12:15 | jamespage | kashyap: lacking some context - just reading the etherpad linked above somewhere | |
| 11:12:59 | kashyap | jamespage: Hi, I didn't ping you with full context yet. :) | |
| 11:13:31 | kashyap | jamespage: It's about a certain class of kernel panics we're seeing in the upstream CI. An example: https://bugs.launchpad.net/nova/+bug/2018612 | |
| 11:16:07 | kashyap | Admittedly (a) these are difficult to reproduce locally; and (b) distro kernel maintainers (understandably) might not have time to debug "unsupported distros" (as evidenced above). | |
| 11:16:30 | kashyap | I need to step out to get some lunch; need to drop here. (I don't have an IRC bouncer anymore) | |
| 11:16:36 | jamespage | ack | |
| 11:19:41 | auniyal | in cinderfixture for attachment_update https://review.opendev.org/c/openstack/nova/+/658904/4/nova/tests/fixtures.py#1997 | |
| 11:19:41 | auniyal | why this volume_id must be self.MULTIATTACH_VOL (the sent volume is a dynamically created new volume, ) MULTIATTACH_VOL is a contant | |
| 11:19:53 | auniyal | gibi ^ | |
| 11:23:44 | auniyal | I am trying to to create a server from snapshot-image and while updating attachment in cinder its failing at this step - can someone please tell why this is wrtten and what I can I do to use MULTIATTACH_VOL. | |
| 11:24:04 | auniyal | so attachment can get updated | |
| 11:33:05 | opendevreview | Merged openstack/nova master: Adds server show in helpers https://review.opendev.org/c/openstack/nova/+/893584 | |
| 12:00:36 | opendevreview | Amit Uniyal proposed openstack/nova master: Fixes bug 2048184 https://review.opendev.org/c/openstack/nova/+/904817 | |
| 12:00:37 | opendevreview | Amit Uniyal proposed openstack/nova master: Updates glance fixture for create image https://review.opendev.org/c/openstack/nova/+/905684 | |
| 12:00:37 | opendevreview | Amit Uniyal proposed openstack/nova master: WIP: snapshot tests https://review.opendev.org/c/openstack/nova/+/905685 | |
| 13:36:04 | bauzas | Uggla: in our OSP product, we have some solution for renaming a compute by scaling in and the out the computes | |
| 14:42:24 | SvenKieske | Hey, has anyone ever thought about enabling "core scheduling" support by default? It's in libvirt since v8.9.0 but I can't find any information regarding openstack implementation status: https://www.libvirt.org/news.html#v8-9-0-2022-11-01 | |
| 14:46:58 | SvenKieske | when searching for this in nova I also found this gem, which seems not to be tracked anymore (last activity 2019, but bug was never closed): https://bugs.launchpad.net/nova/+bug/1417975 | |
| 14:49:24 | opendevreview | Amit Uniyal proposed openstack/nova master: WIP: snapshot tests https://review.opendev.org/c/openstack/nova/+/905685 | |
| 14:56:09 | opendevreview | Amit Uniyal proposed openstack/nova master: Updates glance fixture for create image https://review.opendev.org/c/openstack/nova/+/905684 | |
| 14:56:10 | opendevreview | Amit Uniyal proposed openstack/nova master: Fixes bug 2048184 https://review.opendev.org/c/openstack/nova/+/904817 | |
| 14:56:10 | opendevreview | Amit Uniyal proposed openstack/nova master: WIP: snapshot tests https://review.opendev.org/c/openstack/nova/+/905685 | |
| 15:12:02 | bauzas | SvenKieske: that sounds a new feature request, if you want to use it with nova | |
| 15:13:18 | gibi | dansmith melwitt bauzas : a fresh kernel panic on master https://review.opendev.org/c/openstack/nova/+/905671 | |
| 15:23:28 | dansmith | gibi: that's similar to the one that we opened against the ubuntu team and they asked us to repro on a newer kernel, so that's ... "good" | |
| 15:31:49 | SvenKieske | bauzas: yeah sure, I'm just a little baffled that I seem to be the first person to mention this feature request, as this is a rather useful feature, from a security perspective. | |
| 15:47:10 | kashyap | gibi: Hi, dansmith tells me you've ran into another kernel panic. Got a log link? | |
| 15:47:25 | dansmith | kashyap: https://review.opendev.org/c/openstack/nova/+/905671 | |
| 15:48:01 | dansmith | kashyap: also for future reference: https://meetings.opendev.org/irclogs/ | |
| 15:48:20 | kashyap | dansmith: Hi; thanks! | |
| 15:48:43 | kashyap | dansmith: Oh, yeah; I know we log upstream stuff; forgot for a min :) | |
| 15:48:59 | dansmith | oh, okay | |
| 15:49:01 | kashyap | Now the challenge is find the elusive local reproducer :-( | |
| 15:49:27 | kashyap | Interesting, this was discovered by a power-management related patch | |
| 15:50:04 | dansmith | I doubt it's related, and I also doubt we're going to find a local reproducer | |
| 15:52:09 | gibi | kashyap: power management is disable by default in our upstream CI | |
| 15:52:19 | kashyap | Hm, I see. | |
| 15:52:31 | gibi | so the patch itself is not related | |
| 15:53:50 | kashyap | dansmith: Hm, if we can't figure out a way get a local reproducer, it throws a wrench in our communication with kernel maintainers (whether it be distro or upstream). I'm sure you know this | |
| 15:54:09 | kashyap | I'm wondering how we can unjam this "deadlock" situation. | |
| 15:54:38 | dansmith | there's still information in the stack traces to provide hints on where to go from here | |
| 15:55:19 | bauzas | nova meeting in 5 mins | |
| 15:55:23 | bauzas | *here | |
| 15:55:29 | dansmith | and also, kernel developers are (IME) used to working on issues they can't reproduce because they're related to hardware and/or deadlocks where we can't get forensics out | |
| 15:56:28 | dansmith | a kernel developer might also have a better idea about how to force a repro from the details of what was happening when it faulted | |
| 15:57:43 | kashyap | dansmith: Yeah; that's a fair point; at least _some_ of the traces should lead us somewhere | |
| 15:59:14 | kashyap | And to your previous point, from a recent experience one kernel trace, I did see at least one kernel maintainer immediately say "it's a known issue due to a hardware bug" | |
| 15:59:20 | dansmith | it's also in very early boot of a kernel and userspace they have good access to | |
| 16:00:02 | bauzas | #startmeeting nova | |
| 16:00:02 | opendevmeet | Meeting started Tue Jan 16 16:00:02 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:02 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:02 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:23 | elodilles | o/ | |
| 16:00:31 | grandchild | o/ | |
| 16:00:37 | bauzas | heya | |
| 16:00:41 | dansmith | o/ (kinda) | |
| 16:00:44 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:00:52 | bauzas | let's try to have a short meeting | |
| 16:01:02 | bauzas | some folks have another meeting in 15 mins | |
| 16:01:07 | bauzas | #topic Bugs (stuck/critical) | |
| 16:01:11 | bauzas | #info No Critical bug | |
| 16:01:15 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 46 new untriaged bugs (+3 since the last meeting) | |