| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-09-11 | |||
| 09:24:44 | sean-k-mooney | no | |
| 09:24:58 | sean-k-mooney | the phsnet is already in the attachment handel | |
| 09:25:08 | bogdando[m] | ah | |
| 09:25:24 | sean-k-mooney | what that spec is doign is propsong we port the logic out of the intel only nic driver | |
| 09:25:31 | sean-k-mooney | into the generic pci driver | |
| 09:25:38 | sean-k-mooney | so it wokrs with any nic | |
| 09:26:28 | bogdando[m] | I see. Well my concern remains - phys net likely an attribute and needs another implementation | |
| 09:27:12 | sean-k-mooney | it may be at some point | |
| 09:27:18 | sean-k-mooney | but it shoudl be set via config | |
| 09:27:35 | sean-k-mooney | as the priamry way to configure it | |
| 09:27:56 | sean-k-mooney | nova never uses the atibute api and never will | |
| 09:28:13 | sean-k-mooney | it uses only the arq api and device profile apis | |
| 09:28:41 | sean-k-mooney | the attachment handel is the summeraisation of the information required to attach a device to a workload (vm or container) | |
| 09:29:16 | sean-k-mooney | bogdando[m]: you proably should read https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html | |
| 09:30:27 | bogdando[m] | also it looks like having phys net in ah of legacy intel driver is OKish, while having a fresh started geneeric pci driver design clean | |
| 09:30:32 | sean-k-mooney | when we implmented suprpot for cyborg managed neutron ports in nova in xena we added code in nova that checks teh phsynet | |
| 09:31:04 | sean-k-mooney | bogdando[m]: the attachmetn handle is the corect place for it | |
| 09:31:16 | sean-k-mooney | bogdando[m]: nova should never use the attibutes api ever | |
| 09:32:52 | bogdando[m] | that is a nice reference to read, thank you. I understood that there is another established contract for nova to cyborg and neutron interaction | |
| 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 | |