| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-29 | |||
| 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 | |
| 16:20:36 | gibi | I hate it too | |
| 16:21:05 | dansmith | yeah, I also thought .. even just the one/first pci address would be enough, no? | |
| 16:21:16 | dansmith | but it makes it a bit messy on the backend in case the order changes, etc | |
| 16:21:41 | gibi | so far I thought we allow reconfiguring the content of a *not allocated* group | |
| 16:21:51 | gibi | that breaks naming by address | |
| 16:22:03 | gibi | I thought about just indexing group-type-1 -2 -3 | |
| 16:22:17 | gibi | but then we will be config line order dependent | |
| 16:22:47 | dansmith | sorted(group.addresses)[0] would be somewhat stable against rerders | |
| 16:22:53 | dansmith | but if they add a new earlier one it won't of course | |
| 16:23:30 | dansmith | either way, I think "name" is the wrong label for this thing.. it's an identifier, a key, a ... something | |
| 16:23:57 | dansmith | "name" is really most appropriate for the alias, IMHO, the rest are basically FK's | |
| 16:27:10 | gibi | OK that is fair | |
| 16:27:35 | gibi | key works fo rme | |
| 16:27:38 | gibi | *for me | |
| 16:27:51 | gibi | we even save a char in each def :D | |
| 16:29:33 | dansmith | ack, I'm not too concerned over the char of course, but the meaning | |
| 16:30:22 | gibi | I know, I just entertain myself with the saving of chars :D | |
| 16:31:13 | dansmith | and I guess we could have more than one alias reference a type of group? I'm not sure why really, but I assume that's "desirable" | |
| 16:31:43 | dansmith | ugh, I'm getting 403 from docs.o.o | |
| 16:32:52 | gibi | yes two alias can refer to the same group_type but can asks for different traits, and two groups in the same group_type can have two different set of traits. I have no good example why this would be useful but the current alias syntax allows it today already | |
| 16:33:06 | gibi | ohh I have a good example | |
| 16:33:18 | gibi | two alias can differ in numa_policy | |
| 16:33:39 | dansmith | yeah okay | |
| 16:33:41 | gibi | so you want two GPUs but one alias give with with NUMA affinity required the other just preferres | |
| 16:33:45 | gibi | * preferred | |
| 16:35:03 | dansmith | I wish that we could have alias reference device_spec or group_spec things instead of the devices (by address or vendor/model) and was just thinking of other ways to collapse that a bit | |
| 16:35:06 | dansmith | but probably not possible | |
| 16:35:35 | dansmith | alias can find things by address, vendor/model, and now group_type.. just feels far too undefined | |
| 16:35:51 | gibi | yeah I know | |
| 16:36:28 | gibi | at least alias with a group_type is better in my eyes than using vendor/product | |