| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-12-01 | |||
| 16:13:39 | Uggla | gibi, hum maybe that's a good proposal. ;) | |
| 16:14:07 | Uggla | #info I'll send a "warning" about SF on the mailing list. | |
| 16:16:02 | Uggla | #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg | |
| 16:16:33 | Uggla | #topic Review priorities | |
| 16:16:44 | Uggla | #link https://etherpad.opendev.org/p/nova-2026.1-status | |
| 16:16:49 | Uggla | #topic OpenAPI | |
| 16:16:58 | Uggla | #info still 23 remaining atm. | |
| 16:16:58 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:17:28 | sean-k-mooney | oh o/ | |
| 16:17:43 | Uggla | #topic Stable Branches | |
| 16:17:59 | elodilles | thanks | |
| 16:18:14 | elodilles | #info all three stable branches' gates seem to be in a good state again | |
| 16:18:22 | elodilles | grenade jobs are passing again | |
| 16:18:30 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:18:44 | elodilles | and that's all from me | |
| 16:18:55 | elodilles | Uggla: back to you | |
| 16:21:10 | Uggla | thanks elodilles | |
| 16:21:25 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:21:31 | fwiesel | Hi, no updates from my side. | |
| 16:21:38 | Uggla | fwiesel thanks | |
| 16:21:42 | gibi | fwiesel: I have a question for you | |
| 16:21:47 | fwiesel | gibi: Go ahead | |
| 16:22:18 | gibi | what would be the way to trigger some vmware testing for this changes https://review.opendev.org/q/topic:%22eventlet-removal%22+project:openstack/oslo.vmware ? | |
| 16:22:51 | gibi | the last one in the series is probably not a clean refactor and might cause troubles | |
| 16:22:59 | gibi | https://review.opendev.org/c/openstack/oslo.vmware/+/967418 | |
| 16:25:40 | fwiesel | gibi: A comment with "sap-openstack-ci recheck - some comment" should do the trick. But currently it is broken. | |
| 16:26:25 | fwiesel | The neutron service cannot even start a simple thread, which I have trouble understanding. | |
| 16:26:56 | gibi | OK thanks for the info | |
| 16:27:15 | gibi | fwiesel: neutron when from eventlet to threading at the end of Flamingo | |
| 16:28:00 | gibi | so probably that change is related to your trouble | |
| 16:28:12 | gibi | anyhow I will circle back later to the oslo.vmware patch | |
| 16:28:59 | fwiesel | gibi: Yeah, and at least in our VM, a simple "threading.Thread(target=func)" doesn't work in the place where the service should be started. the target function won't get started. | |
| 16:29:31 | gibi | fwiesel: that line does not start a thread, you need .start() at the end to actually kick of the defined thread | |
| 16:31:15 | Uggla | gibi, fwiesel is that ok, can we move on ? | |
| 16:31:34 | fwiesel | Uggla: Sure, I don'T think we will debug that now :) | |
| 16:31:53 | gibi | sure | |
| 16:31:55 | gibi | :) | |
| 16:32:28 | Uggla | #topic Gibi's news about eventlet removal | |
| 16:32:43 | Uggla | gibi, something new to share about eventlet removal ? | |
| 16:32:43 | gibi | o/ | |
| 16:33:32 | gibi | unfortunately not much new on my side. The bottom 7 patches are ready for review in the compute series https://review.opendev.org/c/openstack/nova/+/965467/22 | |
| 16:33:49 | gibi | and you already saw above my oslo.vmware series | |
| 16:33:57 | gibi | which needs testing | |
| 16:34:33 | gibi | sambork: anything on your side maybe? | |
| 16:36:49 | gibi | I guess no, so we can move on | |
| 16:36:57 | Uggla | thanks gibi | |
| 16:37:16 | Uggla | #topic Open discussion | |
| 16:37:44 | Uggla | I will cancel the next week meeting. | |
| 16:38:23 | Uggla | I don't have a clear visibility on our agenda, so I'd rather cancel. | |
| 16:38:48 | Uggla | I will write an email to openstack discuss too. | |
| 16:38:54 | gibi | yeah some of us will travel next week so I agree to cancel | |
| 16:39:02 | tkajinam | +1 | |
| 16:39:54 | Uggla | Something you'd like to discuss ? | |
| 16:40:46 | tkajinam | I'm just wondering if we can quickly discuss https://review.opendev.org/c/openstack/nova-specs/+/966584 . | |
| 16:41:08 | gibi | I'm pretty +2 on it :) | |
| 16:41:08 | Uggla | sure | |
| 16:41:23 | tkajinam | :-) | |
| 16:41:26 | Uggla | bauzas as well. | |
| 16:42:00 | bauzas | yup, I can send it to the gate | |
| 16:42:06 | tkajinam | ah, ok | |
| 16:42:21 | tkajinam | we can agree how complicated the logic to select the existing firmware is, based on the actual code logic | |
| 16:42:44 | tkajinam | I mean leaving it for follow-up and keep the original direction so far | |
| 16:42:53 | gibi | tkajinam: ^^ good startegy | |
| 16:43:46 | tkajinam | I saw sean-k-mooney also voted his +2 :-) | |
| 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 | |