Earlier  
Posted Nick Remark
#openstack-nova - 2025-10-02
17:07:33 noonedeadpunk I've spotted there's also an scsi blueprint without spec: https://blueprints.launchpad.net/nova/+spec/libvirt-add-support-for-virtio-scsi-multiqueue
17:09:19 noonedeadpunk it seems that these 2 should not be conflicting with each other and I assume both can be implemented?
17:11:14 noonedeadpunk as if I'm not mistaken, that Windows virtio-blk driver is always a single queue, so the way to get any disk performance on windows would be to have scsi and multiqueue there
17:16:15 noonedeadpunk jsut trying to validate if I'm sane and can proceed to working on spec :)
17:16:27 noonedeadpunk (or it could be specless one)
17:17:39 dansmith noonedeadpunk: we have at least three things that are all related, so probably best to have a PTG discussion on it
17:18:02 dansmith domain iothreads, device iothread pinning, and any of these queue things are probably related enough to combine into a single conversation
17:18:05 noonedeadpunk also ports multique I guess?
17:18:16 noonedeadpunk yeah
17:18:20 noonedeadpunk fair enough
19:47:20 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
20:10:26 sean-k-mooney noonedeadpunk: https://review.opendev.org/c/openstack/nova-specs/+/953940 i sthe related one that we created to try and scope down the propsoal to make some progres in 2025.2 but that also got hit by spec freeze
20:11:31 sean-k-mooney noonedeadpunk: im hoping that Masahito will pick up the prosal again this cycle if they have time
20:12:59 sean-k-mooney this was the other thing they were interested in https://review.opendev.org/c/openstack/nova-specs/+/938823
20:14:04 sean-k-mooney so there multiple iothreds, mapping disk queues to iothread and filterign service by netwrok id
20:14:14 sean-k-mooney i dont know which is there priority
20:15:56 sean-k-mooney noonedeadpunk: im just siging off for today but i assuem you want to progress the live migration concurncy feture as well in 2026.1
20:16:12 sean-k-mooney i know there was some code up for that but i lost track for where that review was
20:16:44 sean-k-mooney noonedeadpunk: this was your spec for that https://review.opendev.org/c/openstack/nova-specs/+/955783
20:17:01 sean-k-mooney but i also belive there was a specless blueprint approved indepently?
20:18:19 sean-k-mooney this was your bluepint https://blueprints.launchpad.net/nova/+spec/libvirt-parallel-migrate but https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-parallel
20:18:29 sean-k-mooney was appoved then deferd
20:20:03 sean-k-mooney noonedeadpunk: so we currently have two competing propsoals for this one form you and another form Fabian Wiesel
20:22:58 sean-k-mooney noonedeadpunk: given they have revierd and +1 your versiohn i assume yours is the one that we inteded ot proceed with but we shoudl abandon one fo them and if decied if its goign to be specless or requrie a spec
20:24:41 sean-k-mooney Uggla: fyi ^ do you have any prefernce on which of the two blueprint we use and if we want to proceed specless or not
20:34:16 melwitt sean-k-mooney: do you happen to know if this needs to be changed to something else, perhaps devstack@q-ovn-metadata-agent ? now that q-agt is not used? https://github.com/openstack/nova/blob/master/roles/run-evacuate-hook/tasks/main.yaml#L24
20:35:37 melwitt I'm working on vtpm tempest tests and noticed the error "controller | Unit devstack@q-agt.service could not be found." in the zuul stream
23:10:42 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
23:10:43 opendevreview melanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration https://review.opendev.org/c/openstack/nova/+/962889
23:21:33 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
23:21:33 opendevreview melanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration https://review.opendev.org/c/openstack/nova/+/962889
#openstack-nova - 2025-10-03
07:02:57 noonedeadpunk sean-k-mooney: Uggla fwiw, I also have an implementation for parallel live migrations as well: https://review.opendev.org/c/openstack/nova/+/955784
07:03:59 noonedeadpunk and yeah, I missed the specless one when was working on it :(
07:05:25 bauzas sounds to me a good PTG discussion anyway :)
07:05:51 bauzas it looks like we have a momentum, it would be sad to not having anything for Gazpacho :)
07:06:20 noonedeadpunk and regarding iothreads - I think I have yet another thing to add. or well. there is a specless blueprint already, and I have minimal implementation
07:06:34 noonedeadpunk yeah, totally sounds like a good topic for the PTG
07:06:44 Uggla noonedeadpunk That's a bit sad, to have competing proposal. Anyway yes I agree let's discuss that at PTG.
07:07:28 noonedeadpunk Uggla: they are *exactly* the same
07:07:36 noonedeadpunk so nothing sad I guess
07:08:54 bauzas oh yeah, that just means this should be a good and important effort for this cycle :)
07:08:57 noonedeadpunk I even come up with exactly same config name
07:09:11 noonedeadpunk without seeing yours
07:09:18 Uggla sad because we have to choose one and for one of you, it is a "waste" of time.
07:09:18 bauzas do you read minds ? don't reply, I'm afraid of the answer
07:09:59 bauzas were the competing blueprints both accepted ?
07:10:12 noonedeadpunk neither was so far
07:10:18 noonedeadpunk and one blueprint is specless
07:10:21 noonedeadpunk another has a spec
07:10:34 bauzas if not, that's understandable that two different people can start working on a same feature, while nothing is communicated
07:10:36 noonedeadpunk and given implementation is the same, I don;'t think much time was wasted
07:10:58 noonedeadpunk btw
07:11:12 noonedeadpunk author of https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-parallel voted positively on my implementation :)
07:11:28 bauzas that's cool
07:11:29 noonedeadpunk So they are at least aware of this
07:14:11 noonedeadpunk but regarding iothreads, I think I have one more thing to add on top of https://review.opendev.org/c/openstack/nova-specs/+/938823 and https://review.opendev.org/c/openstack/nova-specs/+/951636
07:15:25 noonedeadpunk or well. let's discuss on PTG :D
07:15:28 bauzas not sure I understand the relationship between io threads and network IDs, but that's probably related to some network IO concern. Anyway, let's wrap that for the PTG
07:16:12 noonedeadpunk if you get into umbrella of "improving guest performance and enable threading capabilities exposed by libvirt" - they are
07:16:16 noonedeadpunk but yeah
07:16:44 noonedeadpunk it can be all formulated as one point in cycle-highlights :)
07:17:00 bauzas glancing at https://review.opendev.org/c/openstack/nova-specs/+/938823/4/specs/2025.2/approved/network-id-query.rst, this was apparently a Nova API performance change, not something related to libvirt
07:17:18 bauzas but I can be wrong
07:17:35 noonedeadpunk oh, I get the wrong spec then
07:20:16 Uggla noonedeadpunk, add this point (// live migration) the ptg agenda ? If not already done.
07:20:51 noonedeadpunk do you have a specific etherpad for PTG already?
07:20:56 Uggla yes
07:21:15 noonedeadpunk oph, it's in channel; topic
07:21:26 Uggla not updated yet in the channel
07:21:46 Uggla https://etherpad.opendev.org/p/nova-2026.1-ptg
07:21:49 noonedeadpunk ok, and replacing 2025.2 with 2026.1 gives the new one
07:27:40 noonedeadpunk done, thanks!
09:39:57 opendevreview Balazs Gibizer proposed openstack/placement master: Remove excessive logging from GET a_c https://review.opendev.org/c/openstack/placement/+/962775
09:39:58 opendevreview Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness https://review.opendev.org/c/openstack/placement/+/962596
09:39:58 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space with invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
09:40:40 gibi sean-k-mooney: bauzas: I moved https://review.opendev.org/c/openstack/placement/+/962775 to the front of the bugfix series as it can land already while I'm cleaning up the rest. So if you have time I appreciate a review there
09:42:05 bauzas gibi: I can try to look at it this afternoon
09:42:13 bauzas I don't have a lot of context but I'll try to find it :)
09:42:25 gibi that patch removes two debug logs that is it
09:42:26 gibi :)
09:42:41 gibi those debug logs generated gigabyte of logs
09:42:48 gibi in certain queries
09:43:04 bauzas ahah I see, then hopefully it should be simple to review :)
09:43:10 gibi it is :)
09:43:24 gibi the rest is a lot more complex and not ready for final review
09:45:06 bauzas yup, saw it
09:45:07 bauzas +2d
09:45:12 gibi thanks
09:45:17 gibi have a nice session in the gym
09:45:35 Uggla ping sean-k-mooney about https://launchpad.net/nova/2026.1
09:45:43 bauzas well, it will be outside :)
09:45:57 bauzas more a cardio session than a gym
09:48:32 sean-k-mooney[m] Uggla: that looks correct as do the status of the other serise +1
10:05:37 opendevreview Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness bug/2126751 https://review.opendev.org/c/openstack/placement/+/962596
10:05:38 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
10:13:13 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
10:30:07 sean-k-mooney bauzas: the only releationship is the same person was proposing both specs
10:31:11 sean-k-mooney bauzas: masahito was interested in implente iothread, mapping io queue to iothread adnfilterign service by network in the last ptg
10:32:31 sean-k-mooney my io thread spec focuse just on the the simplest useful implemeation of iothread basicly spliting it out form the ioqueue work so it can be delivered independtly and incrementally
10:33:21 sean-k-mooney bauzas: im hoping masahito or noonedeadpunk or anyone else who is interested will have time to work on some of these prosposals this cycle

Earlier   Later