| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-12-01 | |||
| 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 | gibi | o/ | |
| 16:32:43 | Uggla | gibi, something new to share about eventlet removal ? | |
| 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 | Uggla | sure | |
| 16:41:08 | gibi | I'm pretty +2 on it :) | |
| 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 | 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: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: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 | sean-k-mooney | which is a porblem if you do inplace upgrades | |
| 16:52:36 | dansmith | yep, understood | |
| 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 | |