| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-02 | |||
| 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 | |
| 10:34:06 | sean-k-mooney | if not i will proably try to impelment one of the propsosal but i woudl prefe to just help them by reviewing there work | |
| 10:34:40 | sean-k-mooney | i do think thses woudl be good enachnmemnt however so if there isnt a comunity effort to move them forward ill see if i can help more directly | |
| 11:12:55 | noonedeadpunk | yeah, I think I should be able to pull couple of them | |
| 13:01:43 | opendevreview | Merged openstack/python-novaclient master: Use pre-commit for lint jobs https://review.opendev.org/c/openstack/python-novaclient/+/952987 | |
| 13:10:56 | opendevreview | Merged openstack/python-novaclient master: tests: Remove use of ddt https://review.opendev.org/c/openstack/python-novaclient/+/953193 | |
| 13:35:32 | opendevreview | Ian Watson proposed openstack/nova master: Changing how placement updates are triggered in RT https://review.opendev.org/c/openstack/nova/+/955687 | |
| 14:59:13 | opendevreview | Balazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776 | |
| 15:00:10 | gibi | sean-k-mooney[m]: dansmith: ^^ now with a long commit message and a workaround flag | |
| 15:03:31 | sean-k-mooney | gibi: so you runign with 21 because well that is what the bug report used. have you tried bumping to 32 PFs | |
| 15:03:44 | sean-k-mooney | gibi: basiclly im wondering how much headroom this is geting us | |
| 15:04:05 | sean-k-mooney | 7 seconds for the 21_21 case is not bad | |
| 15:04:11 | ratailor | sean-k-mooney, gibi elodilles could you please review https://review.opendev.org/q/I04f6e1ba3eff443d40a13c6fe2d0b77a78a020e6 | |
| 15:04:35 | sean-k-mooney | much better thne before you started im juust wonderign if it will explode at say 24_24 or can we push to 32+ | |
| 15:06:27 | gibi | sean-k-mooney: yeah 21 is the magic number from the customer. I can add more cases. | |
| 15:06:39 | gibi | please leave a comment in the review so I won't forget | |
| 15:06:54 | sean-k-mooney | a standard 2U server can typicaly hold 24 2.5" ssd's in the front which woould also need 96 pci lanes to support at full speed. given many chips top out at 96-128 lanes with some going ot the low 160s range 32 device is proably close to the max we woudl expct to see | |
| 15:07:35 | sean-k-mooney | sure i can im ok with the current test uing the reproted worse case i just was wondering if you had playied aroudn with it | |
| 15:07:44 | sean-k-mooney | ill pull it locally and try it | |
| 15:08:22 | sean-k-mooney | but ya 120+ second ot 6.9 is a very nice impovement | |
| 15:08:33 | gibi | sean-k-mooney: if it is two slow for 32/32 then try to decrease the max alocation candidates from 1000 to smaller | |
| 15:08:39 | gibi | s/two/too/ | |
| 15:08:44 | sean-k-mooney | but 120+ to less then one in the non worse case is very promising | |
| 15:09:07 | gibi | I have drop for the weekend in minutes so I won't be able to test it myself today | |
| 15:09:18 | sean-k-mooney | gibi: oh ya that a good poitn if we can provide soem guiance on tuning the values for larger systems than that at least a workaroudn | |
| 15:09:26 | gibi | btw up until 8/8 I tested the logic in devstack as well and the numbers are pretty similar | |