Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-01-21
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.log.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 Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.html
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 bauzas #endmeeting
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...
20:19:31 sean-k-mooney i think the usb sepc allwos somehting like 256 device but i highly doubt qemu supprots that
20:19:49 sean-k-mooney ok ill chat to you tomorrow o/
20:20:06 mikal Thanks Sean, sorry if I made you late for anything. I appreciate the chat.
20:21:34 sean-k-mooney https://qemu-project.gitlab.io/qemu/system/devices/usb.html#physical-port-addressing
20:21:54 sean-k-mooney UHCI has two root ports (1,2). EHCI has six root ports (1-6), and the emulated (1.1) USB hub has eight ports.
20:22:14 sean-k-mooney so 8 unless you use hubs so ya i would limit to 8 for now
20:22:55 mikal Yeah, I'm going to be honest and say I don't immediately know the difference between a "root port" and whatever other types of ports there are.
20:23:30 sean-k-mooney usb can have a tree for device below the root port up to 8 level deep i belive
20:23:55 sean-k-mooney linius tech tips did a video tyring to reach the limit pluging usb hubs into usb hubs a few months ago
20:24:31 sean-k-mooney https://www.youtube.com/watch?v=hiwaxlttWow
20:25:12 mikal Heh. Actionable advice right here.
20:25:17 mikal s/here/there/
#openstack-nova - 2025-01-22
01:32:54 hemanth Hi nova team, appreciate for discussing compute memory monitor during weekly meeting (could not attend due to TZ diff) and thanks sean for detail explanation on the PR!
08:25:21 opendevreview zhou zhong proposed openstack/nova master: Add auto_converge parameters for invoking the migration https://review.opendev.org/c/openstack/nova/+/935614
08:34:29 mikal sean-k-mooney: I did some reading today, and I am left with the distinct impression that we should only add XHCI USB controllers for now. This makes it simpler to predict how many ports are available, but the performance of the older controllers is also not great. So much like we don't support floppies, we should probably not support USB controllers from the 1990s.
08:35:12 mikal sean-k-mooney: that said, I think we should probably support both qemu-xhci and nec-xhci, because I suspect (without testing) that Windows wont know about the qemu version without additional drivers.
08:35:53 mikal sean-k-mooney: it would be trivial to add other controllers back if someone could make a case for them later, but we should probably remove them before the USB redir extra spec lands.
11:48:58 sean-k-mooney ya so the diffent types of port in the list i proved were basicly usb 1 2 and 3
11:49:07 sean-k-mooney xhci being usb 3

Earlier   Later