Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-07-31
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.
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 Uggla #startmeeting nova
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 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 opendevmeet The meeting name has been set to '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.
16:03:39 Uggla #info Please try to provide a meaningful comment when you recheck
16:03:52 fwiesel o/
16:04:10 Uggla I have just look quickly at the gate. That looks ok. Anything to say ?
16:05:10 Uggla seems not, moving on
16:05:11 Uggla #topic Release Planning
16:05:19 Uggla #link https://releases.openstack.org/hibiscus/schedule.html
16:05:26 Uggla #info Nova deadlines are set in the above schedule
16:05:33 elodilles (just a heads-up that 2027.1 Indri release schedule is available: https://releases.openstack.org/indri/schedule.html )
16:05:34 Uggla #info PTG etherpad for 2026.2 is available: https://etherpad.opendev.org/p/nova-2026.2-ptg
16:05:49 Uggla #info Tomorrow is first Nova Implementation Review Day
16:06:13 Uggla I think I'll have a look at the virtiofs cold migration.
16:06:36 Uggla #topic Review priorities
16:06:44 Uggla #link New file for Hibiscus https://etherpad.opendev.org/p/nova-2026.2-status
16:06:49 Uggla #info I have updated Launchpad and the above doc. Please ping me if you spot something missing.
16:06:55 Uggla #info Starting: https://etherpad.opendev.org/p/nova-2026.2-status#L16 interesting bugs to review.
16:07:07 Uggla #topic Stable Branches
16:07:19 elodilles thanks

Earlier   Later