Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-12-01
16:44:30 sean-k-mooney i did
16:44:42 sean-k-mooney but i dont agree with everything
16:44:57 sean-k-mooney i belvie we shoudl be regenergatin the xml without lookign at the exsitng xml
16:45:04 bauzas can we still send it to the gate then ?
16:45:05 sean-k-mooney for both hard-reboot and live migrate
16:45:39 sean-k-mooney i see the current propoal to pin it as a an issue for day2 operations and posisbel security updates if the device path ever change
16:46:08 tkajinam ok so you are mostly on the same side as Uggla.
16:46:10 sean-k-mooney so to me that part is compliecating the propsoal by requiring extra code to maintain the definaiton and complicating upgrades
16:46:16 sean-k-mooney yes
16:46:27 sean-k-mooney i suggested we move forward and revisit in the code review
16:46:36 sean-k-mooney im not going to block on this point either way
16:46:48 sean-k-mooney btu i dont think the curernt proposal s the right longterm choice
16:46:56 tkajinam yeah
16:47:11 tkajinam let's continue the discussion in the actual code review.
16:47:42 Uggla yep I think we can progress anyway.
16:48:08 gibi I don't see dansmith around but based on his review comment he would disagree with always triggering firmware re-select at hard reboot
16:48:42 bauzas yup and I agree with him
16:48:58 bauzas that's why tkajinam said this for both of the actions
16:49:07 dansmith sorry, still catching up
16:50:27 dansmith I don't understand the day2 maintenance issue -- we're currently hard-coding the value into the xml today, correct?
16:51:08 sean-k-mooney we do yes which mean we somethime dont find the correct firmware blob and or need to symlink files if they move
16:51:08 dansmith so all I'm proposing is we don't suddenly change that for any instances due to an operation that a user or operator would not expect could fundamentally and invisibly change the configuration/behavior of the instance
16:51:43 dansmith right, but if the guest has booted, then it's right.. I just don't think changing it on a working guest without some understanding of what's going on makes sense
16:51:44 sean-k-mooney we had a regression in rhel 9 which they fixed but we were broken by a chagne like that
16:52:00 dansmith sure, and letting libvirt pick going forward is the solution there
16:52:20 sean-k-mooney right but the curernt propaly mean that does nto happen until the vm is mvoed
16:52:36 dansmith yep, understood
16:52:36 sean-k-mooney which is a porblem if you do inplace upgrades
16:52:44 sean-k-mooney as i said my prefernce is to regenreated it
16:52:50 sean-k-mooney but i dont object to the current proposal
16:53:26 sean-k-mooney in most case peopel are going to cold/live migrate for disto changes so i think for the most part we are ok
16:53:33 dansmith I'm not majorly opposed to regen all the time either, I just think it's the less-safe option
16:53:47 dansmith I thought the discussion at PTG landed on just doing the safe thing
16:54:14 sean-k-mooney so for now the proposal say "we check the old xml and keep it the same if the xml exist"
16:54:34 sean-k-mooney so im ok with moving forward with that and we can disucss more in the impelation if that what we want ot keep
16:55:08 sean-k-mooney i dont think i was able to attend the ptg session so i dont know the geneal outcome of that
16:55:35 sean-k-mooney but if that was the general feeling cool
16:56:50 Uggla ok
16:57:01 Uggla something else to discuss ?
16:57:15 kgube Hi, just wanted to mention again that I rewrote my spec to address the input from the the PTG, and I would be happy to get any feedback on it: https://review.opendev.org/c/openstack/nova-specs/+/949504
16:58:52 sean-k-mooney kgube: its been a while but all the cinder bits are in placean right and you need the nova aprt to be added with teh call back to cinder before the end to end fucntionality works
16:59:44 sean-k-mooney kgube: i belive there was a quition on the cidner side about how long to wiat for nova is that still an open?
17:00:33 sean-k-mooney ill admin i have not looked at your spec slicne last cycle so perhaps that already captured.
17:01:10 kgube sean-k-mooney: i have had to rewrite it significantly
17:01:47 sean-k-mooney ok so we shoudl read it fresh rather then a repoposal
17:02:19 kgube sean-k-mooney: there was some fundamental critique on using the external server event to trigger the extend operatoion
17:02:39 kgube so it now it proposes a new API
17:03:02 kgube for that purpose. So yes, it's basically a new spec.
17:04:28 sean-k-mooney ok soyour mirroing the exsitng os-assisted-volume-snapshots aprpoch aby adding /assisted-volume-extend
17:04:47 kgube yes
17:04:52 sean-k-mooney i tought we dicsued that last cycle by maybe i imgangied that
17:05:07 sean-k-mooney i dont know if other have had a change to look at it or have any questions?
17:05:15 sean-k-mooney we are over time for the meeting
17:06:06 Uggla yep, we need to move on.
17:06:22 Uggla #topic Bug scrubbing
17:06:22 sean-k-mooney skiming it the new spec seam sto elimianate a rondtrip to cinder and a race condtion so over all it sound liek an improvmeent
17:06:35 Uggla #info up to 199 (+1)
17:06:41 Uggla #link: https://etherpad.opendev.org/p/nova-bug-triage-roster
17:06:49 Uggla #info 2 bugs assigned to each volunteer.
17:07:42 Uggla so we can start to deal again with all these open bugs.
17:07:51 Uggla Thanks for the volunteers btw.
17:08:13 Uggla As mentioned we are over time, so time to close.
17:08:24 Uggla Thanks for joining this meeting. Have a nice day/evening.
17:08:28 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-12-01-16.04.log.html
17:08:28 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-12-01-16.04.txt
17:08:28 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-12-01-16.04.html
17:08:28 opendevmeet Meeting ended Mon Dec 1 17:08:28 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:08:28 Uggla #endmeeting
17:08:34 elodilles thanks o/
17:10:08 tkajinam thanks !
17:30:35 gibi Uggla: thanks. I will check the bugs assigned for triage o/
17:45:18 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load ssm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131
17:45:19 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use firmeare auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132
17:58:05 opendevreview Takashi Kajinami proposed openstack/nova master: Use consistent program name for wsgi scripts and entry points https://review.opendev.org/c/openstack/nova/+/942605
#openstack-nova - 2025-12-02
02:15:33 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load loader and nvram from xml https://review.opendev.org/c/openstack/nova/+/969086
02:15:34 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use firmeare auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132
02:15:34 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load ssm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131
04:55:30 opendevreview Ghanshyam proposed openstack/nova-specs master: Add backlog spec for Graceful shutodwn of nova services https://review.opendev.org/c/openstack/nova-specs/+/967469
04:58:26 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use firmeare auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132
08:02:14 opendevreview Ahmad Hassan proposed openstack/nova-specs master: Offline VM migration using https https://review.opendev.org/c/openstack/nova-specs/+/964444
08:03:16 opendevreview Ahmad Hassan proposed openstack/nova-specs master: Cold VM migration using Webdav https https://review.opendev.org/c/openstack/nova-specs/+/964444
08:10:05 DominikDanelski[m] Hi, it's my first patch to the self-filled bug report, so I don't fully get the process. Should I just wait or ask someone responsible to verify my approach? I refer to https://bugs.launchpad.net/nova/+bug/2132020 and https://review.opendev.org/c/openstack/nova/+/968446
09:11:11 frickler DominikDanelski[m]: in general, you do not need to do anything further, reviewers should find your submission and give feedback. if that doesn't happen in a timely manner, you can ask here or maybe in the weekly meeting (also happening in this channel on Mondays)
09:45:11 DominikDanelski[m] frickler: Thank you. I understand that there's probably no fixed timeline, but approximately when should I reach back?
09:48:20 frickler DominikDanelski[m]: well I'd be hoping that your above message could already generate enough interest, otherwise asking again in a couple of days should be fine
10:19:40 bauzas sean-k-mooney: if you're OK, I'll +W tkajinam's spec given we already discussed in the nova meeting
10:19:46 bauzas https://review.opendev.org/c/openstack/nova-specs/+/966584
10:22:49 sean-k-mooney bauzas: sure
10:25:29 sean-k-mooney DominikDanelski[m]: so today we clean up the vm allocation when the errored vm is deleted
10:26:09 sean-k-mooney DominikDanelski[m]: im not agaist doing that eairlier if we can guarentee that vm will never be resureected
10:26:32 sean-k-mooney DominikDanelski[m]: my inital feedback is its greate you added a functional reguression test but you skipped a step
10:27:14 sean-k-mooney you added https://review.opendev.org/c/openstack/nova/+/968446/1/nova/tests/functional/regressions/test_bug_2132020.py but you ahoudl have an addtional patch before this that demonstrate the allocation is leaked then you fix patch demonstrates that its fixed
10:27:59 sean-k-mooney DominikDanelski[m]: would you mind creatign a secodn review to demonstrate the issue just with the regression test, then rebase your currnt patch on top
10:28:33 sean-k-mooney DominikDanelski[m]: on other question which quota was being exceeded?
10:29:46 sean-k-mooney the server quota included server in error but for all the qutoa corralted with placement allcotion the bug you described sounds valid to me
10:31:28 sean-k-mooney or put another way, its correct for the instance to go to error if a quota would be exceeded but its also correct that we should free the placement allcoation for that instance provide we burry the instance in cell0 or otherwise make sure instnace.host is not set
10:32:16 opendevreview Merged openstack/nova-specs master: libvirt: Use built-in firmware auto-selection for UEFI firmware https://review.opendev.org/c/openstack/nova-specs/+/966584
11:22:02 opendevreview Konrad Gube proposed openstack/nova-specs master: Propose assisted-volume-extend API https://review.opendev.org/c/openstack/nova-specs/+/949504
11:48:15 DominikDanelski[m] bug-report with my regression test but without the fix, wait for the pipelines to fail, and only then update it with the fix?
11:48:15 DominikDanelski[m] sean-k-mooney: Thank you for the review. 1. I observed DISK_GB quota violation leaving non-disk allocations. 2. As for the instance.host, I understand from https://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/regressions/test_bug_1806064.py#L119 that it should already be unset at that stage. 3. Could you expand on the second review? Should I create a completely new review attached (via Closes-Bug) to the

Earlier   Later