Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-12-04
15:39:55 sean-k-mooney and sure we culd make that declarbale in some way vai a file or config option where we cant dicusver it easily.
15:40:36 dansmith sean-k-mooney: yes, I called out storage_type specifically because we can't know.. we _can_ know storage_fsid
15:40:45 sean-k-mooney ack
15:41:09 dansmith man, I do not get it..
15:41:13 sean-k-mooney oh you mean each compute cant know that its shared even if its nfs
15:41:18 sean-k-mooney oh ya your right
15:41:23 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132
15:41:24 dansmith correct
15:41:33 dansmith sometimes I load the spec and gerrit shows me tons of unresolved comments and other times, not.
15:41:43 sean-k-mooney ya...
15:41:52 sean-k-mooney i noticed that too for the last few days
15:42:04 sean-k-mooney i dont know if its a recent regression or browswer caching
15:45:47 gibi dansmith: heh we have a convoluted way already in place to detect early end of the thread. The code adds a callback to the future to execute when it finishes. That callback sets finish_event (which is an Event) that is passed into the monitoring loop and checked there https://github.com/openstack/nova/blob/5d3d0c870a1c37dcd6ce9cd0d542282c7c7994f3/nova/virt/libvirt/driver.py#L11405
15:46:24 gibi so the monitoring loop detects the early end of the thread via that event
15:46:26 dansmith gibi: that detects when the future ends yes, but doesn't care why
15:46:30 gibi (still it does not collect the resutl)
15:46:32 dansmith right
15:46:34 dansmith yep
15:47:09 dansmith gibi: fwiw, I wasn't actually seeing that callback be called when I was pdb'ing the unit test
15:47:20 dansmith but that might be specific to the unit test environment or something
15:47:35 gibi the unit test fixture calles the callback right when it is registered :/
15:47:57 dansmith ah
15:48:16 gibi that fixture is suboptimal to serve the unit test needs
15:48:44 gibi OK. I'm convinced enough now that collecting the result after the monitor make sense
15:49:33 dansmith do we actually need the convoluted done event? is that maybe to give the same behavior in both models or something, instead of just checking future.done?
15:50:35 gibi as far as I think we don't need the convoluted way, we can just use future.done instead within the monitor
15:51:01 dansmith okay that might be better anyway then
15:51:03 gibi using the future directly removes the callback which is a nice symplification
15:51:14 dansmith yup
15:51:48 gibi I have context now should I just pick you patch up and update it? or you would like to do it?
15:53:12 dansmith you're welcome to, but if you need to do other stuff I can do it also
15:53:48 gibi I take it. I need to write some code to keep my sanity :)
15:54:13 dansmith yeah, I've been just reviewing for weeks now.. sanity gone :(
16:21:27 gmaan dansmith: gibi: bauzas: I did one ammended in graceful shutdown backlog spec as spec3, please check. it is for backlog only and to keep it out of scope from the scope of this cycle spec https://review.opendev.org/c/openstack/nova-specs/+/969543
16:22:43 gibi gmaan: make sense to me thanks.
16:30:03 opendevreview sean mooney proposed openstack/nova-specs master: add spec for resource tracker notifications https://review.opendev.org/c/openstack/nova-specs/+/967712
16:48:00 opendevreview Ghanshyam proposed openstack/nova-specs master: Follow up fixes for graceful shutdown spec https://review.opendev.org/c/openstack/nova-specs/+/969813
16:50:08 gmaan gibi: bauzas ^^ quick follow up for fixing some comments
16:51:04 gmaan and thanks dansmith sean-k-mooney gibi bauzas for review and help on the shaping graceful shutdown specs.
16:52:47 gmaan ratailor: most probably it is missing schema but let me review todaty
17:07:07 opendevreview Merged openstack/nova-specs master: Follow up fixes for graceful shutdown spec https://review.opendev.org/c/openstack/nova-specs/+/969813
17:18:46 opendevreview sean mooney proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support https://review.opendev.org/c/openstack/nova-specs/+/967515
17:22:58 sean-k-mooney bauzas: gibi i adresss bogdans feedback and the other open comments if you have time to review that too.
17:51:09 opendevreview Balazs Gibizer proposed openstack/nova master: Collect result of _live_migration_operation https://review.opendev.org/c/openstack/nova/+/969501
18:08:13 opendevreview sean mooney proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support https://review.opendev.org/c/openstack/nova-specs/+/967515
18:17:21 opendevreview Jay Faulkner proposed openstack/nova stable/2024.2: [ironic] Ensure unprovision happens for new states https://review.opendev.org/c/openstack/nova/+/969833
18:17:39 JayF The next step backport for the ironic bugfix, for your consideration ^^^^ :) thank you!
19:06:05 melwitt dansmith: EZ io=native config patch that you have expressed some interest before 😇 https://review.opendev.org/c/openstack/nova/+/964848
19:12:20 dansmith oh yeah I literally have it open already
19:12:39 dansmith I shall hit for sure eventually
19:13:15 sean-k-mooney the only concern i have with that
19:13:15 melwitt :)
19:13:28 sean-k-mooney is live migration btween host with diffent values
19:13:50 sean-k-mooney i assume we need to make sure we do not change the mode during a live mifation
19:13:56 sean-k-mooney *migration
19:14:14 sean-k-mooney its ok if it change on hard reboot or cold migraion
19:15:19 sean-k-mooney melwitt: did you try that
19:15:47 sean-k-mooney we coudl also tweak one of the zuul jobs to enable this
19:16:53 melwitt no, I did not
19:16:54 sean-k-mooney for example the normal nova-live-migration job which uses iscsi
19:17:52 melwitt yeah that sounds like it would be easy to try, just configure the subnode different and run the job?
19:18:28 sean-k-mooney yep
19:18:51 sean-k-mooney we have live_migration_back_and_forth enabled in that job
19:18:52 melwitt in general I wasn't thinking config like this would be different than two computes having various config not matching but maybe none of the others affect xml
19:19:10 sean-k-mooney so if you enable it on one or both host it will give us interesting data
19:19:30 melwitt ok, I'll try it
19:20:06 sean-k-mooney well libvirt might not care im currnetly tying to see if this is confire a backend option or not
19:22:01 sean-k-mooney some thing it will happly allow change in a live migrtion and others it wont an i have never played with seting io="threads" vs io="native" ectra difently on a migration
19:23:20 sean-k-mooney melwitt: related question do we just let libvit choose for local disks or is that also hardcoded to native today
19:24:58 melwitt sean-k-mooney: yes local disks are left to default. this io=native hard-coded thing is only for iSCSI, NFS, and FC Cinder volumes
19:25:29 sean-k-mooney ack
19:25:59 melwitt it comes from this spec from mitaka https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/libvirt-aio-mode.html
19:27:11 sean-k-mooney ya i was asking ai about libvirt io modes and that actullythe firt link it found
19:27:53 sean-k-mooney so it seam like we did adopt the best practices that were recommend at the tiem and optied into native but we pessimsed some backend so the change makes sens
19:28:38 melwitt oh heh
19:29:24 sean-k-mooney number 2 was https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_tuning_and_optimization_guide/sect-virtualization_tuning_optimization_guide-blockio-io_mode which is a littel more useful but im actully surpised this is not coverd in the libvirt domain xml docs
19:29:41 sean-k-mooney they are useable pretty good at docuemtning the difent values
19:31:52 melwitt yeah I guess it only says "The optional io attribute controls specific policies on I/O; qemu guests support "threads" and "native" Since 0.8.8, io_uring Since 6.3.0 (QEMU 5.0)." in https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms
19:32:57 sean-k-mooney ah yep just roudn it deep in the driver section
19:33:20 sean-k-mooney unfortuetly you cant deep link that far into the doc
19:33:44 sean-k-mooney io_uring support could be very interesting in teh future
19:34:14 melwitt yeah I wish their doc pages had more fine grain links
19:39:08 sean-k-mooney https://kb.blockbridge.com/technote/proxmox-aio-vs-iouring/ is interesting but i have not had time to read i tyet
19:39:46 sean-k-mooney finding 1 "IOThreads significantly improve performance for most workloads" well i guess its a good thing we are finally going to turn them on
19:42:02 melwitt haha yeah. I saw similar things when i first started reading up on io=native vs io=threads
19:42:39 opendevreview melanie witt proposed openstack/nova master: DNM test io=threads => io=native live migration https://review.opendev.org/c/openstack/nova/+/969844
19:47:00 gmaan ratailor if you see it when online. I commented in tempest change. maybe you can run the same tests which is executing same action on isntance in your devstack end and see why finsih_time is None - https://review.opendev.org/c/openstack/tempest/+/953331
19:47:23 opendevreview melanie witt proposed openstack/nova master: DNM test io=threads => io=native live migration https://review.opendev.org/c/openstack/nova/+/969844
19:48:10 gmaan there should be difference between API, action you call via tempest test or osc but somewhere it is missing the recording of finish time.
19:52:12 sean-k-mooney gmaan: os that comment thread on the swap voluem one only show up on v2 for me
19:52:29 sean-k-mooney i didnt see that in the latest revsion at all when i went to revie it
19:53:51 gmaan sean-k-mooney: yeah, there are multiple way to do lile task state as melwitt suggested early or checking migration status or based on request (your latest comment). but we should not make RPC call whenever we have GET volume attachment call
19:54:27 sean-k-mooney ya i agree
19:54:43 gmaan and that is something we need to agree as design in spec and should not delay to implementation.
19:54:50 sean-k-mooney i just didnt see that rad on the spec yestready because the commens are not propagating the way i expect
19:54:55 melwitt gmaan: yeah, thanks for commenting on that spec. it seemed crazy to me to do the RPC call about swap progress every time when 99% of the time no swap would be in progress
19:55:06 gmaan true
19:56:09 gmaan sean-k-mooney: comment propagation in gerrit is really weird. i hate that many times :)
19:58:08 gmaan last spec I am going through today is rajesh finish_time one, and previous comments are all lost there either due to Gerrit or they are marked resolved before agreement was reached. that is adding more time to review specs
20:02:20 sean-k-mooney ya i normlly try not to mark thing resovled unlless i made the change that was requested

Earlier   Later