Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-01-16
10:14:23 bauzas doh
10:14:40 bauzas gibi: apologies for the mess
10:15:08 gibi no worries I made my one fair share of mess in it
10:15:08 bauzas I should create bugfixes with the same gerrit topic than the feature
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 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:41 auniyal in cinderfixture for attachment_update https://review.opendev.org/c/openstack/nova/+/658904/4/nova/tests/fixtures.py#1997
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: WIP: snapshot tests https://review.opendev.org/c/openstack/nova/+/905685
12:00:37 opendevreview Amit Uniyal proposed openstack/nova master: Updates glance fixture for create image https://review.opendev.org/c/openstack/nova/+/905684
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: WIP: snapshot tests https://review.opendev.org/c/openstack/nova/+/905685
14:56:10 opendevreview Amit Uniyal proposed openstack/nova master: Fixes bug 2048184 https://review.opendev.org/c/openstack/nova/+/904817
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 opendevmeet The meeting name has been set to 'nova'
16:00:02 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
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 bauzas #startmeeting 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)

Earlier   Later