| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-30 | |||
| 17:17:28 | sean-k-mooney | but you all out thing like "An RLock is used per database because a single thread may nest writer | |
| 17:17:30 | sean-k-mooney | transactions against the same engine facade." | |
| 17:18:20 | gibi | and that is exactly what an RLock is for :) | |
| 17:18:48 | sean-k-mooney | and its also one of the thing build into the FairlockGurads constaitns | |
| 17:18:54 | sean-k-mooney | ill upgarde to a +2 for now | |
| 17:19:19 | sean-k-mooney | but if this proves unstabel i would prefrer ot adotp the FairLockGuard instead fo theying ot fix this implemetion | |
| 17:19:28 | sean-k-mooney | gibi: does that work for you | |
| 17:20:54 | gibi | if the instability is due to a problem that is solved by the fairlockguard then yes it is good for me | |
| 17:22:28 | sean-k-mooney | patchset 8 was created 21 days ago | |
| 17:22:43 | sean-k-mooney | so that before your shutdown speedup patch landed yes | |
| 17:23:11 | sean-k-mooney | so we woudl execte a new run to also be faster | |
| 17:23:47 | sean-k-mooney | or rather the thereaded and eventet version shoudl be closer now | |
| 17:41:23 | jgilaber | sean-k-mooney, so after clearing the cache the functional tests are green again https://zuul.opendev.org/t/openstack/buildset/6a7d3edc4ae84ba7b33487e037f1acc5 | |
| 17:41:50 | sean-k-mooney | jgilaber: with an without that change i was not able to cause it to fial locally | |
| 17:41:56 | sean-k-mooney | i still have it runingin the backgorund | |
| 17:42:20 | sean-k-mooney | but if ci is happy i guess that is progress | |
| 17:43:31 | jgilaber | yeah, I don't like that I don't know what was wrong there, but good to advance | |
| 17:44:15 | jgilaber | I guess CI harware is slower than our local machines and caused the problem to surface somehow | |
| 17:44:58 | sean-k-mooney | yes that happens | |
| 17:45:44 | sean-k-mooney | you can sort of emulatie that by messign with some of the test teimouts | |
| 17:46:03 | sean-k-mooney | but then its hard to tell if tis a real failure or not | |
| 17:47:59 | gmaan | gibi: you have time to talk about unify the executors get/destroy comment https://review.opendev.org/c/openstack/nova/+/998571/comment/23f68a57_21843d10/ | |
| 17:48:16 | gmaan | if you are done for the day, I can add comment on gerrit and we can discuss there or tomorrow | |
| 18:01:01 | opendevreview | Merged openstack/nova master: tests: Use per-database write locks instead of global lock https://review.opendev.org/c/openstack/nova/+/992862 | |
| 19:22:58 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Fix deny_share host locality for NFS https://review.opendev.org/c/openstack/nova/+/998752 | |
| 19:22:58 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 19:54:06 | Zhan[m] | Hi friends, recently I found a somewhat tricky bug with live migration: https://bugs.launchpad.net/nova/+bug/2160728. Wondering if I can get some feedbacks on it and I can work on the fix too, thanks! | |
| 22:47:33 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Allow rebuild for instances with virtiofs shares https://review.opendev.org/c/openstack/nova/+/999048 | |
| #openstack-nova - 2026-07-31 | |||
| 01:45:38 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 01:45:39 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 02:02:22 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 02:02:23 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633 | |
| 07:35:17 | gibi | gmaan: sorry I was already done for the day at that point yesterday. | |
| 08:03:40 | opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | |
| 08:25:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: check tempest for instability https://review.opendev.org/c/openstack/nova/+/999378 | |
| 09:30:53 | opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | |
| 09:30:53 | opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | |
| 09:34:32 | opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | |
| 10:20:32 | opendevreview | Roman Hros proposed openstack/nova master: Delete inactive port bindings during live migration https://review.opendev.org/c/openstack/nova/+/999374 | |
| 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: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 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 | |
| 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: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: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: Extract share management from ComputeManager https://review.opendev.org/c/openstack/nova/+/999349 | |
| 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: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: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | |
| 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 | |
| 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. | |