| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-21 | |||
| 16:16:56 | bauzas | (bauzas) Updating our QEMU/libvirt min versions ? | |
| 16:17:26 | bauzas | so, when working with Uggla on the VFIO-pci series for live-migration, we discussed about the minimum versions we have | |
| 16:18:06 | bauzas | the context is that in libvirt we do support our minimums from Focal, AFAICT :) | |
| 16:18:56 | bauzas | but now, our tested runtimes are clear, we only need to support Jammy | |
| 16:19:00 | bauzas | #link https://governance.openstack.org/tc/reference/runtimes/2025.1.html | |
| 16:19:51 | bauzas | during the Caracal PTG, we agreed on upgrading our min versions as soon as we were able to bump them, and I'd prefer honestly to bump our mins on that SLURP release rather than on a non-SLURP | |
| 16:20:25 | gibi | +1 | |
| 16:20:28 | bauzas | (which would mean that we need to forward-port the relnotes to G* which would be the next SLURP if we bump during Flamingo) | |
| 16:20:28 | Uggla | +1 | |
| 16:20:51 | bauzas | are we okay to bump our mins to be the existing the next mins ? | |
| 16:20:57 | bauzas | which are Jammy ones | |
| 16:21:20 | bauzas | we could define the next mins to be the Noble versions for QEMU and libvirt | |
| 16:21:55 | gibi | +1 on making the current next_min our new min, and set next_min to whatever in Noble | |
| 16:21:58 | bauzas | #link https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L215-L224 | |
| 16:22:38 | Uggla | sounds good, are there docs to update too ? | |
| 16:22:39 | bauzas | that's OK, we can provide a patch and people will review it anyway | |
| 16:23:05 | bauzas | Uggla: yes, there are, see the big fat comment on top of the code, by the link I passed | |
| 16:23:25 | bauzas | Uggla: fancy proposing the bump ? | |
| 16:23:55 | gibi | feel free to ping me for review | |
| 16:24:14 | bauzas | thanks gibi | |
| 16:24:16 | Uggla | yep I can provide the patch early next week. | |
| 16:24:35 | gibi | Uggla: thanks for taking this | |
| 16:24:44 | bauzas | #agreed Uggla will propose the QEMU/libvirt versions bump this cycle so people may review the proposal | |
| 16:24:57 | bauzas | moving on | |
| 16:25:05 | bauzas | a procedural note, | |
| 16:25:17 | bauzas | (bauzas) This is my last PTL term | |
| 16:25:18 | Uggla | I will also propose the release for trait if that's ok for you ? | |
| 16:25:34 | bauzas | Uggla: which trait ? | |
| 16:25:38 | gibi | Uggla: sure go ahead | |
| 16:25:51 | sean-k-mooney | bauzas: oh sorry | |
| 16:25:59 | sean-k-mooney | i was distracted | |
| 16:26:02 | bauzas | oh you meant the os-trait release patch ? sure, but please wait until next week as said before | |
| 16:26:07 | gibi | if in the meantime we get the patches for the vTPM traits the we can hold the release a bit but I suggest to just do one more release if needed | |
| 16:26:09 | Uggla | bauzas, yes | |
| 16:26:26 | bauzas | sean-k-mooney: no worries, we'll get back to you in a sec | |
| 16:26:29 | gibi | releases are quick an cheap | |
| 16:26:42 | bauzas | so, about the PTL seat, I'll leave it | |
| 16:27:00 | bauzas | as a reminder, elections start on Feb 5 | |
| 16:27:12 | bauzas | voilà, it was mostly a FYI | |
| 16:27:36 | gibi | bauzas: thank you for your service | |
| 16:27:41 | bauzas | (as you've seen, my upstream involvment on Nova decreased a bit so I need to give me more time to do real work) | |
| 16:28:00 | elodilles | indeed, thanks so far bauzas o/ | |
| 16:28:25 | Uggla | thx bauzas for the PRL service. | |
| 16:28:39 | fwiesel | bauzas: Thanks a lot! | |
| 16:28:59 | Uggla | I think I will be a candidate for the PTL seat. bauzas almost convinced me. :) | |
| 16:29:03 | bauzas | thanks, I appreciated that seat but now the cushion has my bottom nearly printed on it *on it since I seated too long | |
| 16:29:28 | bauzas | I don't want to convince anyone, it's an election | |
| 16:29:45 | bauzas | but I appreciate people volunteering for that service | |
| 16:29:50 | Uggla | Of course. | |
| 16:30:02 | bauzas | as a reminder, I won't disappear and I'll of course help the new PTL | |
| 16:30:43 | bauzas | whoever is elected | |
| 16:31:13 | bauzas | anyway, that reminds me I have to start to draft next PTG agenda | |
| 16:31:41 | bauzas | of course, I won't run it but the next person will appreciate to have it ready | |
| 16:31:58 | bauzas | anyway, done on that procedural note | |
| 16:32:04 | bauzas | moving on | |
| 16:32:12 | bauzas | back to sean-k-mooney's point | |
| 16:32:23 | bauzas | (sean-k-mooney) disable the heal instance info cache periodic | |
| 16:32:29 | bauzas | sean-k-mooney: around now ? | |
| 16:32:33 | sean-k-mooney | ya so context | |
| 16:33:26 | sean-k-mooney | about 2-3 years ago the neturon folks started seeing higher then expecte background load the neutorn server api in bug reports form upstream/downstream custoemrs | |
| 16:34:05 | sean-k-mooney | after some invstatiation thaty raised the topic of our periodic heal action in a neutron nova cross project session and asked is it really needed | |
| 16:34:12 | bauzas | indeed | |
| 16:34:25 | sean-k-mooney | at the time we determined that it should not be but it kind of fell off our radar | |
| 16:34:27 | bauzas | I do also remember some OpenInfra talks about that | |
| 16:34:55 | sean-k-mooney | recently this has come up again down stream and i wanted to bring th topic back upstrem | |
| 16:35:04 | sean-k-mooney | so there are two patches related to this in flight | |
| 16:35:18 | sean-k-mooney | the first just test disabling the perodic in nova next | |
| 16:35:32 | sean-k-mooney | i belive tha that has already merged | |
| 16:35:40 | sean-k-mooney | the second which is what i wanted to dicuss | |
| 16:35:53 | sean-k-mooney | is how do we feel about finally disbaling the perodic by default | |
| 16:36:19 | bauzas | given the operator feedback I heard, I'm pro-this | |
| 16:36:34 | sean-k-mooney | i would like to propose doign it this cycle but if we want to leave it back in the nova-next job to get more data that also a path forward | |
| 16:36:43 | bauzas | sean-k-mooney: here's my proposal, | |
| 16:37:07 | bauzas | send a thread to openstack-discuss by notifying the ops that we plan to do it this cycle | |
| 16:37:13 | bauzas | link to the proposed patch | |
| 16:37:29 | bauzas | and if nobody argues by the next weeks, then we can merge it | |
| 16:37:47 | bauzas | my bet is that operators will appreciate the default disabling | |
| 16:37:59 | sean-k-mooney | ok i can do that | |
| 16:38:15 | sean-k-mooney | shal we set a date to check back. say 2 weeks? | |
| 16:38:27 | sean-k-mooney | i would prefer not to wiat rith to FF to change the default | |
| 16:38:49 | sean-k-mooney | in case we decied we need to revert it | |
| 16:38:53 | bauzas | good point | |
| 16:39:07 | bauzas | yeah, 2 weeks seems a reasonable trade-off | |
| 16:39:07 | masahito | I agree the default change as a large scale OpenStack operator. it's nice update. | |
| 16:39:14 | bauzas | we have 5 weeks to FF | |
| 16:39:25 | bauzas | that would leave 3 weeks with the change running in CI | |
| 16:40:05 | sean-k-mooney | ack ill send a mail to the list later today | |
| 16:40:10 | gibi | I'm OK with the 2 weeks notice | |
| 16:40:45 | sean-k-mooney | the proceedign patch https://review.opendev.org/c/openstack/nova/+/939453/1 | |
| 16:40:51 | sean-k-mooney | hasnet actully merge yet | |
| 16:41:05 | sean-k-mooney | that is just testing disabling it in nova-next only | |
| 16:41:18 | sean-k-mooney | if there is no objection ill recheck that | |
| 16:41:36 | sean-k-mooney | and that gives ues 2 addtional weeks fo feedback in the nova-next job while we wait | |
| 16:41:52 | bauzas | indeed | |
| 16:41:58 | bauzas | sounds a plan | |
| 16:42:42 | bauzas | #agreed sean-k-mooney will notify openstack-discuss about disabling by default the instance info cache and give a 2-week notice for disagreements | |
| 16:42:53 | bauzas | cool | |
| 16:42:56 | bauzas | moving on | |
| 16:43:55 | bauzas | (hemanth) Request for review - Compute memory monitor | |
| 16:43:59 | bauzas | is hemanth here? | |