| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-29 | |||
| 15:18:57 | bauzas | melwitt: not sure I'll have time, but I'll try | |
| 15:19:10 | stephenfin | gmaan++ ty 🙏 | |
| 15:20:19 | melwitt | bauzas: ack thanks | |
| 15:21:05 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use native IntOpt for tx_queue_size and rx_queue_size https://review.opendev.org/c/openstack/nova/+/969014 | |
| 15:32:27 | gmaan | melwitt: stephenfin sean-k-mooney gibi bauzas dansmith Uggla, As we were not able to discuss the 'standardization of service-to-service communication' topic in PTG, I am proposing it in gerrit, please check when you have time https://review.opendev.org/c/openstack/nova/+/986590 | |
| 15:32:48 | gmaan | I am not in hurry to merge it but would like to get a kind of team agreement on it | |
| 15:33:49 | sean-k-mooney | gmaan: ack. to soften my stand a bit. it may be ok to use the service_user section as a fall back ot create teh user token for requst made by nova on behalvf of a user. but it idally shoudl not be the only way | |
| 15:33:58 | gmaan | sean-k-mooney: I think it is aligned what you were suggesting but I am adding a fallback to service_user which you objected to use for service calling | |
| 15:34:17 | gmaan | sean-k-mooney: yeah | |
| 15:34:25 | sean-k-mooney | the reason im brinign that up is we know that cern and other have one nova that talks to neutron in 3 regions | |
| 15:34:52 | sean-k-mooney | so we can assume that all service a given compute host talks to are in the same region or use the same CA for tls ectra | |
| 15:35:24 | sean-k-mooney | so each service nova talsk to shoudl ahve its onw cofnig section with the common keystone auth optiosn in it | |
| 15:35:25 | gmaan | sean-k-mooney: and i ack your concern for devstack bug for mess up on configuring service users which I will take up as a separate things to solve, I can work on that when get time | |
| 15:35:35 | sean-k-mooney | and then and only then fallback to service_user | |
| 15:37:03 | bauzas | do people know that we have upstream bug triage discussion at the moment ? | |
| 15:37:12 | bauzas | I don't see Uggla telling about it | |
| 15:37:18 | bauzas | https://meet.google.com/fdz-phux-cnc | |
| 15:37:38 | opendevreview | Jay Faulkner proposed openstack/nova stable/2026.1: ironic: Abort build on fatal image validation errors https://review.opendev.org/c/openstack/nova/+/986674 | |
| 15:37:40 | sean-k-mooney | gmaan: by the way i mentioned this in the agentic coding irc channle. its entirly ok for proejct or teams to do one of ptg style meetign that are open for everyoen to join if they need high bandwith com like the midcycle. ill review your proposal when i have time but if we need oen we can poll the list for a time that works an do liek a 1 hour one off on this topic | |
| 15:38:15 | sean-k-mooney | bauzas: oh ok vagely i can join in a mainly liste mode | |
| 15:38:15 | gmaan | ++ | |
| 15:38:24 | sean-k-mooney | im doint somethign else in parallel | |
| 15:38:29 | gmaan | let's see how feedback goes in gerrit and accordingly we can decide | |
| 15:38:55 | gmaan | ' agentic coding irc channle' can you link name, I can join it | |
| 15:40:23 | sean-k-mooney | #openstack-agentic-workflows | |
| 15:40:31 | sean-k-mooney | we need to get that added to ease drop | |
| 15:40:46 | sean-k-mooney | but that will happen once the tc vote happens on the governace repo | |
| 15:50:28 | gmaan | thanks | |
| 15:51:09 | gmaan | sean-k-mooney: Uggla bauzas as we spoke in bug triage meeting,. this is functional test for live migration cleanup things https://review.opendev.org/c/openstack/nova/+/986477 | |
| 16:11:06 | cardoe | So for cyborg+nova, nova is still making a KVM VM for example and attaching the accelerator to the VM? | |
| 16:13:55 | sean-k-mooney | cardoe: yes | |
| 16:14:16 | sean-k-mooney | cardoe: nova is entrily respocneble for the vm defintion and lifecyle management | |
| 16:14:23 | cardoe | okay cool. I wish the docs actually said that plainly on the intro page. :D | |
| 16:14:37 | sean-k-mooney | cardoe: cyborg just dose the inventory of the accelerator adn tells nova here is the pci adress | |
| 16:15:15 | sean-k-mooney | in the future cybrog may to other thing such as cleanign the device it manages for example | |
| 16:15:22 | sean-k-mooney | not firmware flashing | |
| 16:15:34 | sean-k-mooney | but secure rease of nvme ssds | |
| 16:15:43 | sean-k-mooney | that sort of thing | |
| 16:16:38 | sean-k-mooney | eventually its is hoped that cyborg woudl be able to mange other devices beyond pci like usb or cxl or block devices | |
| 16:16:52 | sean-k-mooney | nova woudl still need to eb able to add those to a vm | |
| 16:17:14 | sean-k-mooney | but that woudl be the limit of what nova woudl need to do and cybrog woudl do the enurmation and prepreation fo the device as requreid | |
| 16:17:42 | sean-k-mooney | at least that is the current split of responsiblitys, who knwo what ti will actully become | |
| 16:26:08 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add functional test for NUMA live migration overcommit bug https://review.opendev.org/c/openstack/nova/+/986693 | |
| 17:23:24 | melwitt | aw man, microversion 2.98 (server show image props) in openstackclient and openstacksdk have still not happened 😭 https://review.opendev.org/c/openstack/python-openstackclient/+/940799 and https://review.opendev.org/c/openstack/openstacksdk/+/940798 | |
| 17:53:38 | sean-k-mooney | i also have a ptch for server backup i need ot respin at some point | |
| 17:53:53 | sean-k-mooney | melwitt: server backup works exactly once | |
| 17:53:58 | sean-k-mooney | which is what we test | |
| 17:55:04 | sean-k-mooney | melwitt: stephenfin is gone for today but if we think those are ready to go we shoudl refresh them and ask stephen to then take a look | |
| 17:55:12 | melwitt | hah, awesome | |
| 17:55:46 | melwitt | yeah that would be good. I would usually assume there is something wrong with the proposed patches and that's why they've not been reviewed and merged yet | |
| 17:56:01 | melwitt | so if we can find out what that is, I or you or whoever can update them | |
| 17:57:46 | sean-k-mooney | yep we have +2 right there but not +w bug stpehn as both so if we can get them into a state we think is good to go we cna then ask stephn to take a look | |
| 17:58:45 | melwitt | oh I didn't even notice that it had been +2 in the past | |
| 18:49:40 | opendevreview | Merged openstack/nova master: Stop asking bug report to upstream https://review.opendev.org/c/openstack/nova/+/933381 | |
| 19:16:04 | opendevreview | Merged openstack/nova master: Drop workaround for old keystoneauth https://review.opendev.org/c/openstack/nova/+/927669 | |
| 19:16:21 | opendevreview | Merged openstack/nova master: Fix typo in Caracal prelude https://review.opendev.org/c/openstack/nova/+/915036 | |
| 19:31:21 | opendevreview | Merged openstack/nova master: Remove old warning log about UEFI support https://review.opendev.org/c/openstack/nova/+/908563 | |
| 20:24:48 | opendevreview | Merged openstack/nova master: Delete duplicate unit test https://review.opendev.org/c/openstack/nova/+/984607 | |
| 20:25:03 | opendevreview | Merged openstack/nova master: TPM: fixup for bump service version documentation https://review.opendev.org/c/openstack/nova/+/978836 | |
| 20:25:27 | opendevreview | Merged openstack/nova master: Remove unused gabbi https://review.opendev.org/c/openstack/nova/+/978006 | |
| 22:57:33 | opendevreview | Merged openstack/nova master: libvirt: Use native IntOpt for tx_queue_size and rx_queue_size https://review.opendev.org/c/openstack/nova/+/969014 | |
| #openstack-nova - 2026-04-30 | |||
| 01:39:18 | opendevreview | Merged openstack/nova master: TPM: handle key manager Forbidden errors consistently https://review.opendev.org/c/openstack/nova/+/983504 | |
| 04:35:07 | opendevreview | Merged openstack/nova master: TPM: clean up orphaned libvirt secret on guest creation failure https://review.opendev.org/c/openstack/nova/+/983505 | |
| 08:27:55 | opendevreview | chenker proposed openstack/nova master: add risc-v https://review.opendev.org/c/openstack/nova/+/986752 | |
| 08:34:07 | opendevreview | chenker proposed openstack/nova master: Add compatibility for nova with RISC-V architecture. https://review.opendev.org/c/openstack/nova/+/986752 | |
| 08:44:03 | opendevreview | Kamil Sambor proposed openstack/nova master: Change nova-alt-configurations job https://review.opendev.org/c/openstack/nova/+/983179 | |
| 09:00:10 | opendevreview | Julien LE JEUNE proposed openstack/nova master: Reproduce bug #2150616: KeyError in _rollback_volume_bdms https://review.opendev.org/c/openstack/nova/+/986754 | |
| 12:10:33 | opendevreview | Merged openstack/nova master: Fix invalid jsonschema for keypair list response https://review.opendev.org/c/openstack/nova/+/986660 | |
| 12:56:16 | opendevreview | Merged openstack/os-vif master: Remove url tags from README https://review.opendev.org/c/openstack/os-vif/+/976271 | |
| 15:47:18 | dansmith | gibi: I'm not sure if my point is getting across in the spec reviews.. I'm not really blocking on anything I just feel like we're taking an already very confusing syntax and blowing it up, which I think is unfortunate | |
| 16:01:00 | gibi | dansmith: yeah I agree that the config syntax is complicated. I like your idea of listing addresses to define the group. I just went one step further and wanted to do that in a separate group_spec option not directly in the already complicated device_spec optikn | |
| 16:01:05 | gibi | *option | |
| 16:01:45 | gibi | I think we are not *ready* with the spec so your comment alone is not blocking anything | |
| 16:02:20 | gibi | I think we are exploring the possible configurations to express a group right now | |
| 16:02:31 | gibi | so no hard feeling at all | |
| 16:03:16 | gibi | (if I come accross as angry in my comment then sorry it wasn't the intention, today I got angry on a totally unrealted thing but I guess some then leaked into my spec comment) | |
| 16:05:37 | dansmith | oh no, no leakage that I noticed I'm just trying to make sure it's clear that "I don't like this but I don't really know what the best plan is" | |
| 16:05:55 | dansmith | and it's really just about the actual [pci] syntax part | |
| 16:06:11 | gibi | OK cool then | |
| 16:06:33 | gibi | I do want to spend still couple of back and forth before settle on the syntax. I think it is worth exploring the possibilities | |
| 16:07:05 | gibi | honestly the [pci]device_spec allows too many things already | |
| 16:07:11 | dansmith | for sure | |
| 16:07:39 | dansmith | can you answer though - is it just managed=True that needs to be per-device instead of per-group? | |
| 16:10:13 | gibi | I think live_migratable is also per device, especially if we eventually extend that flag to support live migration via unplug and replug (how we do it for neutron port requested PCI devs today). phyiscal_network can be a per device in the future when we start supporting neutron port requested PCI device with PCI in Placement. | |
| 16:10:41 | gibi | one_time_use is an edge case that does not need to be per device today | |
| 16:11:08 | gibi | but logically if I group an NVME and a NIC and I want to define that the NVME in the group the one that needs the cleaning then | |
| 16:11:31 | gibi | it would be better to model one_time_use on the device instead of on the group | |
| 16:11:37 | dansmith | live_migratable is per group though right? you can't have a group with one migratable device and one not | |
| 16:12:20 | dansmith | I guess I'm not sure why you would group a nic and a nvme together, but fair enough - for the cleaning it makes more sense to account for them individually | |
| 16:12:44 | gibi | imagine that we start grouping a "normally" live_migratable GPU with a NIC that is stateless and should not prevent the live migration but instead we will allow saying for the NIC that live_migratable=unplug | |
| 16:13:05 | dansmith | I know we _should_ be able to group any two devices for any reason, but it's also okay for this to be minimally useful and leave complex scenarios to cyborg :) | |
| 16:13:59 | dansmith | that unplug case could be a cyborg-only too I think, but yeah fair as well | |
| 16:15:04 | gibi | the whole grouping could be / should be cybog only :D | |
| 16:15:34 | dansmith | right, which is why I guess I'm (perhaps too) willing to have some limitations :D | |
| 16:15:50 | dansmith | but okay so sounds like we have to keep the device_spec lines per device | |
| 16:16:36 | dansmith | the "name" is required for each group so we know which provider in placement goes with each set of devices right? | |
| 16:19:59 | gibi | yeah the name is an ugly leak of how we implement resource tracking | |
| 16:20:08 | gibi | we need to name the RP in placement with a stable name | |
| 16:20:30 | dansmith | I _hate_ that | |
| 16:20:32 | gibi | I thought about generating it from the hash of the PCI addresses in the group but that is still not stable | |