| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-21 | |||
| 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 | |
| 11:49:33 | sean-k-mooney | i think that makes sense as a baseline | |
| 15:44:42 | opendevreview | Dan Smith proposed openstack/nova master: WIP Inspect snapshot images and adjust disk_format https://review.opendev.org/c/openstack/nova/+/939815 | |
| 15:44:42 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test with latest oslo.utils https://review.opendev.org/c/openstack/nova/+/933444 | |
| 16:08:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: [CI][nova-next]test with placement ac breadth-first https://review.opendev.org/c/openstack/nova/+/937275 | |
| 16:49:09 | opendevreview | James Page proposed openstack/nova master: Restore nova.virt.__init__ https://review.opendev.org/c/openstack/nova/+/939827 | |
| 18:27:15 | mikal | sean-k-mooney: so, mostly. If I am reading this stuff right, OHCI / UHCI are USB 1.1. If you want USB 2.0 you need both EHCI _and_ one of OHCI / UCHI as a "companion controller". None of these controllers are particularly virt (or 64 bit!) friendly. XHCI supports USB 1.1 / 2 / 3 without a companion controller, while also being 64 bit and virt friendly. | |
| 18:28:21 | mikal | sean-k-mooney: XHCI 1.0 was released in 2010, so I would hope that basically anything people would want to run would support it. | |
| 18:30:39 | opendevreview | Merged openstack/nova master: Run nova-next without periodic cache healing https://review.opendev.org/c/openstack/nova/+/939453 | |
| 18:33:10 | sean-k-mooney | mikal: yep it should | |
| 18:33:22 | sean-k-mooney | its a good baseline if nothing else | |
| 18:36:50 | mikal | Honestly, adding the others back would be relatively trivial (less than ten lines of code), so if you think that's reasonable I'll tweak that PR to just do XHCI and we can limit the number of redirected channels to the number of root ports on a XHCI controller. | |
| 18:37:30 | mikal | I would like to test to see if qemu-xhci works for me because for reasons I no longer remember I used nec-xhci in my testing last time. | |
| 18:38:32 | sean-k-mooney | ack sounds like a plan | |
| 18:40:29 | mikal | Cool. I personally don't think any of that should hold up reviews of the earlier patches, I see this as a relatively minor tweak to the final patch in the series. | |