| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-21 | |||
| 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? | |
| 16:44:48 | bauzas | looks not | |
| 16:44:51 | sean-k-mooney | so we have said no to extenind that inteface to coolect memory stats in the past | |
| 16:45:07 | sean-k-mooney | this would be a spec or specless blueprint too right | |
| 16:45:10 | bauzas | and this is a feature request, which would require an approval exception | |
| 16:45:27 | bauzas | given we're past the Feature Approval Freeze deadline | |
| 16:45:52 | sean-k-mooney | https://docs.openstack.org/nova/latest/contributor/policies.html#metrics-gathering | |
| 16:45:56 | gibi | yeah put it on the next PTG agenda | |
| 16:46:04 | sean-k-mooney | that speicficly stats that we wont implement new monditors | |
| 16:46:04 | bauzas | I'm particularly not against discussing that feature with the owner but not this cycle | |
| 16:46:16 | sean-k-mooney | that was added after intel propeosed extending this for numa/memory metrics | |
| 16:46:48 | sean-k-mooney | so we can revisit this but it would be a direct revsersal fo that proabition on new monitors | |
| 16:47:11 | bauzas | agreed, this is a broad discussion | |
| 16:47:54 | bauzas | and I'd want to have it done with a quorum | |
| 16:48:20 | bauzas | I agree with gibi, we could add it tothe PTG (provided I create the PTG agenda) | |
| 16:48:34 | sean-k-mooney | yep ptg disccsion woudl be good | |
| 16:49:17 | gibi | yeah so give the discussion a space and time but set expectation with hemanth that this is not an easy one due to the policy in place | |
| 16:49:24 | bauzas | tbc, one of the options being "continue to disregard any other monitors" or even "deprecate the CPU one" | |
| 16:50:03 | sean-k-mooney | so the exisitn inteface is currently frozen | |
| 16:50:10 | bauzas | gibi: 100% agreed, we would need to understand the usecase and why this is crucial to have Nova supporting such monitors | |
| 16:50:14 | sean-k-mooney | and we partly reverted the merged numa code | |
| 16:50:26 | sean-k-mooney | because of the perfoamce impact on the rpc bus | |
| 16:50:40 | sean-k-mooney | however i do know that peopel use the existing cpu monitor | |
| 16:50:49 | sean-k-mooney | namely our internal redhat cloud uses it | |
| 16:51:03 | sean-k-mooney | and it massivly helped them with there workload schdduleing | |
| 16:51:45 | bauzas | perhaps, but there are limitations that people need to understand | |
| 16:51:52 | sean-k-mooney | the specificly use the host cpu load metric via the metrics weigher to avoid hevlilly loaded hosts when placing new instnaces | |
| 16:52:13 | bauzas | I know, that's the most common usecase | |
| 16:52:54 | bauzas | as I said, there are usecases but also limitations | |
| 16:53:18 | bauzas | like, the timewindow is pretty large and if you rely your cloud capacity on such timewindow, you're a fool | |
| 16:53:35 | sean-k-mooney | yep we dont need to preempt the ptg topic | |
| 16:53:56 | sean-k-mooney | well i disagre with that statement but anyway there are lots of dragons here | |
| 16:54:15 | sean-k-mooney | the metrics are sent as aprt fo each schduelr report | |
| 16:55:04 | sean-k-mooney | anywya i think we can move on | |
| 16:55:46 | bauzas | #agreed as the current design policy explicitely avoiding new monitors, this feature requires a quorum and a long discussion to evaluate a policy revision, hence the Nova community proposing to revisit that topic at the PTG | |
| 16:56:00 | bauzas | sean-k-mooney: every 60 secs, right ? :) | |
| 16:56:17 | bauzas | (by default of course) | |
| 16:56:53 | bauzas | I'm just saying that planning your cloud capacity on a 60-sec time window is nice but not helpful | |
| 16:57:09 | bauzas | anyway, we're mostly at time | |
| 16:57:19 | bauzas | anything else ? | |
| 16:57:23 | gibi | - | |
| 16:57:42 | bauzas | thanks all | |
| 16:57:46 | bauzas | #endmeeting | |
| 16:57:46 | opendevmeet | Meeting ended Tue Jan 21 16:57:46 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:46 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.html | |
| 16:57:46 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.txt | |
| 16:57:46 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.log.html | |
| 16:57:59 | elodilles | thanks o/ | |
| 16:58:04 | masahito | thank you | |
| 16:58:33 | gibi | thanks | |
| 18:20:25 | opendevreview | Mark Goddard proposed openstack/nova master: ironic: Let Ironic handle deployment cleanup actions during destroy https://review.opendev.org/c/openstack/nova/+/883411 | |
| 18:37:08 | mikal | sean-k-mooney: are you still around? | |
| 18:50:03 | sean-k-mooney | mikal: kind of | |
| 18:50:31 | sean-k-mooney | i will be for the next 20-30 mins or so | |
| 18:50:54 | sean-k-mooney | mikal: you updated your spcie patches in the last few days correct | |
| 18:52:06 | sean-k-mooney | i asume you woudl like to make progress on https://review.opendev.org/c/openstack/nova/+/927354/13 and the proceedign ones | |
| 20:06:05 | mikal | sean-k-mooney: yeah, the code didn't change, I just figured if I pushed again I'd get a newer CI run. I figure I'll do that weekly from now on. | |
| 20:06:27 | mikal | sean-k-mooney: but yeah, I'm just after some advice about what I need to do next. I think I'm just waiting on reviews, but maybe I missed something? | |
| 20:06:58 | mikal | sean-k-mooney: (also sorry for the slow reply, I was off having my pre-work ablutions). | |
| 20:07:03 | sean-k-mooney | no worries | |
| 20:07:12 | sean-k-mooney | im still here but going to finish shortly | |
| 20:07:28 | mikal | That's cool. You don't have to reply now or anything. | |
| 20:07:44 | sean-k-mooney | melwitt: you started looking at mikal's serise last cycle can you take anotoehr pass this cycle? | |
| 20:07:49 | mikal | I would like to get these landed so I don't have to keep rebasing them, but I understand there are competing priorities. | |
| 20:08:34 | sean-k-mooney | my +2 is still there on the first 2 patches ill see if i can load context and look at the remaining 3 this week | |
| 20:09:09 | mikal | Thanks. Let me know if you need anything from me. There is an outstanding question on the final patch that I need to reload the state for and address. I'll try to get that one done after work tonight. | |
| 20:09:47 | sean-k-mooney | is it this one https://review.opendev.org/c/openstack/nova/+/927354/8/nova/virt/libvirt/driver.py#6790 | |
| 20:09:55 | sean-k-mooney | i have not read it but seems to be the only open comment | |
| 20:10:32 | sean-k-mooney | oh its askign what happens if the requeted number fo usb prots is larger the the model supprot | |
| 20:10:47 | sean-k-mooney | my guess is livbirt will complain and we will fail to define the domain | |
| 20:10:50 | mikal | Yeah, that's the one. | |
| 20:11:05 | mikal | I need to do some testing there. | |
| 20:11:42 | sean-k-mooney | if we knwo or cna detect the limit perhaps via virsh domcapablities | |
| 20:12:10 | sean-k-mooney | we coudl add some validation but i think without tha tthe only real option are put the vm in error and log a relevent error | |
| 20:12:14 | mikal | I think I'd be tempted to just put in a smallish constant upper bound for now and see if people really care? | |
| 20:12:39 | mikal | Like... How many USB devices are you really passing through? Shouldn't it mostly just be mass storage or a smartcard reader or something? | |
| 20:12:43 | sean-k-mooney | that or have a cofnig option that default to the same value | |
| 20:12:48 | mikal | It shouldn't be dozens of devices I wouldn't think. | |
| 20:13:05 | mikal | Yeah. | |
| 20:13:07 | sean-k-mooney | ya so 8-10 proably | |
| 20:13:29 | mikal | I think I'd rather land something simple, and then iterate based on feedback. Solving all possible issues seems like premature optimisation to me. | |
| 20:13:40 | sean-k-mooney | yep | |
| 20:13:41 | mikal | (As long as the simple thing is compatible with whatever we think might be a valid future thing) | |
| 20:14:37 | mikal | Noting as well that for this to be really useful I need to land code in the clients and at least one deployer. So at this rate I think this is at least two releases away from being usable in the real world. | |
| 20:14:38 | sean-k-mooney | you coudl likely set a limit here 'hw_redirected_usb_ports': fields.IntegerField(), | |
| 20:14:42 | sean-k-mooney | of like 10 | |
| 20:14:54 | sean-k-mooney | but it would proably be better to do that in the driver then the object | |
| 20:15:18 | mikal | I can do some reading on the capabilities of the various USB controllers in libvirt today. | |
| 20:16:02 | sean-k-mooney | this is perhaps somethin that could be a followup patch on top by the way | |
| 20:17:18 | mikal | Yeah, that would be my preference. Happy to work on it, don't really want to block on it though. | |
| 20:17:38 | mikal | Anyways, I'll take a look today / tonight and should let you go. I have to go learn how shoes work before I miss my bus. | |
| 20:18:30 | sean-k-mooney | https://libvirt.org/formatdomain.html#controllers the libvirt docs just say " USB controllers accept a ports attribute to configure how many devices can be connected to the controller." | |
| 20:18:43 | sean-k-mooney | but they dont document the limtis so i feel like this will be a qemu limit | |
| 20:18:50 | mikal | Herm. That sounds like "read the qemu code" territory... | |