| opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: bindep: Remove stale marker https://review.opendev.org/c/openstack/python-novaclient/+/999529 | 02:19 |
|---|---|---|
| opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | 05:55 |
| opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Allow rebuild for instances with virtiofs shares https://review.opendev.org/c/openstack/nova/+/999048 | 06:12 |
| opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | 06:36 |
| opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | 06:36 |
| *** haleyb|out is now known as haleyb | 13:27 | |
| opendevreview | Sylvain Bauza proposed openstack/nova master: doc: Document postcopy incompatibility with vGPU live migration https://review.opendev.org/c/openstack/nova/+/999607 | 13:46 |
| bauzas | gibi: sean-k-mooney: I have a doc patch that's quite simple to review https://review.opendev.org/c/openstack/nova/+/999607 tl;dr: postcopy isn't supported for mdev live-migrations so we need to doc it | 13:49 |
| sean-k-mooney[m] | ill review it tomorow its a public holiday today but as far as i recall post copy is disabled by default upstream | 13:51 |
| *** ykarel_ is now known as ykarel | 14:00 | |
| melwitt | dansmith: I wondered what is your opinion about scatter gather min service version check in a placement request filter? my initial reaction thought it's a bad idea but the more I think about it, it would run only once per scheduling request and would not run on retries because of the pre-calculation of host alternates | 14:43 |
| dansmith | uhm | 14:45 |
| dansmith | you mean in a request filter, which normally makes a change for placement but which would just do a service-version-based alteration instead? | 14:45 |
| melwitt | so is it really worse than checking in say conductor or some other point 🤔 | 14:46 |
| melwitt | it will add a trait on the request _if_ min service version is sufficient | 14:46 |
| dansmith | min service across all computes/cells I guess? | 14:47 |
| melwitt | yes | 14:47 |
| dansmith | what would be the use-case? I think normally we don't even allow a request for a thing if the cluster is not fully upgraded (which I assume is what you're asking for) so letting it continue and just not select for a thing seems a bit weird | 14:50 |
| melwitt | yeah, this is a weird one and it's throwing me off. it's for this spec https://specs.openstack.org/openstack/nova-specs/specs/2026.2/approved/cyborg-vgpu-support.html basically if the cluster is upgraded start requiring the OWNER_NOVA trait | 14:51 |
| dansmith | I'm a bit confused .. OWNER_NOVA would mean that nova owns it not cyborg.. are you talking about to start filtering out the ones that cyborg is reporting so what works today continues to work and doesn't find cyborg's devices? | 14:55 |
| melwitt | I believe so ... jgilaber please correct me if I'm wrong | 14:56 |
| dansmith | that seems problematic as an upgrade mitigation, because if cyborg was reporting things before we're upgraded, we're not going to request the trait, but we can't because the computes aren't upgraded, | 14:59 |
| dansmith | which means we'd select some of cyborg's devices right? | 15:00 |
| dansmith | I think you need to not report cyborg devices into placement that nova might find until all the computes are upgraded and we start filtering them out | 15:00 |
| dansmith | and in that case, I dunno... might be better to have config I guess | 15:01 |
| dansmith | otherwise you're sort of paying that service version lookup penalty all the time for something that can't really be graceful (although I guess it should be cached so maybe not a huge deal) | 15:01 |
| jgilaber | dansmith, melwitt Hi! Reading back a bit | 15:09 |
| jgilaber | So the original proposal for this comes back from zed https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html | 15:09 |
| sambork | Uggla, I can't participate in today's nova meeting, so I will paste my update now, especially since there hasn't been much change since last week: Not much to update. This week's eventlet-removal work in Nova was dominated by test work: gibi is trying to make the functional-py313-threading job voting (#997216), while a refactor replacing StaticallyDelayingWrapper with a futurist-based executor (#997410) is under review | 15:10 |
| jgilaber | Right now this would affect two kind of devices, pci passthrough and vgpus, which could be configured in both Nova and Cyborg | 15:10 |
| Uggla | sambork, ok no pb. I will paste the info during the meeting. Thx. | 15:11 |
| jgilaber | the idea of my patch is to start adding the OWNER_NOVA trait to all Nova-managed resource providers | 15:11 |
| jgilaber | but only require it after all compute services are upgraded | 15:11 |
| jgilaber | right now this is left as the operators responsibilty to configure both services correctly so conflicts do not occurr | 15:12 |
| dansmith | jgilaber: but there can be no cyborg-provided devices in the tree until that happens, agreed? | 15:12 |
| jgilaber | no, currently there can be cyborg managed devices | 15:14 |
| sambork | Uggla, thanks! | 15:16 |
| dansmith | jgilaber: without problems? if so, I'm not sure what problem the extra pre-filtering will resolve | 15:16 |
| dansmith | your spec says "to prevent collisions" so that tells me there _would_ be problems | 15:17 |
| jgilaber | yes, there would be problems indeed | 15:22 |
| dansmith | okay I'm not really sure how we went wrong here... my point is that today they can't be mixed without problems, so there's no sort of "before" scenario we need to protect across an upgrade boundary, | 15:24 |
| dansmith | just the after case where we need to make sure to never find cyborg devices *once* they start being reported | 15:25 |
| jgilaber | in this concrete case, the version check is to avoid requiring the owner trait before it's added | 15:26 |
| jgilaber | it protects against nova becoming unable to schedule resources, not against nova-cyborg conflicts | 15:26 |
| dansmith | I guess doing a service version check to determine if we _can_ always select for OWNER_NOVA is okay, although it's sort of unfortunate to have to do that extra bit of expensive work | 15:26 |
| dansmith | the assumption is that even if you never use cyborg, all nova's mdev devices will be reported with that trait henceforth so after we're past the upgrade boundary we can just always require that trait for everyone right? | 15:27 |
| jgilaber | that's right | 15:28 |
| jgilaber | althought the proposal was to add the trait to all nova resource providers, not only mdevs | 15:28 |
| lajoskatona | sean-k-mooney: Hi, there is a patch ( https://review.opendev.org/c/openstack/nova/+/982085) for https://bugs.launchpad.net/nova/+bug/2051685 (After repeat of incomplete migration nova applies wrong (status=error) migration context in update_available_resource periodic job) | 15:35 |
| lajoskatona | sean-k-mooney: and a reproducer functional test under the commit. As I remember we had a chance to have a short chat about it, if you have time can you please check it? Bence / rubasov started to work on it but He was moved to another project so I am kind of responsible for it now :) | 15:36 |
| Uggla | Reminder, upstream meeting in ~20mn | 15:38 |
| Uggla | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Mon Aug 3 16:00:10 2026 UTC and is due to finish in 60 minutes. The chair is Uggla. 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 |
| Uggla | Hello everyone | 16:00 |
| bauzas | o/ and welcome back | 16:00 |
| dansmith | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| Leo[m] | o/ | 16:00 |
| tkajinam | o/ | 16:01 |
| lajoskatona | o/ | 16:01 |
| Uggla | Let's start | 16:02 |
| Uggla | #topic Bugs (stuck/critical) | 16:02 |
| Uggla | #info No Critical bug | 16:02 |
| Uggla | #topic Gate status | 16:03 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:03 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:03 |
| Uggla | #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:03 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:03 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:03 |
| fwiesel | o/ | 16:03 |
| Uggla | I have just look quickly at the gate. That looks ok. Anything to say ? | 16:04 |
| Uggla | seems not, moving on | 16:05 |
| Uggla | #topic Release Planning | 16:05 |
| Uggla | #link https://releases.openstack.org/hibiscus/schedule.html | 16:05 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:05 |
| elodilles | (just a heads-up that 2027.1 Indri release schedule is available: https://releases.openstack.org/indri/schedule.html ) | 16:05 |
| Uggla | #info PTG etherpad for 2026.2 is available: https://etherpad.opendev.org/p/nova-2026.2-ptg | 16:05 |
| Uggla | #info Tomorrow is first Nova Implementation Review Day | 16:05 |
| Uggla | I think I'll have a look at the virtiofs cold migration. | 16:06 |
| Uggla | #topic Review priorities | 16:06 |
| Uggla | #link New file for Hibiscus https://etherpad.opendev.org/p/nova-2026.2-status | 16:06 |
| Uggla | #info I have updated Launchpad and the above doc. Please ping me if you spot something missing. | 16:06 |
| Uggla | #info Starting: https://etherpad.opendev.org/p/nova-2026.2-status#L16 interesting bugs to review. | 16:06 |
| Uggla | #topic Stable Branches | 16:07 |
| * Uggla giving the mic to elodilles | 16:07 | |
| elodilles | thanks | 16:07 |
| elodilles | #info osc-placement's stable/2025.2 and stable/2025.1 gate is blocked by tox-docs job - fix: https://review.opendev.org/c/openstack/osc-placement/+/998816 | 16:07 |
| elodilles | i'll backport the fix when this has landed ^^^ | 16:07 |
| elodilles | #info other stable gates should be OK | 16:07 |
| elodilles | at least i'm not aware of any issue | 16:07 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:08 |
| * elodilles passes back the mic to Uggla | 16:08 | |
| Uggla | thx elodilles | 16:08 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:08 |
| elodilles | np | 16:08 |
| Uggla | fwiesel, something to share ? | 16:08 |
| fwiesel | Hi, no news from my side, except that I will be on PTO until September | 16:08 |
| Uggla | thx, enjoy your PTO | 16:09 |
| fwiesel | thx | 16:09 |
| Uggla | #topic Kamil's news about eventlet removal | 16:09 |
| Uggla | Neither Kamim not gibi are available today, but Kamil gave an update earlier: | 16:10 |
| Uggla | Not much to update. This week's eventlet-removal work in Nova was dominated by test work: gibi is trying to make the functional-py313-threading job voting (#997216), while a refactor replacing StaticallyDelayingWrapper with a futurist-based executor (#997410) is under review | 16:10 |
| Uggla | #topic Nova using openstack sdk for neutron | 16:11 |
| Uggla | hello lajoskatona, something to share today ? | 16:11 |
| lajoskatona | Hi, | 16:11 |
| lajoskatona | the actually what I shared last week: I added option to SDK to have filtering option for fields | 16:12 |
| lajoskatona | https://review.opendev.org/c/openstack/openstacksdk/+/995724 | 16:12 |
| lajoskatona | with this we can do the same low-cost API requestst toward Neutron like it happened with neutronclient | 16:12 |
| lajoskatona | that's it actually for this topic from me | 16:13 |
| Uggla | thx lajoskatona | 16:13 |
| Uggla | #topic Confidential computing, status of SNP and TDX features | 16:13 |
| Uggla | tkajinam, antia something you'd like to share ? | 16:14 |
| antia | Got a TDX vm up and running. Will add some documentation to go with it. | 16:14 |
| Uggla | antia cool ! | 16:14 |
| tkajinam | I've not yet checked https://review.opendev.org/c/openstack/nova/+/999249 but will review it later this week | 16:15 |
| Uggla | I understood SNP is merged now, so nothing remaining on that side ? | 16:16 |
| tkajinam | yeah, nothing from nova's perspective | 16:16 |
| Uggla | tkajinam cool thanks for all this work. | 16:17 |
| tkajinam | though I've found a few problems with ovmf in ubuntu 26.04 package. in case anyoen is interested please check https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2161231 and https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2160129 | 16:17 |
| tkajinam | at this moment c10s would be a better choice, it seems | 16:17 |
| Uggla | tkajinam good to know thanks | 16:18 |
| Uggla | anything else ? | 16:19 |
| tkajinam | nothing from my end | 16:19 |
| Uggla | ok moving on | 16:19 |
| Uggla | #topic Bug scrubbing | 16:20 |
| Uggla | #info 80 open bugs | 16:20 |
| Uggla | #link https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:20 |
| Uggla | #link https://truc.uggla.fr/ to follow the trend. | 16:20 |
| Uggla | Next meeting (this week): [public] Upstream bug triage. Wednesday, August 5th · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj | 16:20 |
| Uggla | i'll try to sync it probably tomorrow. | 16:20 |
| Uggla | #topic Open discussion | 16:21 |
| Uggla | nothing listed on the agenda. | 16:21 |
| Leo[m] | Hello. My apologies, I thought I added this to the open discussion agenda but it appears my change didn’t take. As was decided last week, I wrote a blueprint with possible ways to support hostname-based Ceph Mon references. Here is a link to the blueprint: https://blueprints.launchpad.net/nova/+spec/hostname-mon-references. Please let me know what my next steps should be. Thank you for your time and attention | 16:21 |
| Uggla | Something you'd like to discuss ? | 16:21 |
| Uggla | if not I guess we are done for today. | 16:22 |
| Leo[m] | Could we discuss what the next steps would be for the above ^^? | 16:23 |
| Uggla | oh sorry Leo[m] | 16:23 |
| Uggla | I thought it was from last week | 16:23 |
| Leo[m] | Oh no worries | 16:23 |
| Leo[m] | * Oh, no worries | 16:23 |
| Uggla | I guess the next step it to have a spec, so it could be reviewed at the next PTG. | 16:24 |
| Leo[m] | Sorry, what's a PTG? | 16:25 |
| bauzas | we said last week we should discuss this whether it would be specless or not | 16:25 |
| bauzas | but as we already said too, we're too late for this cycle | 16:25 |
| Uggla | ok, so if specless, no spec required. | 16:25 |
| Uggla | Leo[m], PTG is a long week meeting to prepare the tech topic for next cycle. | 16:26 |
| Uggla | https://openinfra.org/ptg/ | 16:26 |
| dansmith | feels like a spec is warranted, | 16:27 |
| dansmith | because I dunno what would happen if someone flips that config on a live system with some existing instances, etc | 16:27 |
| dansmith | and what upgrade requirements there should be | 16:27 |
| dansmith | or what the implications of reading ceph.conf directly are | 16:27 |
| bauzas | I wasn't saying this is specless, I was referring to the fact last week we were missing quorum | 16:27 |
| Leo[m] | I can write a spec and do more testing on our end. Is there a gut-reaction preference to one of the options? | 16:30 |
| dansmith | not option 3, IMHO | 16:30 |
| dansmith | (gut reaction) | 16:30 |
| Uggla | still no quorum today, but from Dan's questions I guess it would be good to have one. | 16:31 |
| dansmith | but providing the pros/cons of each in the spec will help narrow down the right path | 16:31 |
| tkajinam | +1 | 16:31 |
| tkajinam | we discussed similar concerns during the previous meeting and indicated this may need a spec | 16:32 |
| Leo[m] | Sounds good. Thank you | 16:32 |
| Uggla | Leo[m] 👍 | 16:33 |
| Uggla | something else ? | 16:33 |
| Uggla | so this time I think we are good for today. | 16:35 |
| Uggla | Thanks for joining this meeting. Have a nice day/evening. | 16:35 |
| Uggla | #endmeeting | 16:35 |
| opendevmeet | Meeting ended Mon Aug 3 16:35:27 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:35 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-08-03-16.00.html | 16:35 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-08-03-16.00.txt | 16:35 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-08-03-16.00.log.html | 16:35 |
| elodilles | thanks o/ | 16:35 |
| Leo[m] | thank you o/ | 16:35 |
| lajoskatona | o/ | 16:35 |
| tkajinam | thanks | 16:36 |
| opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Fix deny_share host locality for NFS https://review.opendev.org/c/openstack/nova/+/998752 | 18:11 |
| opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | 18:11 |
| opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | 18:11 |
| clif | I'm trying to run py3 tox target locally on latest master but I'm getting a lot (217) failed unit tests. Is there something I'm supposed to do besides git clone and then tox -epy3? | 19:54 |
| clif | I've made sure I have a completely clean tree | 19:54 |
| clif | One message I'm seeing a lot of in failures: "Exception: This test invokes builtins.open on /sys/module/kvm_amd/parameters/sev. It is bad, you should mock it." | 19:55 |
| dansmith | clif: are you on something other than linux? although from the look of that, I'd guess maybe even being on linux but without SEV support you might hit that | 20:22 |
| dansmith | I'd think the latter would affect CI though | 20:22 |
| clif | linux, fedora specifically | 20:23 |
| dansmith | ack, should work of course.. maybe hit tkajinam knows if something merged recently for the CC stuff that might be related | 20:24 |
| clif | Is there a way to turn off or skip sev specific tests? I'm not familiar with the feature, I *am* running an AMD cpu | 20:25 |
| clif | but a desktop chip, not EPYC | 20:25 |
| JayF | I don't know if practices in Nova are different, but we'd also generally treat a non-mocked read of stuff outta /sys (or proc, or dev, or anything-local) in unit tests as a bug | 20:28 |
| JayF | (in Ironic) | 20:28 |
| dansmith | yep for sure, hence why I'm suggesting it might be a recent merge and the CC people might know of something obvious | 20:37 |
| tkajinam | clif, which commit hash are you using ? | 23:20 |
| clif | 39dc667a1f9a7c12814f5892b900462560b1a229 as of last attemp | 23:27 |
| opendevreview | Seyeong Kim proposed openstack/nova stable/2026.1: Restore 'fork' start method for daemon mode on Python 3.14 https://review.opendev.org/c/openstack/nova/+/999667 | 23:35 |
| opendevreview | Seyeong Kim proposed openstack/nova stable/2025.2: Restore 'fork' start method for daemon mode on Python 3.14 https://review.opendev.org/c/openstack/nova/+/999668 | 23:36 |
| opendevreview | Seyeong Kim proposed openstack/nova stable/2025.1: Restore 'fork' start method for daemon mode on Python 3.14 https://review.opendev.org/c/openstack/nova/+/999669 | 23:36 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!