| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-09-08 | |||
| 18:10:47 | opendevreview | Merged openstack/cyborg master: Add cors middleware defaults https://review.opendev.org/c/openstack/cyborg/+/997712 | |
| 20:45:25 | opendevreview | OpenStack Release Bot proposed openstack/cyborg master: Update master for stable/2026.2 https://review.opendev.org/c/openstack/cyborg/+/1004702 | |
| #openstack-cyborg - 2026-09-09 | |||
| 05:24:03 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928 | |
| 05:24:03 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929 | |
| 05:24:04 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255 | |
| 05:24:04 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945 | |
| 06:42:59 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928 | |
| 06:42:59 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929 | |
| 06:43:00 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255 | |
| 06:43:00 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945 | |
| 08:20:23 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945 | |
| 09:38:55 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945 | |
| 12:20:48 | opendevreview | chandan kumar proposed openstack/cyborg master: Use GenericDriver.update() as the FPGA programming interface https://review.opendev.org/c/openstack/cyborg/+/991598 | |
| 12:20:48 | opendevreview | chandan kumar proposed openstack/cyborg master: Move create() from FPGADriver to GenericDriver https://review.opendev.org/c/openstack/cyborg/+/998004 | |
| 12:20:49 | opendevreview | chandan kumar proposed openstack/cyborg master: Enable fake FPGA program tests in tempest.conf https://review.opendev.org/c/openstack/cyborg/+/999683 | |
| 15:08:38 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928 | |
| 15:08:39 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255 | |
| 15:08:39 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929 | |
| 15:08:40 | opendevreview | chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945 | |
| 15:08:40 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add configurable NVMe sanitize capability https://review.opendev.org/c/openstack/cyborg/+/1004867 | |
| 15:11:01 | chandankumar | pci-sim nvme implementation with msi and configurable santizie support will work now. | |
| 15:11:32 | chandankumar | Docs are not updated. will address all docs next week. | |
| 15:12:54 | opendevreview | chandan kumar proposed openstack/cyborg master: pci-sim: add configurable NVMe sanitize capability https://review.opendev.org/c/openstack/cyborg/+/1004867 | |
| 23:23:06 | opendevreview | melanie witt proposed openstack/cyborg-specs master: Add services API spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1001999 | |
| #openstack-cyborg - 2026-09-10 | |||
| 14:59:22 | melwitt | sean-k-mooney: I believe you already created the ptg etherpad :) https://etherpad.opendev.org/p/cyborg-2027.1-ptg | |
| 14:59:48 | sean-k-mooney | yep i just need to copy past the stnadard header | |
| 15:00:00 | sean-k-mooney | so that is the one we will use and il update the channel topic with that shortly too | |
| 15:00:15 | sean-k-mooney | when i figure out how to do that again | |
| 15:00:37 | melwitt | heh ok | |
| 15:21:08 | opendevreview | Joan Gilabert proposed openstack/cyborg-specs master: Repropose generic mdev driver spec for 2026.2 https://review.opendev.org/c/openstack/cyborg-specs/+/1005068 | |
| 15:27:24 | melwitt | I updated the services spec proposal yesterday to add a small "Road to rolling upgrade support" section https://review.opendev.org/c/openstack/cyborg-specs/+/1001999/5/specs/2027.1/approved/services-api.rst#644 | |
| 15:28:42 | sean-k-mooney | melwitt: ack cool. | |
| 15:29:05 | melwitt | just to try and capture "what all do we need to make this work" | |
| 15:29:07 | sean-k-mooney | the gap today is not that upgrades are not a thing so much as roling upgrade and skip level upgardes are not a thing | |
| 15:29:18 | sean-k-mooney | so it kind assume you update everything at once today | |
| 15:29:24 | melwitt | yeah | |
| 15:31:47 | sean-k-mooney | once we can properly do n+1 the rest is a lot simpler | |
| 15:32:08 | sean-k-mooney | geting n+1 workign properly not just acidentally is the major lift | |
| 15:34:48 | melwitt | right | |
| 16:49:38 | opendevreview | melanie witt proposed openstack/cyborg-specs master: Add spec for NIC SR-IOV support in the generic PCI driver https://review.opendev.org/c/openstack/cyborg-specs/+/1005089 | |
| 20:04:09 | opendevreview | melanie witt proposed openstack/cyborg-specs master: Add spec for NIC SR-IOV support in the generic PCI driver https://review.opendev.org/c/openstack/cyborg-specs/+/1005089 | |
| #openstack-cyborg - 2026-09-11 | |||
| 08:53:42 | bogdando[m] | hi, WDYT folks on resurrecting https://specs.openstack.org/openstack/cyborg-specs/specs/2023.1/approved/attribute-api-support.html and applying that design for phys_net of deployables instead of attributing particular semanthics to attach handles in generic drivers? context is https://review.opendev.org/c/openstack/cyborg-specs/+/1005089 | |
| 08:54:15 | sean-k-mooney | we will likely reviit but not on the deployable | |
| 08:54:23 | sean-k-mooney | the attibutes shoudl have been on the device instead | |
| 08:54:50 | bogdando[m] | well, device is PF, and for smart nic, its more makes sense to attribute one or a group of its VFs (deployables) | |
| 08:54:55 | sean-k-mooney | bogdando[m]: but to be clear we will asy want to have a config driven approch as a primary approch | |
| 08:55:04 | sean-k-mooney | we may add some api driven suprpot later | |
| 08:55:16 | sean-k-mooney | but its really not a good ux at scale | |
| 08:55:33 | sean-k-mooney | device is not the pf | |
| 08:55:50 | sean-k-mooney | tdevice is the assiable thing it can be the pf or vf | |
| 08:56:04 | sean-k-mooney | a deployable is a pool of allcoatabel devices | |
| 08:56:41 | sean-k-mooney | currently resouce classes for palcement are tracked via the atibutes api | |
| 08:56:44 | sean-k-mooney | that shoudl be on the device | |
| 08:56:56 | sean-k-mooney | becuase each deployable corresponds to a placment resouce provider | |
| 08:57:01 | bogdando[m] | ack, it seems I missread "A device has a management interface, whose address is the control path identifier: for SR-IOV devices, this is usually the PCI Physical Function (PF)" - PF is indeed control managmenent interface of a device, not the device | |
| 08:57:13 | sean-k-mooney | and we want to be able to have 1 placement resouce provier with inventoreis of diffent resouce class | |
| 08:58:18 | bogdando[m] | yes, I like the idea that a deployable is a pool of VFs | |
| 08:58:20 | sean-k-mooney | to be clear i dont think that hte atibute api as orgianly specified is the right shap and the impelation that was done didnt follow the spec and is even worse | |
| 08:58:38 | bogdando[m] | but I am not sure about PFs VFs boundaries as you suggested | |
| 08:59:42 | bogdando[m] | grouping devices or PFs seems a bit another layer of abstraction than VFs affinity | |
| 09:00:05 | sean-k-mooney | placement is not deisign to have 100s of rps for a given host | |
| 09:00:27 | sean-k-mooney | it casue sever performance probelms and a singel nic can have 100s of VFs | |
| 09:00:47 | sean-k-mooney | we group VFs by pf in nova today | |
| 09:01:20 | bogdando[m] | I see, that makes sense to not break the contracts established like each deployable is a placement rp | |
| 09:01:43 | sean-k-mooney | there are 3 related thigns | |
| 09:01:54 | sean-k-mooney | devices deployables and attachmet handels | |
| 09:02:08 | sean-k-mooney | there is a 1:1 relathiship between devices adn attachment handels | |
| 09:02:24 | sean-k-mooney | and a many:1 relasthip between device and deployable | |
| 09:02:37 | sean-k-mooney | or attachmetn_handel and deployabel depending on how you look at it | |
| 09:03:11 | bogdando[m] | hm, my understanding was 1:many for devices and deployables and 1:many for deployables and ah | |
| 09:03:23 | sean-k-mooney | no | |
| 09:03:47 | bogdando[m] | it is based on https://specs.openstack.org/openstack/cyborg-specs/specs/train/implemented/cyborg-nova-placement.html#background | |
| 09:04:33 | bogdando[m] | "A Cyborg device has one or more components named deployables, each of which contains one or more accelerators" | |
| 09:05:00 | bogdando[m] | so accelerators to handles is 1:1, right | |
| 09:05:56 | bogdando[m] | everyting else seems to be 1:many :) | |
| 09:06:25 | sean-k-mooney | so in the db they are not corratled at all directly | |
| 09:06:39 | bogdando[m] | if there is some hidden knowledge based on placement desing, do we have a better place to read about it? | |
| 09:07:08 | sean-k-mooney | not really and the curen implation is both incodsitend and not scalable | |
| 09:07:23 | sean-k-mooney | you really need to look at the code and already know hwo placment was designe to be used | |
| 09:07:32 | bogdando[m] | I see, that comlpicates design review on shaky grounds | |
| 09:08:13 | sean-k-mooney | so the actuall relation ship is as follow | |
| 09:08:56 | sean-k-mooney | device <> contoplathID is 1:1 contolpath id <> attachment handel is 1:1 | |
| 09:09:18 | sean-k-mooney | attachment handel <> deployable is many to 1 | |
| 09:09:49 | sean-k-mooney | the attachment handel is actullth theing that maps contoplath ides to deployables | |
| 09:09:51 | bogdando[m] | would be nice to reflect that in dev docs | |
| 09:09:55 | sean-k-mooney | and devices are assocated transitivly | |
| 09:10:05 | sean-k-mooney | bogdando[m]: its on my todo list | |
| 09:10:21 | bogdando[m] | ack, thanks for explaining! | |
| 09:10:30 | sean-k-mooney | but you can see this by looking at the db schema today https://github.com/openstack/cyborg/blob/master/cyborg/db/sqlalchemy/models.py#L78-L210 | |
| 09:11:19 | sean-k-mooney | the problem iwth the atibutes api is it shoudl have been again the device or optionaly the device or deployable | |
| 09:11:25 | bogdando[m] | looking into code may confuse reader because old implementation paths not strictly following old design specs | |
| 09:11:39 | sean-k-mooney | this is consitent with the spec | |
| 09:11:52 | sean-k-mooney | but you need more context then is captured there | |
| 09:12:10 | sean-k-mooney | or rather ti coudl have done with better diagrams to make it very clear | |
| 09:12:47 | sean-k-mooney | https://specs.openstack.org/openstack/cyborg-specs/specs/train/implemented/cyborg-nova-placement.html#background does not show it clearly | |
| 09:12:52 | bogdando[m] | that comment about code was mostly for "to be clear i dont think that hte atibute api as orgianly specified is the right shap and the impelation that was done didnt follow the spec and is even worse" | |
| 09:13:21 | sean-k-mooney | ah well yes the implementation didnt follwo the spec | |
| 09:13:32 | sean-k-mooney | the spec was reasonabel the implelatin less so | |
| 09:14:56 | sean-k-mooney | i was effectivly planing to remvoe the top level /atibute api because that was neer approved and doesnt really work well | |
| 09:15:25 | sean-k-mooney | https://specs.openstack.org/openstack/cyborg-specs/specs/2023.2/implemented/attribute-api-support.html#rest-api-impact | |