| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-09-11 | |||
| 09:33:53 | bogdando[m] | albeit do you think that adding network specific attributes, then for example gpu specific ones, and maybe later one more for nvmes or fpgas, still keeps that driver attach handle generic? | |
| 09:35:24 | bogdando[m] | am not trying to make a revolution here though :) | |
| 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 | |