| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-09-11 | |||
| 09:35:41 | sean-k-mooney | first of all yes, but secondly the only things that will be specifid via that interface are thigns that change how the device is assocated with the guest | |
| 09:36:27 | sean-k-mooney | bogdando[m]: currently your propsoal are misaligned with the driction i woudl liek to take the proejct. im open ot dicussion but i do not want to have nova need to know more about cybrog then it already does in general | |
| 09:36:44 | sean-k-mooney | nov ainteract with only 2 api, the device profile api to get the resouce request | |
| 09:36:57 | sean-k-mooney | and the the acclerator request api to bind allcoated devices | |
| 09:37:03 | bogdando[m] | I am ok with that just maybe renaming generic driver to something else then | |
| 09:37:12 | sean-k-mooney | the attchmeth handel is part of the repocne of the arq bind | |
| 09:37:20 | bogdando[m] | like universal driver | |
| 09:37:48 | sean-k-mooney | the term generic is chooen specifly to be vendor agnistic | |
| 09:37:56 | sean-k-mooney | we have a pci driver, and are addning an nvme dirver | |
| 09:38:08 | sean-k-mooney | they arem named after the bus tehy manage | |
| 09:38:17 | sean-k-mooney | i.e. the mdev drvier that we are creating | |
| 09:38:29 | sean-k-mooney | my hope is to eventually remove most of the vendor specific drivers | |
| 09:38:45 | bogdando[m] | yes, I also support that | |
| 09:38:48 | sean-k-mooney | and only have the generic driver unless there is a stong reaodn ot keep a vendor driver | |
| 09:39:24 | sean-k-mooney | so if we say wanted ot supprot USB passthough in the future we woudl add a usb driver that can work with any usb device instead of a logitech driver | |
| 09:40:07 | sean-k-mooney | same fr cxl, block devices ectra. | |
| 09:40:36 | sean-k-mooney | the reason nvme is not part fo the generic pci deriver is because its stateful and need specific cleaning | |
| 09:40:37 | bogdando[m] | just as a thought experiment, what if attributes api to be added for accelerators api to which nova already interacts | |
| 09:41:28 | sean-k-mooney | it already is kidn of there in a form more useful to nova | |
| 09:41:39 | sean-k-mooney | bogdando[m]: the only thing that this is used for today is addign an removing traits | |
| 09:41:45 | sean-k-mooney | that it | |
| 09:42:07 | sean-k-mooney | the device profile already contians groups of resoucelass and trait requests | |
| 09:42:38 | sean-k-mooney | the atibute api is not inteded as a way to do devifce configuration | |
| 09:42:42 | sean-k-mooney | its a metadata store | |
| 09:43:01 | sean-k-mooney | i do not want to extend it to do configuration if we do that it will be iva a diffent api | |
| 09:43:36 | sean-k-mooney | bogdando[m]: form the api ref "A attribute represents the trait of a physical card like FPGA or GPU." | |
| 09:43:54 | sean-k-mooney | its litally just a proxy api to add traits to the placement resouce provider | |
| 09:44:07 | sean-k-mooney | its not needed today because you can do that directly via the placment api | |
| 09:45:09 | sean-k-mooney | this is why i said i dont think its fit for porpus today and i woudl prefer to entirly replace it in the future | |
| 09:47:54 | bogdando[m] | attributes api looks redundant, yes, although mentions non-placement/nova use cases | |
| 09:48:27 | sean-k-mooney | it would acked as a geneitc metatdata store | |
| 09:48:52 | sean-k-mooney | but https://bugs.launchpad.net/openstack-cyborg/+bug/2158996 prevents it form being used at all today | |
| 09:49:25 | sean-k-mooney | the implemtion today requries you to know the internal database primary key which is never returend form teh api | |
| 09:49:45 | bogdando[m] | "A device may have components, such as flash memory or BMC, which are not of relevance to Nova or Placement. Those components may have attributes" | |
| 09:50:29 | sean-k-mooney | we do not have any usecase that require that currnetly | |
| 09:51:38 | sean-k-mooney | to be clear if i was a core when this was propsoed i would have been -2 on the spec based on its curent content | |
| 09:52:06 | bogdando[m] | actually that "not of Nova relevance" answers to my propoal already - phys_net is in relevance, hence not a fit for that api | |
| 09:53:06 | sean-k-mooney | i can see usecase for device metadta or config apis in the future but that diffent | |
| 16:27:54 | sean-k-mooney | melwitt: ok i finially finsihed reviewign both your spec and left comments inline | |
| 16:28:37 | sean-k-mooney | directionally both are a good start but between teh 2 i left 60 ish comments so maybe wait till monday to read them :) | |
| 16:57:48 | melwitt | sean-k-mooney: 60?? lol ok. thank you for reviewing :) | |
| 17:06:01 | sean-k-mooney | melwitt: some of them may be duplicative | |
| 17:06:28 | sean-k-mooney | i went seciton by seciton and later noteice that soem eiarer coment were paticly adressed | |
| 17:06:45 | melwitt | ah nice I got some review from bogdando[m] too. thanks both | |
| 17:07:00 | melwitt | ah k | |
| 17:09:04 | sean-k-mooney | i started early today and it now 18:00 so im going to finsh nowish | |
| 17:09:26 | sean-k-mooney | if you want to chat about any of the feed back on a call or somehting we can grab some time next week | |
| 17:09:52 | melwitt | sounds good :) | |
| 17:09:53 | sean-k-mooney | but we can continue to dicuss on gerrit too | |
| 17:16:23 | opendevreview | Takashi Kajinami proposed openstack/cyborg-tempest-plugin master: Add stable/2026.2 job https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/1005315 | |
| #openstack-cyborg - 2026-09-12 | |||
| 01:11:15 | 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-14 | |||
| 15:24:32 | melwitt | sean-k-mooney: thanks for the review on my specs :) I have replied and updated the NIC support in generic PCI driver one | |
| 15:25:09 | sean-k-mooney | cool ill try and take a look later in the week | |
| 15:25:32 | sean-k-mooney | did the expectaion aound the nova cybrog neutron interactions make sense to you wehn you read them | |
| 15:26:35 | sean-k-mooney | i know that is a bit complex but the spec were at least somehwat clear on what each service should be doing | |
| 15:26:48 | sean-k-mooney | i looked at the neutron code but didnt look at teh nova side | |
| 16:08:41 | melwitt | sean-k-mooney: yes I think I understood the basics of what you said about nova/cyborg/neutron | |
| 16:09:35 | melwitt | on the nova side it appears you are right about accessing 'physical_network' is _currently_ pointless bc it's not used for anything | |
| 16:10:01 | melwitt | it accesses the key but then does nothing with it | |
| 16:11:35 | sean-k-mooney | ack | |
| 16:11:40 | melwitt | the question is then, should nova be using that key to report a trait to placement (per the https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html spec) | |
| 16:11:41 | sean-k-mooney | that shoudl be an easy fix so | |
| 16:11:50 | sean-k-mooney | no it should not | |
| 16:12:02 | sean-k-mooney | the placement reporting is doen by cyborg | |
| 16:12:29 | sean-k-mooney | nova shuld be using the phsyical network form the neturon port/network to request the phsynet when quering placement | |
| 16:12:30 | melwitt | yeah, in my testing I commented out that key access and then was able to create the server successfully with the sriov port | |
| 16:12:32 | melwitt | ack | |
| 16:13:07 | sean-k-mooney | basiclly we shoudd more or less do this like we would for neutron sriov ports | |
| 16:13:18 | sean-k-mooney | currenly we do that filtering after the placement call | |
| 16:13:23 | sean-k-mooney | but ideally we woudl do it before hand | |
| 16:13:38 | sean-k-mooney | i.e. we do it via the pci filter today for neutron | |
| 16:15:21 | sean-k-mooney | in nova our vifi object have a type filed and a network field https://github.com/openstack/nova/blob/master/nova/network/model.py#L427-L428 | |
| 16:16:14 | sean-k-mooney | but im not sure we currently recored the phsynet in the network | |
| 16:16:29 | sean-k-mooney | so we may have to look that up directly form neutron | |
| 16:16:44 | sean-k-mooney | or plumb that inf though the modeles | |
| 16:16:56 | sean-k-mooney | this is the bit i didnt want to look up on firday :) | |
| 16:18:14 | sean-k-mooney | we have some exsting code we can draw form like https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2183-L2224 | |
| 16:18:48 | sean-k-mooney | for example in create_resouces_requsts https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356 | |
| 16:19:23 | sean-k-mooney | infact that is also wehre we are creating the cyborg requests | |
| 16:19:27 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356-L2373 | |
| 16:20:52 | melwitt | hm ok, so nova should be using the key to request a trait rather | |
| 16:21:01 | sean-k-mooney | unless im missing somehting we are looking up the phsynet and nerver actully passing it | |
| 16:21:12 | sean-k-mooney | melwitt: yes | |
| 16:21:24 | melwitt | that is what I saw as well, looking it up but then doing nothing with it | |
| 16:21:27 | sean-k-mooney | because the device profile is the same regardless fo the network | |
| 16:21:46 | sean-k-mooney | but hte phsynet depend on the network and or l2 segment | |
| 16:22:12 | melwitt | ok I will update the nova bug with this info | |
| 16:27:01 | sean-k-mooney | ah... https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2417-L2422 | |
| 16:27:04 | melwitt | ok yeah I see now, I had misread the spec | |
| 16:27:26 | sean-k-mooney | so right now stpehens piror chagnes are findign a host aht has the requried phnets | |
| 16:27:45 | sean-k-mooney | but when they added the cybrog feature the didnt do it on a per nic basis | |
| 16:28:04 | sean-k-mooney | i.e. then never enriched the requried traits for the cyborg request group | |
| 16:28:29 | sean-k-mooney | so if your host only has 1 phsynet this will owrk but if it has 2 then you might get a device on the wrong one form placement | |
| 16:28:38 | melwitt | does that mean anything needst o change about the code you linked with the physnets? or would the cyborg change be an additive change | |
| 16:28:41 | sean-k-mooney | that will then fail at the port bidning stage in neutron | |
| 16:28:53 | sean-k-mooney | no the code shoudl still be changed | |
| 16:29:20 | melwitt | I mean, does _that_ code need to change? with cyborg, is it bad to add the physnet to the set the way it is currently? | |
| 16:29:45 | sean-k-mooney | those are 2 diffent api responces | |
| 16:29:53 | sean-k-mooney | it is correct to add it to the attachment handel | |
| 16:30:07 | sean-k-mooney | but https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2367-L2376 is the imporant part we need to check | |