| opendevreview | suiong ng proposed openstack/nova master: Fix parameter order in add_instance_info_to_node https://review.opendev.org/c/openstack/nova/+/939411 | 00:52 |
|---|---|---|
| opendevreview | Masahito Muroi proposed openstack/nova master: Fix parameter order in add_instance_info_to_node https://review.opendev.org/c/openstack/nova/+/939411 | 01:07 |
| opendevreview | Masahito Muroi proposed openstack/nova master: Use defaultdict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/939658 | 01:09 |
| opendevreview | Masahito Muroi proposed openstack/nova master: Add ServersViewBuilderTestV296 unit test class https://review.opendev.org/c/openstack/nova/+/939673 | 01:09 |
| opendevreview | suiong ng proposed openstack/nova master: Fix parameter order in add_instance_info_to_node https://review.opendev.org/c/openstack/nova/+/939411 | 01:21 |
| opendevreview | suiong ng proposed openstack/nova master: Fix parameter order in add_instance_info_to_node https://review.opendev.org/c/openstack/nova/+/939411 | 02:42 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing image properties in server show response https://review.opendev.org/c/openstack/nova/+/939649 | 07:01 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | 08:34 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | 08:34 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | 08:34 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra spec for sound device. https://review.opendev.org/c/openstack/nova/+/926126 | 08:34 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927354 | 08:34 |
| opendevreview | Pierre Riteau proposed openstack/nova stable/2024.1: libvirt: Wrap un-proxied listDevices() and listAllDevices() https://review.opendev.org/c/openstack/nova/+/939695 | 08:44 |
| lucadelmonte | hello, not sure if this is the right channel to ask some clarificatin about ironic node console integration with nova, i am having some issue to make it work, following the documentation i setup a node with ipmitool-socat console driver, and issuing the baremetal command i am able to get the socat connection working, when i issue the command from nova (openstack console url show --debug --serial <SERVERID>) i rece | 11:03 |
| lucadelmonte | "unexpected exception in api method: attributeerror: 'node' object has no attribute 'get_node_console", does someone have some ideas on how to fix it? | 11:03 |
| sean-k-mooney | gibi: fyi https://review.opendev.org/c/openstack/devstack/+/922846 merged if you want to try updating https://review.opendev.org/c/openstack/nova/+/937275 again | 13:02 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [CI][nova-next]test with placement ac breadth-first https://review.opendev.org/c/openstack/nova/+/937275 | 13:39 |
| gibi | sean-k-mooney: thanks for the headsup. Trying in ^^ | 13:40 |
| sean-k-mooney | cool lets check back in an hour or two and hopefully that passes | 13:41 |
| *** gaudenz__ is now known as gaudenz | 13:59 | |
| *** ykarel_ is now known as ykarel | 14:33 | |
| opendevreview | James Page proposed openstack/nova master: Switch to using oslo.utils secretutils https://review.opendev.org/c/openstack/nova/+/939721 | 15:21 |
| opendevreview | James Page proposed openstack/nova master: Correctly patch get_by_flavor_id https://review.opendev.org/c/openstack/nova/+/939722 | 15:21 |
| opendevreview | Merged openstack/placement stable/2024.2: Add a global limit on the number of allocation candidates https://review.opendev.org/c/openstack/placement/+/938939 | 15:54 |
| gibi | sean-k-mooney: no luck, now it fails at https://github.com/openstack/devstack/blob/3cddf9f8832328c17be3644ddd7be5a7dcbedda8/inc/meta-config#L192 | 15:56 |
| gibi | sean-k-mooney: I will dig a bit later | 15:56 |
| sean-k-mooney | oh i see | 15:58 |
| sean-k-mooney | we are now creatign the dir in merge_config_file | 15:58 |
| sean-k-mooney | so we can remove that if | 15:58 |
| sean-k-mooney | https://github.com/openstack/devstack/blob/3cddf9f8832328c17be3644ddd7be5a7dcbedda8/inc/meta-config#L189-L193 | 15:58 |
| elodilles | gibi: btw, the placement patches are on gate now, was it too early to merge them? :-o | 15:59 |
| elodilles | gibi: i mean the backports on stable/2024.2 | 16:00 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jan 21 16:00:34 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | hey folks | 16:00 |
| gibi | elodilles: don't worry :) | 16:00 |
| elodilles | :) | 16:00 |
| elodilles | o/ | 16:00 |
| fwiesel | o/ | 16:00 |
| masahito | o/ | 16:00 |
| opendevreview | Merged openstack/placement stable/2024.2: Factor out allocation candidate generation strategy https://review.opendev.org/c/openstack/placement/+/938940 | 16:01 |
| opendevreview | Merged openstack/placement stable/2024.2: Add round-robin candidate generation strategy https://review.opendev.org/c/openstack/placement/+/938941 | 16:01 |
| gibi | elodilles: this is just figthing with devstack to configure placement to use the new config options in nova-next | 16:01 |
| elodilles | gibi: ACK (merged meanwhile ^^^) | 16:01 |
| gibi | elodilles: thanks | 16:01 |
| bauzas | okay let's start the meeting | 16:01 |
| bauzas | I'll be clear, packed day with meetings, so I had no time to update the agenda | 16:02 |
| bauzas | so let's do it live | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
| bauzas | anything about bugs ? | 16:03 |
| Uggla | o/ | 16:03 |
| bauzas | looks not | 16:03 |
| bauzas | #topic Gate status | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:04 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:04 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:04 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:04 |
| bauzas | (still waiting for the periodic runs check to be done) | 16:04 |
| bauzas | anything about the gate ? | 16:04 |
| bauzas | I'll be honest, this week I was mostly away from upstream CI | 16:05 |
| bauzas | okay, all periodics are green-ish (one is on RETRY) | 16:05 |
| bauzas | I guess we can move on | 16:05 |
| bauzas | then, let's move on | 16:06 |
| bauzas | #topic Release Planning | 16:07 |
| bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:07 |
| bauzas | #info Nova deadlines are set in the above schedule | 16:07 |
| bauzas | #info 5 weeks before Feature Freeze | 16:07 |
| bauzas | tick tock... | 16:07 |
| bauzas | as a reminder from last week : | 16:07 |
| bauzas | #info we'll try to create as os-traits release next 2 week, please provide your os-traits patches sooner than later. | 16:08 |
| bauzas | we already merged one trait proposal, so feel free to propose the ones you need for your series | 16:08 |
| bauzas | #undo | 16:08 |
| opendevmeet | Removing item from minutes: #info we'll try to create as os-traits release next 2 week, please provide your os-traits patches sooner than later. | 16:08 |
| bauzas | #info we'll try to create as os-traits release next week, please provide your os-traits patches sooner than later. | 16:08 |
| bauzas | (bad copy paste) | 16:08 |
| bauzas | this is said | 16:09 |
| bauzas | any question ? | 16:09 |
| Uggla | We need to bump the LIBVIRT / QEMU version too. | 16:09 |
| bauzas | we'll discuss that in the open discussion section | 16:10 |
| Uggla | ok | 16:10 |
| bauzas | moving on then | 16:10 |
| bauzas | #topic Review priorities | 16:10 |
| bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:10 |
| bauzas | hemanth: I've seen your review request on https://review.opendev.org/c/openstack/nova/+/939044 | 16:11 |
| bauzas | I'll make sure that your patch is in the above etherpad | 16:11 |
| bauzas | oh it's there already | 16:11 |
| bauzas | hemanth: given the patch, we'll discuss that in the open discussion section to see whether it's a specless blueprint or not and whether we can accept it as an feature exception for this cycle | 16:12 |
| bauzas | moving on then | 16:13 |
| bauzas | #topic Stable Branches | 16:13 |
| bauzas | elodilles: your time :) | 16:13 |
| elodilles | ACK | 16:13 |
| elodilles | i should be quick: | 16:13 |
| elodilles | #info nothing to report, stable gates seem to be healthy | 16:13 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:13 |
| elodilles | this is all | 16:14 |
| elodilles | from me | 16:14 |
| bauzas | ++ | 16:14 |
| bauzas | thanks | 16:14 |
| elodilles | np | 16:14 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:14 |
| bauzas | fwiesel: anything to mention ? | 16:15 |
| fwiesel | Nothing to report from my side | 16:15 |
| bauzas | cool | 16:15 |
| bauzas | #topic Open discussion | 16:15 |
| bauzas | pretty large agenda for today | 16:15 |
| bauzas | let's be productive | 16:15 |
| bauzas | (sean-k-mooney) disable the heal instance info cache periodic | 16:15 |
| bauzas | around ? | 16:16 |
| bauzas | if not, we can leave that item for next week, no worries | 16:16 |
| bauzas | next item | 16:16 |
| bauzas | (bauzas) Updating our QEMU/libvirt min versions ? | 16:16 |
| bauzas | so, when working with Uggla on the VFIO-pci series for live-migration, we discussed about the minimum versions we have | 16:17 |
| bauzas | the context is that in libvirt we do support our minimums from Focal, AFAICT :) | 16:18 |
| bauzas | but now, our tested runtimes are clear, we only need to support Jammy | 16:18 |
| bauzas | #link https://governance.openstack.org/tc/reference/runtimes/2025.1.html | 16:19 |
| 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:19 |
| gibi | +1 | 16:20 |
| 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 |
| Uggla | +1 | 16:20 |
| bauzas | are we okay to bump our mins to be the existing the next mins ? | 16:20 |
| bauzas | which are Jammy ones | 16:20 |
| bauzas | we could define the next mins to be the Noble versions for QEMU and libvirt | 16:21 |
| gibi | +1 on making the current next_min our new min, and set next_min to whatever in Noble | 16:21 |
| bauzas | #link https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L215-L224 | 16:21 |
| * gibi does not feel the quorum | 16:22 | |
| Uggla | sounds good, are there docs to update too ? | 16:22 |
| bauzas | that's OK, we can provide a patch and people will review it anyway | 16:22 |
| bauzas | Uggla: yes, there are, see the big fat comment on top of the code, by the link I passed | 16:23 |
| bauzas | Uggla: fancy proposing the bump ? | 16:23 |
| gibi | feel free to ping me for review | 16:23 |
| bauzas | thanks gibi | 16:24 |
| Uggla | yep I can provide the patch early next week. | 16:24 |
| gibi | Uggla: thanks for taking this | 16:24 |
| bauzas | #agreed Uggla will propose the QEMU/libvirt versions bump this cycle so people may review the proposal | 16:24 |
| bauzas | moving on | 16:24 |
| bauzas | a procedural note, | 16:25 |
| bauzas | (bauzas) This is my last PTL term | 16:25 |
| Uggla | I will also propose the release for trait if that's ok for you ? | 16:25 |
| bauzas | Uggla: which trait ? | 16:25 |
| gibi | Uggla: sure go ahead | 16:25 |
| sean-k-mooney | bauzas: oh sorry | 16:25 |
| sean-k-mooney | i was distracted | 16:25 |
| bauzas | oh you meant the os-trait release patch ? sure, but please wait until next week as said before | 16:26 |
| 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 |
| Uggla | bauzas, yes | 16:26 |
| bauzas | sean-k-mooney: no worries, we'll get back to you in a sec | 16:26 |
| gibi | releases are quick an cheap | 16:26 |
| bauzas | so, about the PTL seat, I'll leave it | 16:26 |
| bauzas | as a reminder, elections start on Feb 5 | 16:27 |
| bauzas | voilà, it was mostly a FYI | 16:27 |
| gibi | bauzas: thank you for your service | 16:27 |
| 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:27 |
| elodilles | indeed, thanks so far bauzas o/ | 16:28 |
| Uggla | thx bauzas for the PRL service. | 16:28 |
| fwiesel | bauzas: Thanks a lot! | 16:28 |
| Uggla | I think I will be a candidate for the PTL seat. bauzas almost convinced me. :) | 16:28 |
| 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 |
| bauzas | I don't want to convince anyone, it's an election | 16:29 |
| bauzas | but I appreciate people volunteering for that service | 16:29 |
| Uggla | Of course. | 16:29 |
| bauzas | as a reminder, I won't disappear and I'll of course help the new PTL | 16:30 |
| bauzas | whoever is elected | 16:30 |
| bauzas | anyway, that reminds me I have to start to draft next PTG agenda | 16:31 |
| bauzas | of course, I won't run it but the next person will appreciate to have it ready | 16:31 |
| bauzas | anyway, done on that procedural note | 16:31 |
| bauzas | moving on | 16:32 |
| bauzas | back to sean-k-mooney's point | 16:32 |
| bauzas | (sean-k-mooney) disable the heal instance info cache periodic | 16:32 |
| bauzas | sean-k-mooney: around now ? | 16:32 |
| sean-k-mooney | ya so context | 16:32 |
| 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:33 |
| 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 |
| bauzas | indeed | 16:34 |
| sean-k-mooney | at the time we determined that it should not be but it kind of fell off our radar | 16:34 |
| bauzas | I do also remember some OpenInfra talks about that | 16:34 |
| sean-k-mooney | recently this has come up again down stream and i wanted to bring th topic back upstrem | 16:34 |
| sean-k-mooney | so there are two patches related to this in flight | 16:35 |
| sean-k-mooney | the first just test disabling the perodic in nova next | 16:35 |
| sean-k-mooney | i belive tha that has already merged | 16:35 |
| sean-k-mooney | the second which is what i wanted to dicuss | 16:35 |
| sean-k-mooney | is how do we feel about finally disbaling the perodic by default | 16:35 |
| bauzas | given the operator feedback I heard, I'm pro-this | 16:36 |
| 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 |
| bauzas | sean-k-mooney: here's my proposal, | 16:36 |
| bauzas | send a thread to openstack-discuss by notifying the ops that we plan to do it this cycle | 16:37 |
| bauzas | link to the proposed patch | 16:37 |
| bauzas | and if nobody argues by the next weeks, then we can merge it | 16:37 |
| bauzas | my bet is that operators will appreciate the default disabling | 16:37 |
| sean-k-mooney | ok i can do that | 16:37 |
| sean-k-mooney | shal we set a date to check back. say 2 weeks? | 16:38 |
| sean-k-mooney | i would prefer not to wiat rith to FF to change the default | 16:38 |
| sean-k-mooney | in case we decied we need to revert it | 16:38 |
| bauzas | good point | 16:38 |
| bauzas | yeah, 2 weeks seems a reasonable trade-off | 16:39 |
| masahito | I agree the default change as a large scale OpenStack operator. it's nice update. | 16:39 |
| bauzas | we have 5 weeks to FF | 16:39 |
| bauzas | that would leave 3 weeks with the change running in CI | 16:39 |
| sean-k-mooney | ack ill send a mail to the list later today | 16:40 |
| gibi | I'm OK with the 2 weeks notice | 16:40 |
| sean-k-mooney | the proceedign patch https://review.opendev.org/c/openstack/nova/+/939453/1 | 16:40 |
| sean-k-mooney | hasnet actully merge yet | 16:40 |
| sean-k-mooney | that is just testing disabling it in nova-next only | 16:41 |
| sean-k-mooney | if there is no objection ill recheck that | 16:41 |
| sean-k-mooney | and that gives ues 2 addtional weeks fo feedback in the nova-next job while we wait | 16:41 |
| bauzas | indeed | 16:41 |
| bauzas | sounds a plan | 16:41 |
| 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 |
| bauzas | cool | 16:42 |
| bauzas | moving on | 16:42 |
| bauzas | (hemanth) Request for review - Compute memory monitor | 16:43 |
| bauzas | is hemanth here? | 16:43 |
| bauzas | looks not | 16:44 |
| sean-k-mooney | so we have said no to extenind that inteface to coolect memory stats in the past | 16:44 |
| sean-k-mooney | this would be a spec or specless blueprint too right | 16:45 |
| bauzas | and this is a feature request, which would require an approval exception | 16:45 |
| bauzas | given we're past the Feature Approval Freeze deadline | 16:45 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/contributor/policies.html#metrics-gathering | 16:45 |
| gibi | yeah put it on the next PTG agenda | 16:45 |
| sean-k-mooney | that speicficly stats that we wont implement new monditors | 16:46 |
| bauzas | I'm particularly not against discussing that feature with the owner but not this cycle | 16:46 |
| sean-k-mooney | that was added after intel propeosed extending this for numa/memory metrics | 16:46 |
| sean-k-mooney | so we can revisit this but it would be a direct revsersal fo that proabition on new monitors | 16:46 |
| bauzas | agreed, this is a broad discussion | 16:47 |
| bauzas | and I'd want to have it done with a quorum | 16:47 |
| bauzas | I agree with gibi, we could add it tothe PTG (provided I create the PTG agenda) | 16:48 |
| sean-k-mooney | yep ptg disccsion woudl be good | 16:48 |
| 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 |
| bauzas | tbc, one of the options being "continue to disregard any other monitors" or even "deprecate the CPU one" | 16:49 |
| sean-k-mooney | so the exisitn inteface is currently frozen | 16:50 |
| bauzas | gibi: 100% agreed, we would need to understand the usecase and why this is crucial to have Nova supporting such monitors | 16:50 |
| sean-k-mooney | and we partly reverted the merged numa code | 16:50 |
| sean-k-mooney | because of the perfoamce impact on the rpc bus | 16:50 |
| sean-k-mooney | however i do know that peopel use the existing cpu monitor | 16:50 |
| sean-k-mooney | namely our internal redhat cloud uses it | 16:50 |
| sean-k-mooney | and it massivly helped them with there workload schdduleing | 16:51 |
| bauzas | perhaps, but there are limitations that people need to understand | 16:51 |
| 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:51 |
| bauzas | I know, that's the most common usecase | 16:52 |
| bauzas | as I said, there are usecases but also limitations | 16:52 |
| bauzas | like, the timewindow is pretty large and if you rely your cloud capacity on such timewindow, you're a fool | 16:53 |
| sean-k-mooney | yep we dont need to preempt the ptg topic | 16:53 |
| sean-k-mooney | well i disagre with that statement but anyway there are lots of dragons here | 16:53 |
| sean-k-mooney | the metrics are sent as aprt fo each schduelr report | 16:54 |
| sean-k-mooney | anywya i think we can move on | 16:55 |
| 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:55 |
| bauzas | sean-k-mooney: every 60 secs, right ? :) | 16:56 |
| bauzas | (by default of course) | 16:56 |
| bauzas | I'm just saying that planning your cloud capacity on a 60-sec time window is nice but not helpful | 16:56 |
| bauzas | anyway, we're mostly at time | 16:57 |
| bauzas | anything else ? | 16:57 |
| gibi | - | 16:57 |
| bauzas | thanks all | 16:57 |
| bauzas | #endmeeting | 16:57 |
| 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 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-21-16.00.log.html | 16:57 |
| elodilles | thanks o/ | 16:57 |
| masahito | thank you | 16:58 |
| gibi | thanks | 16:58 |
| *** eandersson0 is now known as eandersson | 17:51 | |
| 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:20 |
| mikal | sean-k-mooney: are you still around? | 18:37 |
| sean-k-mooney | mikal: kind of | 18:50 |
| sean-k-mooney | i will be for the next 20-30 mins or so | 18:50 |
| sean-k-mooney | mikal: you updated your spcie patches in the last few days correct | 18:50 |
| 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 | 18:52 |
| 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 |
| 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 |
| mikal | sean-k-mooney: (also sorry for the slow reply, I was off having my pre-work ablutions). | 20:06 |
| sean-k-mooney | no worries | 20:07 |
| sean-k-mooney | im still here but going to finish shortly | 20:07 |
| mikal | That's cool. You don't have to reply now or anything. | 20:07 |
| sean-k-mooney | melwitt: you started looking at mikal's serise last cycle can you take anotoehr pass this cycle? | 20:07 |
| 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:07 |
| 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:08 |
| 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 |
| sean-k-mooney | is it this one https://review.opendev.org/c/openstack/nova/+/927354/8/nova/virt/libvirt/driver.py#6790 | 20:09 |
| sean-k-mooney | i have not read it but seems to be the only open comment | 20:09 |
| sean-k-mooney | oh its askign what happens if the requeted number fo usb prots is larger the the model supprot | 20:10 |
| sean-k-mooney | my guess is livbirt will complain and we will fail to define the domain | 20:10 |
| mikal | Yeah, that's the one. | 20:10 |
| mikal | I need to do some testing there. | 20:11 |
| sean-k-mooney | if we knwo or cna detect the limit perhaps via virsh domcapablities | 20:11 |
| 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 |
| 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 |
| 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 |
| sean-k-mooney | that or have a cofnig option that default to the same value | 20:12 |
| mikal | It shouldn't be dozens of devices I wouldn't think. | 20:12 |
| mikal | Yeah. | 20:13 |
| sean-k-mooney | ya so 8-10 proably | 20:13 |
| 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 |
| sean-k-mooney | yep | 20:13 |
| mikal | (As long as the simple thing is compatible with whatever we think might be a valid future thing) | 20:13 |
| 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 |
| sean-k-mooney | you coudl likely set a limit here 'hw_redirected_usb_ports': fields.IntegerField(), | 20:14 |
| sean-k-mooney | of like 10 | 20:14 |
| sean-k-mooney | but it would proably be better to do that in the driver then the object | 20:14 |
| mikal | I can do some reading on the capabilities of the various USB controllers in libvirt today. | 20:15 |
| sean-k-mooney | this is perhaps somethin that could be a followup patch on top by the way | 20:16 |
| mikal | Yeah, that would be my preference. Happy to work on it, don't really want to block on it though. | 20:17 |
| 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:17 |
| 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 |
| sean-k-mooney | but they dont document the limtis so i feel like this will be a qemu limit | 20:18 |
| mikal | Herm. That sounds like "read the qemu code" territory... | 20:18 |
| sean-k-mooney | i think the usb sepc allwos somehting like 256 device but i highly doubt qemu supprots that | 20:19 |
| sean-k-mooney | ok ill chat to you tomorrow o/ | 20:19 |
| mikal | Thanks Sean, sorry if I made you late for anything. I appreciate the chat. | 20:20 |
| sean-k-mooney | https://qemu-project.gitlab.io/qemu/system/devices/usb.html#physical-port-addressing | 20:21 |
| 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:21 |
| sean-k-mooney | so 8 unless you use hubs so ya i would limit to 8 for now | 20:22 |
| 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:22 |
| sean-k-mooney | usb can have a tree for device below the root port up to 8 level deep i belive | 20:23 |
| 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:23 |
| sean-k-mooney | https://www.youtube.com/watch?v=hiwaxlttWow | 20:24 |
| mikal | Heh. Actionable advice right here. | 20:25 |
| mikal | s/here/there/ | 20:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!