| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-31 | |||
| 10:34:15 | ralonsoh | sean-k-mooney, hi! will you have some time to talk about https://bugs.launchpad.net/nova/+bug/2161894? | |
| 10:34:38 | ralonsoh | In particular about `create_tap`!=`ovs_create_tap` | |
| 10:38:21 | sean-k-mooney | sure am are you free now ish, or at the top of the hour? | |
| 10:38:34 | sean-k-mooney | i was going to go grab a coffee quickly | |
| 10:38:56 | sean-k-mooney | but we can chat in say 5 mins | |
| 10:39:41 | ralonsoh | perfect | |
| 10:51:51 | sean-k-mooney | those https://meet.google.com/nbj-ernx-ymb work for you other are fee to join to we will be talking about https://bugs.launchpad.net/nova/+bug/2161894 a live migration instablity with ml2/ovs | |
| 12:51:17 | opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | |
| 17:21:53 | gmaan | gibi: no issue, I commented on the change, I think doing option 3 (moving all thread/executors things in a separate file) will make it easy to maintain in long term | |
| 17:22:18 | gmaan | anyways, will wait for your feedback before I start doing the modification | |
| 18:29:18 | gmaan | dansmith: thanks for review graceful shutdown change, I replied please check, mainly for this comment if the approach i replied is ok https://review.opendev.org/c/openstack/nova/+/996299/comment/5c3a3d23_ff206cc3/ | |
| 18:30:51 | gmaan | for revert_resize I think making dest revert_resize idempotent will work, but I will handle that in separate change with functional reproducer test | |
| 18:36:29 | dansmith | gmaan: reading but just realizing I forgot to delete half a sentence in there :/ | |
| 18:46:54 | dansmith | gmaan: replied | |
| 18:58:00 | gmaan | dansmith: thanks, for task end. I end task for both success and failure case. do you think recording the status also can be useful for shutdown case? we will be returning the erorr to users in that case but in case that is missed as we are shutting down, having tasks failed can be useful for users to trigger them again? | |
| 18:58:50 | dansmith | gmaan: you mean logging what tasks failed during shutdown right? | |
| 18:58:57 | gmaan | yeah | |
| 18:59:07 | dansmith | yeah, definitely seems good to log that stuff | |
| 18:59:31 | gmaan | ok, will add that | |
| 18:59:58 | dansmith | on the multiple end thing, I'm really just saying that if we expect one start and one end for each task, but we get a second end it might mean we raced or lost track of something and so it'd be good to flag it .. if it is expected for some reason then no need | |
| 19:02:08 | gmaan | ah i see yeah missed to record start task is good point. | |
| 19:04:42 | dansmith | yeah exactly | |
| 20:51:35 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Fix deny_share host locality for NFS https://review.opendev.org/c/openstack/nova/+/998752 | |
| 21:44:52 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 21:44:52 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 22:01:48 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 22:01:48 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 22:12:48 | opendevreview | Ghanshyam Maan proposed openstack/nova master: Task tracking mechanism for graceful shutdown https://review.opendev.org/c/openstack/nova/+/996299 | |
| 22:21:42 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 22:21:42 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 22:46:21 | opendevreview | Ghanshyam Maan proposed openstack/nova master: Call manager graceful_shutdown while RPC server waits https://review.opendev.org/c/openstack/nova/+/996583 | |
| 22:46:36 | gmaan | dansmith: updated the changes. Its public holiday here on Monday so will be checking it back on tuesday | |
| #openstack-nova - 2026-08-03 | |||
| 02:19:33 | opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: bindep: Remove stale marker https://review.opendev.org/c/openstack/python-novaclient/+/999529 | |
| 05:55:56 | opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | |
| 06:12:21 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Allow rebuild for instances with virtiofs shares https://review.opendev.org/c/openstack/nova/+/999048 | |
| 06:36:20 | 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:20 | opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | |
| 13:46:56 | opendevreview | Sylvain Bauza proposed openstack/nova master: doc: Document postcopy incompatibility with vGPU live migration https://review.opendev.org/c/openstack/nova/+/999607 | |
| 13:49:04 | 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:51:43 | 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 | |
| 14:43:16 | 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:45:23 | dansmith | uhm | |
| 14:45:49 | 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:46:06 | melwitt | so is it really worse than checking in say conductor or some other point 🤔 | |
| 14:46:41 | melwitt | it will add a trait on the request _if_ min service version is sufficient | |
| 14:47:12 | dansmith | min service across all computes/cells I guess? | |
| 14:47:17 | melwitt | yes | |
| 14:50:08 | 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:51:54 | 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:55:05 | 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:56:28 | melwitt | I believe so ... jgilaber please correct me if I'm wrong | |
| 14:59: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, | |
| 15:00:05 | dansmith | which means we'd select some of cyborg's devices right? | |
| 15:00:37 | 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:01:03 | dansmith | and in that case, I dunno... might be better to have config I guess | |
| 15:01:34 | 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:09:35 | jgilaber | dansmith, melwitt Hi! Reading back a bit | |
| 15:09:49 | 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:10:03 | 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:31 | jgilaber | Right now this would affect two kind of devices, pci passthrough and vgpus, which could be configured in both Nova and Cyborg | |
| 15:11:08 | Uggla | sambork, ok no pb. I will paste the info during the meeting. Thx. | |
| 15:11:15 | jgilaber | the idea of my patch is to start adding the OWNER_NOVA trait to all Nova-managed resource providers | |
| 15:11:34 | jgilaber | but only require it after all compute services are upgraded | |
| 15:12:37 | jgilaber | right now this is left as the operators responsibilty to configure both services correctly so conflicts do not occurr | |
| 15:12:59 | dansmith | jgilaber: but there can be no cyborg-provided devices in the tree until that happens, agreed? | |
| 15:14:41 | jgilaber | no, currently there can be cyborg managed devices | |
| 15:16:23 | sambork | Uggla, thanks! | |
| 15:16:50 | dansmith | jgilaber: without problems? if so, I'm not sure what problem the extra pre-filtering will resolve | |
| 15:17:07 | dansmith | your spec says "to prevent collisions" so that tells me there _would_ be problems | |
| 15:22:48 | jgilaber | yes, there would be problems indeed | |
| 15:24:57 | 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:25:21 | dansmith | just the after case where we need to make sure to never find cyborg devices *once* they start being reported | |
| 15:26:15 | jgilaber | in this concrete case, the version check is to avoid requiring the owner trait before it's added | |
| 15:26:42 | jgilaber | it protects against nova becoming unable to schedule resources, not against nova-cyborg conflicts | |
| 15:26:53 | 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:27:32 | 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:28:12 | jgilaber | that's right | |
| 15:28:46 | jgilaber | althought the proposal was to add the trait to all nova resource providers, not only mdevs | |
| 15:35:04 | 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:36:50 | 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:38:42 | Uggla | Reminder, upstream meeting in ~20mn | |
| 16:00:10 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:10 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:10 | 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:10 | Uggla | #startmeeting nova | |
| 16:00:19 | Uggla | Hello everyone | |
| 16:00:34 | bauzas | o/ and welcome back | |
| 16:00:39 | dansmith | o/ | |
| 16:00:40 | elodilles | o/ | |
| 16:00:48 | Leo[m] | o/ | |
| 16:01:07 | tkajinam | o/ | |
| 16:01:21 | lajoskatona | o/ | |
| 16:02:32 | Uggla | Let's start | |
| 16:02:47 | Uggla | #topic Bugs (stuck/critical) | |
| 16:02:52 | Uggla | #info No Critical bug | |
| 16:03:02 | Uggla | #topic Gate status | |
| 16:03:10 | Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:03:19 | Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:03:26 | 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:34 | Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |