)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e365af30_71ac544d","updated":"2026-09-11 16:27:10.000000000","message":"againg good baseline\n\ni have pointed aout a number of things inline that we need to refien but drictionaly i think this headed in teh right direcection","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"}],"specs/2027.1/approved/pci-driver-nic-support.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"839f91bb45ca1e20c0d06d95970cf62874054041","unresolved":false,"context_lines":[{"line_number":147,"context_line":"- Coordinate the switch atomically: change the driver, restart"},{"line_number":148,"context_line":"  the agent, update device profiles, recreate ports."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"This is manageable but adds friction to migration. Three"},{"line_number":151,"context_line":"approaches to address it:"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"**Option A — configurable resource class via whitelist tag.**"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7e0e7d45_d89b034d","line":150,"updated":"2026-09-10 17:00:26.000000000","message":"Proposed Change item 3 presents Options A/B/C for the migration resource-class problem without stating which the spec adopts, and item 2 hedges the device_type whitelist tag with \u0027could ... as a fallback\u0027. Yet the Work Items (\u0027Support configurable resource class (item 3)\u0027), Other Deployer Impact (\u0027resource_class: new tag, overrides the default CUSTOM_PCI\u0027; \u0027device_type: new tag, overrides the inferred device type\u0027), the example configuration, and the Testing section (\u0027resource_class tag overrides the default CUSTOM_PCI\u0027; \u0027Device type is inferred from PCI class code or whitelist tag\u0027) all assume Option A and the device_type tag are committed. The document is internally inconsistent about what is being agreed.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: Reviewers cannot tell which resource-class approach they are approving. If the review outcome selects Option B or C, the Work Items, Deployer Impact tag list, example config, and Testing sections all need rewriting; conversely an implementer may build the whitelist tag (Option A) without that decision having been made in review.\n\n**Suggestion**:\nState the chosen approach explicitly at the end of item 3 (Option A matches the rest of the document), confirm the device_type tag is in scope rather than \u0027could\u0027, and move the rejected options into the Alternatives section with the reasons for rejection.","commit_id":"afbf68655ab862cd652997e7ed173a34f6adfa68"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"The Intel NIC driver (``intel_nic_driver``) is currently the only"},{"line_number":26,"context_line":"Cyborg driver that supports the Neutron smartNIC SR-IOV port flow."},{"line_number":27,"context_line":"It works, but has a hardcoded list of known PCI device IDs"},{"line_number":28,"context_line":"(``KNOWN_NICS`` in ``nic/intel/sysinfo.py``). Any new NIC variant"},{"line_number":29,"context_line":"requires a code change. A ``device_addresses`` allow-list was added"}],"source_content_type":"text/x-rst","patch_set":2,"id":"299e3f92_34a5b8d1","line":26,"updated":"2026-09-11 16:27:10.000000000","message":"it would be good to link to https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html as a refence to this flow.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"The Intel NIC driver (``intel_nic_driver``) is currently the only"},{"line_number":26,"context_line":"Cyborg driver that supports the Neutron smartNIC SR-IOV port flow."},{"line_number":27,"context_line":"It works, but has a hardcoded list of known PCI device IDs"},{"line_number":28,"context_line":"(``KNOWN_NICS`` in ``nic/intel/sysinfo.py``). Any new NIC variant"},{"line_number":29,"context_line":"requires a code change. A ``device_addresses`` allow-list was added"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3233e0fa_7474c7c9","line":26,"in_reply_to":"299e3f92_34a5b8d1","updated":"2026-09-12 01:11:41.000000000","message":"Done","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":30,"context_line":"in 2026.2 (commit ``664f75c``) to address the lack of device"},{"line_number":31,"context_line":"exclusion, but the hardcoded device list remains."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The generic PCI driver (``pci_driver``) avoids hardcoded device IDs"},{"line_number":34,"context_line":"entirely — it uses ``[pci] passthrough_whitelist`` with"},{"line_number":35,"context_line":"vendor/product/address filtering to select devices. A spike on Intel"},{"line_number":36,"context_line":"XXV710 hardware (`LP#2165432`_) confirmed:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"- **Path A (flavor-based passthrough)** works end-to-end with the"},{"line_number":39,"context_line":"  unmodified ``pci_driver``: VFs discovered, Placement resources"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e2b12436_2ab841f5","line":36,"range":{"start_line":33,"start_character":0,"end_line":36,"end_character":42},"updated":"2026-09-11 16:27:10.000000000","message":"i would prefer to avoid agile terminology i know i would not have know what a spike was 8 years ago before i was expose to agaile and most operator and end user proably dont know that spiek means a timebox investiation\n\n```suggestion\nThe generic PCI driver (``pci_driver``) avoids hardcoded device IDs\nentirely, it uses ``[pci] passthrough_whitelist`` with\nvendor/product/address filtering to select devices.\nA prior investigation of managing Intel XXV710 hardware (`LP#2165432`_) confirmed:\n```","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":30,"context_line":"in 2026.2 (commit ``664f75c``) to address the lack of device"},{"line_number":31,"context_line":"exclusion, but the hardcoded device list remains."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The generic PCI driver (``pci_driver``) avoids hardcoded device IDs"},{"line_number":34,"context_line":"entirely — it uses ``[pci] passthrough_whitelist`` with"},{"line_number":35,"context_line":"vendor/product/address filtering to select devices. A spike on Intel"},{"line_number":36,"context_line":"XXV710 hardware (`LP#2165432`_) confirmed:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"- **Path A (flavor-based passthrough)** works end-to-end with the"},{"line_number":39,"context_line":"  unmodified ``pci_driver``: VFs discovered, Placement resources"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4222f09f_990d1f5e","line":36,"range":{"start_line":33,"start_character":0,"end_line":36,"end_character":42},"in_reply_to":"e2b12436_2ab841f5","updated":"2026-09-12 01:11:41.000000000","message":"Done","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":42,"context_line":"- **Path B (Neutron accelerator-direct port)** fails. Two gaps:"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"  1. The ``pci_driver`` omits ``physical_network`` from the ARQ"},{"line_number":45,"context_line":"     attach handle (``pci/sysinfo.py:90``), so Nova raises"},{"line_number":46,"context_line":"     ``KeyError: \u0027physical_network\u0027`` when building the Neutron"},{"line_number":47,"context_line":"     ``binding:profile``. The Intel NIC driver avoids this by"},{"line_number":48,"context_line":"     passing the physnet (``nic/intel/sysinfo.py:251-252``)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7aacc0c7_fe3c89a8","line":45,"range":{"start_line":45,"start_character":18,"end_line":45,"end_character":42},"updated":"2026-09-11 16:27:10.000000000","message":"i would remove this or relace it with a real link to the code (ideally pinned) but i don\u0027t think its requried\n\n\n```suggestion\n     attach handle, so Nova raises a keyerror when hen building the Neutron\n     ``binding:profile``\n```\n\nby the way this feeld more like a nova bug if that where that is failing.\n\nthe way this is ment to work is neutron shoudl be includign the phsynet as a requried tratie request\n\nnova shoudl be mergeing that with the resouce reqruest form the defivce profile\nand nova shoudl not requrie setting the phsynet in the binding:profile\nsince the phsynet is an atibute of the neutron network or l3 segment not the port\nbinding:profile\n\n\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html#interaction-when-booting-the-vm\n\nthe binding profile exist for nova/ironic ot pass infroamtion about the interface to the network backend like the pci adddres for the cybrog device so that the sriov nic agent can bind manage it.\n\nbut the phsnet information is neutorn infroamtion which it already has and shoudl not need to be duplcaited into the bidning profile by nova. in other words it somehting we read not soemthign we write.\n\nthe sriov nic agent does supprot cyrbog ports\n\nhttps://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py#L42\n\nbut i do not see any usage of the phsynet as part of port bidnign in the mechanisum driver\n\nhttps://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py#L117-L226\n\nand in teh sriov nic agent it only sues the pci_slot\n\nhttps://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#L134-L143\n\nso out side fo readign the phsyical netowrk form the neutron port adn passign taht as a required traits with the acclareator requst form the cybrog device profiles to placement there shoudl be no need for the code that is fialing.\n\nso we shoudl remvoe that logic in nova\n\nwhat missing in cybrog, in the pic driver is the ablity to declar which phsyical network the pci device is attached too so it can report it to placement as a CUSTOM_PHYSNET_\u003cvalue\u003e trait\n\n```\nNova API: Nova need to check if vnic type is “accelerator-direct”. If so, Nova will get the device profile’s name from neutron port and call Cyborg API to get the details of this device profile. Meanwhile, Nova need to generate a trait for physical network, for example, Nova get “physnet1” as the physical network from Neutorn, the trait should looks like “CUSTOM_PHYSNET_PHYSNET1”, which is consistent with what Cyborg reports.```\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html#nova\n\ncyborg only role in this desgin really was the inventory reproting to placement\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html#cyborg\n\n```\nA new driver needs to be added in Cyborg in order to discover, program and bind the device. More details is in the Cyborg spec.\n\nCyborg needs to implement a device config file to configure the nic’s name, pci address, physnet name, etc, which are used for Cyborg driver to generate resource provider, trait, etc.\n\n[dev-type]\nphysical_device_mappings \u003d physnet1:eth2|eth3\nfunction_device_mappings \u003d GTPv1:eth3|eth2\n```","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":true,"context_lines":[{"line_number":42,"context_line":"- **Path B (Neutron accelerator-direct port)** fails. Two gaps:"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"  1. The ``pci_driver`` omits ``physical_network`` from the ARQ"},{"line_number":45,"context_line":"     attach handle (``pci/sysinfo.py:90``), so Nova raises"},{"line_number":46,"context_line":"     ``KeyError: \u0027physical_network\u0027`` when building the Neutron"},{"line_number":47,"context_line":"     ``binding:profile``. The Intel NIC driver avoids this by"},{"line_number":48,"context_line":"     passing the physnet (``nic/intel/sysinfo.py:251-252``)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"b5c50722_f874ebd2","line":45,"range":{"start_line":45,"start_character":18,"end_line":45,"end_character":42},"in_reply_to":"7aacc0c7_fe3c89a8","updated":"2026-09-12 01:11:41.000000000","message":"\u003e so out side fo readign the phsyical netowrk form the neutron port adn passign taht as a required traits with the acclareator requst form the cybrog device profiles to placement there shoudl be no need for the code that is fialing.\n\u003e \n\u003e so we shoudl remvoe that logic in nova\n\nI have filed a bug for this part: https://bugs.launchpad.net/nova/+bug/2167144","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":53,"context_line":"     ``pci_driver``-only deployment silently drops the port\u0027s"},{"line_number":54,"context_line":"     ``device_profile``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The whitelist infrastructure already supports a"},{"line_number":57,"context_line":"``physical_network`` tag (``devspec.py`` parses it;"},{"line_number":58,"context_line":"``PciDeviceSpec.get_tags()`` returns it). The driver simply never"},{"line_number":59,"context_line":"reads it."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":".. _LP#2165432: https://bugs.launchpad.net/openstack-cyborg/+bug/2165432"},{"line_number":62,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"d45d05b2_4ba065d7","line":59,"range":{"start_line":56,"start_character":2,"end_line":59,"end_character":9},"updated":"2026-09-11 16:27:10.000000000","message":"support is a stretch\nthis is more a config validation bug as we don\u0027t support any additional unrecognised values in the devspec\n\nbut because tis is just a json blob and we are not do any schema valdation its true that all the infra is in place to parse adn return it today.\n\nthe cybrog-agent proably shoudl ahve at least rasie a warning before if not failed ot start.\n\nbut it does mean that this is relitivly trivial to add\n\nwe shoudl add json schema validation eventually to catch typos and unrecongnised keyparis like this\n\nwe could track that as a seperate bug","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":true,"context_lines":[{"line_number":53,"context_line":"     ``pci_driver``-only deployment silently drops the port\u0027s"},{"line_number":54,"context_line":"     ``device_profile``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The whitelist infrastructure already supports a"},{"line_number":57,"context_line":"``physical_network`` tag (``devspec.py`` parses it;"},{"line_number":58,"context_line":"``PciDeviceSpec.get_tags()`` returns it). The driver simply never"},{"line_number":59,"context_line":"reads it."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":".. _LP#2165432: https://bugs.launchpad.net/openstack-cyborg/+bug/2165432"},{"line_number":62,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"71fd254d_d2c76916","line":59,"range":{"start_line":56,"start_character":2,"end_line":59,"end_character":9},"in_reply_to":"d45d05b2_4ba065d7","updated":"2026-09-12 01:11:41.000000000","message":"Filed a bug: https://bugs.launchpad.net/openstack-cyborg/+bug/2167145","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":64,"context_line":"---------"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a **deployer**, I want to use the generic PCI driver with a"},{"line_number":67,"context_line":"whitelist to expose NIC VFs for SR-IOV passthrough, so that I do"},{"line_number":68,"context_line":"not need to maintain a hardcoded device ID list when adding new"},{"line_number":69,"context_line":"NIC hardware."},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3440c369_fa232a8f","line":67,"range":{"start_line":67,"start_character":0,"end_line":67,"end_character":9},"updated":"2026-09-11 16:27:10.000000000","message":"by the way one of the things i was hoping to do this cycle was to rename this to devspec\n\nthat jsut an fyi but we are tryign to remvoe the term whitelist form our configs, im not sure if that shoudl be part fo the PciBusManger rework or not\n\ni have a colelction of enhacnemnet i kind of want to do togheter but im not sure if we will have time to do that in 2027.1 or not but i might just do the config option rename to get the deprecation of the old names in 2027.1 even if the rest is defered.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":64,"context_line":"---------"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a **deployer**, I want to use the generic PCI driver with a"},{"line_number":67,"context_line":"whitelist to expose NIC VFs for SR-IOV passthrough, so that I do"},{"line_number":68,"context_line":"not need to maintain a hardcoded device ID list when adding new"},{"line_number":69,"context_line":"NIC hardware."},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a612c61_2dda1633","line":67,"range":{"start_line":67,"start_character":0,"end_line":67,"end_character":9},"in_reply_to":"3440c369_fa232a8f","updated":"2026-09-12 01:11:41.000000000","message":"Acknowledged","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"As a **developer**, I want a single configurable driver that can"},{"line_number":77,"context_line":"serve GPU, NIC, and other PCI device classes, reducing the"},{"line_number":78,"context_line":"maintenance burden of per-vendor driver code."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Proposed Change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3c4f526f_a5075656","line":78,"updated":"2026-09-11 16:27:10.000000000","message":"+1\n\nspeaking of `device classes` there are standard pci device classes for nic and gpus and nvme devices\n\nso we coudl use that to set the type reported in the device table automaticly if its a known one.\n\nright now i think they are normally reproted as GPU but i was fixint that in my pci serise\n\nthat mroe a nice to have but we coudl also jsut use the present of phsyical_netork to set device type to NIC\n\nhttps://github.com/openstack/cyborg/blob/master/cyborg/common/constants.py#L94\n\nthat what the intel driver used and it will hep for copatiablity.\n\nalthough instead of resocue class CUSTOM_NIC\n\nhttps://github.com/openstack/cyborg/blob/master/cyborg/common/constants.py#L141\n\nit proably shoudl be the standard one which si \u0027SRIOV_NET_VF\u0027\n\nhttps://github.com/openstack/os-resource-classes/blob/master/os_resource_classes/__init__.py#L49\n\nwe only implmented suprpot for acclerator-direct vnic type in neutron which should alwasy be a VF \n\nacclerator-direct-phsyical is for a PF","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"11acc06876126053eadd18fa695ad00dd61bcda6","unresolved":true,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ef670c01_a0c2f7b4","line":90,"updated":"2026-09-11 08:32:18.000000000","message":"Does this networking specific attribute fit well for *generic* PCI driver? Based on original design doc [0]:\n\n\"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, such as flash memory capacity or BMC firmware version\" - I would assume that phys network represents such an attribute of a device (SR-IOV PF) or perhaps a deployable (VF), but unlikely of a handle?\n\n[0] https://specs.openstack.org/openstack/cyborg-specs/specs/train/implemented/cyborg-nova-placement.html :","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":false,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"94e2ed4a_7e825195","line":90,"in_reply_to":"08b4d74d_931aa585","updated":"2026-09-11 16:27:10.000000000","message":"right the scope fo the pci driver is any statelet pci device\n\nnic, gpu, usb conrolter\n\nas long as it is a pci device and does not require cleaning or programing before its pass to the device or after its returned its in scoep\n\ni coudl see use supporting more advance driver eventually via the generic pci driver but thats a tangent that is our of scope.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"48a2b893d756612503edc17d99bafcb334862df2","unresolved":true,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a4c7c609_fad00b8d","line":90,"in_reply_to":"2e8da730_ab7935aa","updated":"2026-09-11 08:50:56.000000000","message":"Please also see https://specs.openstack.org/openstack/cyborg-specs/specs/2023.1/approved/attribute-api-support.html which seems an abandoned design today, but represents the same idea as my comments above","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"5c7caae7bf46cf900c28c556942d7ce416b876b6","unresolved":true,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ced603a2_30c9d6d9","line":90,"in_reply_to":"a4c7c609_fad00b8d","updated":"2026-09-11 09:23:39.000000000","message":"tl;dr it seems we might want to postpone this until we have new attributes design implemented (to avoid multiple migration paths)?","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"42489b72ef844278c62a51f0d78f418a908817e8","unresolved":false,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"08b4d74d_931aa585","line":90,"in_reply_to":"ced603a2_30c9d6d9","updated":"2026-09-11 10:00:34.000000000","message":"ok, it looks like this generic driver already aims multiple device types, so adding pyhts net into the handle violates nothing; and the attributes api future and use cases are unlcear. Removing this concern.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"b4f3bd3cac2b571d2592606820dd337c3106c8a7","unresolved":true,"context_lines":[{"line_number":87,"context_line":"``sriovnicswitch`` mechanism driver and ``port_device_profile``"},{"line_number":88,"context_line":"extension work as-is."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"1. Plumb ``physical_network`` into the attach handle"},{"line_number":91,"context_line":"----------------------------------------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"In ``_discover_pcis()`` (``pci/sysinfo.py``), after matching a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2e8da730_ab7935aa","line":90,"in_reply_to":"ef670c01_a0c2f7b4","updated":"2026-09-11 08:43:51.000000000","message":"I missed that \"The attach handle represents the object by which an accelerator is associated with an instance: ...(VF)\". So that means that a phys net may belong to a VF, technically. Or it could become an attribute of a deployable as a grouping unit, which implies all of its VFs must be connected to the same phys_net. What represents deployable of generic PCI device in Cyborg today? WDYT, which of two would provide a more accurate abstraction?","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":104,"context_line":"- ``Whitelist.get_devspec()`` (``whitelist.py:90``) returns the"},{"line_number":105,"context_line":"  matching ``PciDeviceSpec``."},{"line_number":106,"context_line":"- ``PciDeviceSpec.get_tags()`` (``devspec.py:308``) returns"},{"line_number":107,"context_line":"  remaining tags including ``physical_network``."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"This is the core change that unblocks Path B."},{"line_number":110,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"0cc301e7_6c865f75","line":107,"updated":"2026-09-11 16:27:10.000000000","message":"this shoudl be simialr to \nhttps://review.opendev.org/c/openstack/cyborg/+/1002257/1/cyborg/accelerator/common/utils.py\nand\nhttps://review.opendev.org/c/openstack/cyborg/+/1002257/1/cyborg/accelerator/drivers/pci/devspec.py","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"  0200 → DEVICE_NIC"},{"line_number":124,"context_line":"  03xx → DEVICE_GPU"},{"line_number":125,"context_line":"  other → DEVICE_PCI"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"As a fallback, a ``device_type`` tag in the whitelist JSON could"},{"line_number":128,"context_line":"override the inferred type."}],"source_content_type":"text/x-rst","patch_set":2,"id":"ce6309b4_cd0161a2","line":125,"updated":"2026-09-11 16:27:10.000000000","message":"ah you already had this 😉 +1","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":124,"context_line":"  03xx → DEVICE_GPU"},{"line_number":125,"context_line":"  other → DEVICE_PCI"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"As a fallback, a ``device_type`` tag in the whitelist JSON could"},{"line_number":128,"context_line":"override the inferred type."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"3. Support configurable resource class"},{"line_number":131,"context_line":"--------------------------------------"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"a6776d88_89b5919c","line":129,"range":{"start_line":127,"start_character":0,"end_line":129,"end_character":1},"updated":"2026-09-11 16:27:10.000000000","message":"i would prefer not to expsoe this\nDEVICE_PCI is alwasy correct for the pci driver but we can be more speciifc if we can detect it.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":124,"context_line":"  03xx → DEVICE_GPU"},{"line_number":125,"context_line":"  other → DEVICE_PCI"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"As a fallback, a ``device_type`` tag in the whitelist JSON could"},{"line_number":128,"context_line":"override the inferred type."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"3. Support configurable resource class"},{"line_number":131,"context_line":"--------------------------------------"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ecefd53e_7db71340","line":129,"range":{"start_line":127,"start_character":0,"end_line":129,"end_character":1},"in_reply_to":"a6776d88_89b5919c","updated":"2026-09-12 01:11:41.000000000","message":"Done, removed ``device_type`` as a whitelist tag.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":136,"context_line":"``pci_driver`` without any resource class accommodation, they"},{"line_number":137,"context_line":"must:"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"- Recreate device profiles with ``resources:CUSTOM_PCI`` instead"},{"line_number":140,"context_line":"  of ``resources:CUSTOM_NIC``."},{"line_number":141,"context_line":"- Recreate any existing ``accelerator-direct`` ports (they carry"},{"line_number":142,"context_line":"  the device profile name whose resource request drives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4a3154c7_6820906d","line":139,"range":{"start_line":139,"start_character":34,"end_line":139,"end_character":54},"updated":"2026-09-11 16:27:10.000000000","message":"so we shoudl not be using ``resources:CUSTOM_PCI`` today in genral\n\nthat a but in the curren impletion and wone of the reason i waso considerign a v2 pci driver\n\nthe default shoudl have been ``resources:CUSTOM_PCI_\u003cVENDOR_ID\u003e_\u003cPRODUCT_ID\u003e``\n\nbut the correct resouce class for a neutron mnaged sriov port is SRIOV_NET_VF\n\nso realy we shoudl be useing CUSTOM_PCI_\u003cVENDOR_ID\u003e_\u003cPRODUCT_ID\u003e when phsyical_netowrk is not defeind and SRIOV_NET_VF if it is btu we could use \nCUSTOM_PCI_\u003cVENDOR_ID\u003e_\u003cPRODUCT_ID\u003e alwasy\n\n\norginally SRIOV_NET_VF was intoduced to be able to put a quota on sriov prot via unifed limits but it was never actully implemtned because we never did pci in placmenet for neutron\n\nand at this point we may never do it if we are movign to have cybrog replace nova in that capaicty.\n\naligneing with \nhttps://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html#scheduling\n\non  CUSTOM_PCI_\u003cvendor_id\u003e_\u003cproduct_id\u003e for genirc pci devices \n\nhttps://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html#neutron-sr-iov-ports-out-of-scope\n\nusing SRIOV_NET_VF","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":136,"context_line":"``pci_driver`` without any resource class accommodation, they"},{"line_number":137,"context_line":"must:"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"- Recreate device profiles with ``resources:CUSTOM_PCI`` instead"},{"line_number":140,"context_line":"  of ``resources:CUSTOM_NIC``."},{"line_number":141,"context_line":"- Recreate any existing ``accelerator-direct`` ports (they carry"},{"line_number":142,"context_line":"  the device profile name whose resource request drives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4a73ef89_b6e2f043","line":139,"range":{"start_line":139,"start_character":34,"end_line":139,"end_character":54},"in_reply_to":"4a3154c7_6820906d","updated":"2026-09-12 01:11:41.000000000","message":"Done","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":154,"context_line":"  [pci]"},{"line_number":155,"context_line":"  passthrough_whitelist \u003d {\"address\": \"0000:3b:0a.*\","},{"line_number":156,"context_line":"                           \"physical_network\": \"physnet1\","},{"line_number":157,"context_line":"                           \"resource_class\": \"CUSTOM_NIC\"}"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"When present, the driver uses the specified resource class"},{"line_number":160,"context_line":"instead of the default ``CUSTOM_PCI``. This lets operators match"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c62c2853_7b2228c4","line":157,"updated":"2026-09-11 16:27:10.000000000","message":"i agree we shoudl allow you to orveried the resource_class for unallcoted devices.\n\ndo the check fo it tis allcoated need some prequiste that im building in https://review.opendev.org/c/openstack/cyborg/+/1002256/1 but that is nto nessiarly compelte yet\n\nthe core of the chagne is there \nhttps://review.opendev.org/c/openstack/cyborg/+/1002256/1/cyborg/agent/resource_tracker.py\n\nthe rescource tracker needs to determin if a pci device is already in teh db and if it is it can only update the maanged stat in teh attachment handel if its currenlty not in us.\n\nin your case you need to do the same check for the phsyical_network and resouces class.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":161,"context_line":"the resource class their existing profiles target and migrate"},{"line_number":162,"context_line":"without touching device profiles or ports."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"The drawback is that this is a generic knob — operators can set"},{"line_number":165,"context_line":"any resource class string, not just ``CUSTOM_NIC``. This is"},{"line_number":166,"context_line":"consistent with the PCI driver\u0027s philosophy of trusting"},{"line_number":167,"context_line":"operator-provided configuration (same as ``physical_network``),"},{"line_number":168,"context_line":"but it does make Placement inventory less predictable from the"},{"line_number":169,"context_line":"driver name alone."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"An alternative considered was inferring the resource class from"},{"line_number":172,"context_line":"the PCI class code (as item 2 does for device type), but this"},{"line_number":173,"context_line":"does not generalize: ``0200 → CUSTOM_NIC`` is clean, but GPU"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6dc8939c_49714d53","line":170,"range":{"start_line":164,"start_character":1,"end_line":170,"end_character":1},"updated":"2026-09-11 16:27:10.000000000","message":"we allow this in nova so to me this is also jsut a partity thing\n\nif you were usign custome resouce calss names in nova and you want cybrog to mange the same devices with the same names ebcause you have the unified limit quotas and billing already set up we shoudl facilidate that.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":168,"context_line":"but it does make Placement inventory less predictable from the"},{"line_number":169,"context_line":"driver name alone."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"An alternative considered was inferring the resource class from"},{"line_number":172,"context_line":"the PCI class code (as item 2 does for device type), but this"},{"line_number":173,"context_line":"does not generalize: ``0200 → CUSTOM_NIC`` is clean, but GPU"},{"line_number":174,"context_line":"devices have no ``CUSTOM_GPU`` resource class — Cyborg uses the"},{"line_number":175,"context_line":"standard ``PGPU`` and ``VGPU`` classes, and the distinction"},{"line_number":176,"context_line":"between physical and virtual GPU cannot be determined from a PCI"},{"line_number":177,"context_line":"class code. The inference would only work for NICs, making it a"},{"line_number":178,"context_line":"special case disguised as a general mechanism."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Doing nothing (operators update device profiles manually) is also"},{"line_number":181,"context_line":"viable — the migration checklist is small — but adds unnecessary"},{"line_number":182,"context_line":"friction when a simple configuration tag eliminates it."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"4. Emit physnet and PF/VF traits"},{"line_number":185,"context_line":"--------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0dfcaa0a_6ea40710","line":182,"range":{"start_line":171,"start_character":0,"end_line":182,"end_character":55},"updated":"2026-09-11 16:27:10.000000000","message":"these shoudl move to the alternitives section fo the spec.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":168,"context_line":"but it does make Placement inventory less predictable from the"},{"line_number":169,"context_line":"driver name alone."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"An alternative considered was inferring the resource class from"},{"line_number":172,"context_line":"the PCI class code (as item 2 does for device type), but this"},{"line_number":173,"context_line":"does not generalize: ``0200 → CUSTOM_NIC`` is clean, but GPU"},{"line_number":174,"context_line":"devices have no ``CUSTOM_GPU`` resource class — Cyborg uses the"},{"line_number":175,"context_line":"standard ``PGPU`` and ``VGPU`` classes, and the distinction"},{"line_number":176,"context_line":"between physical and virtual GPU cannot be determined from a PCI"},{"line_number":177,"context_line":"class code. The inference would only work for NICs, making it a"},{"line_number":178,"context_line":"special case disguised as a general mechanism."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Doing nothing (operators update device profiles manually) is also"},{"line_number":181,"context_line":"viable — the migration checklist is small — but adds unnecessary"},{"line_number":182,"context_line":"friction when a simple configuration tag eliminates it."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"4. Emit physnet and PF/VF traits"},{"line_number":185,"context_line":"--------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8a851462_4e631c3b","line":182,"range":{"start_line":171,"start_character":0,"end_line":182,"end_character":55},"in_reply_to":"0dfcaa0a_6ea40710","updated":"2026-09-12 01:11:41.000000000","message":"Done","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":184,"context_line":"4. Emit physnet and PF/VF traits"},{"line_number":185,"context_line":"--------------------------------"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The NIC driver emits ``CUSTOM_VF``/``CUSTOM_PF`` and"},{"line_number":188,"context_line":"``CUSTOM_\u003cPHYSNET\u003e`` traits via ``get_physical_network_and_traits``"},{"line_number":189,"context_line":"(``nic/intel/sysinfo.py:64-97``). The PCI driver emits only"},{"line_number":190,"context_line":"``CUSTOM_PCI_\u003cVENDOR\u003e`` and ``CUSTOM_PCI_PRODUCT_ID_\u003cid\u003e``."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"When ``physical_network`` is present in the whitelist, emit a"},{"line_number":193,"context_line":"``CUSTOM_\u003cPHYSNET\u003e`` trait. Determine VF/PF status by checking for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a50d7508_6d298d31","line":190,"range":{"start_line":187,"start_character":0,"end_line":190,"end_character":59},"updated":"2026-09-11 16:27:10.000000000","message":"ya swe shoudl proably clean this up\n\nassumign we go with `CUSTOM_PCI_\u003cVENDOR_ID\u003e_\u003cPRODUCT_ID\u003e`\n\nwe do not need ``CUSTOM_PCI_\u003cVENDOR\u003e`` and ``CUSTOM_PCI_PRODUCT_ID_\u003cid\u003e``. as trait\n\nif we go with SRIOV_NET_VF then we coudl keep them but that not really correct form a placment point of view\n\ndifefnt device shoudl be diffent resocue clases by default.\n\nit is only ok to have 2 devices use the saem resouce class if they are interchangeable or fungabile in the guest\n\nmean same over make/modle and driver\n\nthe 2 port vs 4 port device sku is fungable \nintel vs melanox is not really but  for obviousl reason for neturon sriov prot we wante dhtem to be fungable\n\n ``CUSTOM_VF``/``CUSTOM_PF`` i dont thnk shoudl ever be used\n \n\nper the nova spec the phsynet trati shoudl be ``CUSTOM_PHYSNET_\u003cpysical_netowrk\u003e``\ni.e. ``CUSTOM_PHYSNET_PHYSNET1`` so we shoudl audit that code in nova and use that if it aligns.\n\nim fearing that nova is not proply requesting that and that would be a bigger bug in nova that we woudl ahve to fix as part fo this feature.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":190,"context_line":"``CUSTOM_PCI_\u003cVENDOR\u003e`` and ``CUSTOM_PCI_PRODUCT_ID_\u003cid\u003e``."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"When ``physical_network`` is present in the whitelist, emit a"},{"line_number":193,"context_line":"``CUSTOM_\u003cPHYSNET\u003e`` trait. Determine VF/PF status by checking for"},{"line_number":194,"context_line":"a ``physfn`` symlink in ``/sys/bus/pci/devices/\u003caddr\u003e/`` and emit"},{"line_number":195,"context_line":"``CUSTOM_VF`` or ``CUSTOM_PF`` accordingly."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"These traits are useful for device profile targeting but are not"},{"line_number":198,"context_line":"required for Path B to function — the physnet in the attach handle"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d593c52f_ac15db9d","line":195,"range":{"start_line":193,"start_character":28,"end_line":195,"end_character":43},"updated":"2026-09-11 16:27:10.000000000","message":"i woudl prefer to avoid thos in genral or have standar tratis for it if we really ned that.\n\nwe may want to report the nic tratis that were added for nova \n\nhttps://github.com/openstack/os-traits/blob/master/os_traits/hw/nic/offload.py\n\nwe can use ethtool via libvirt ot get those\n\nits basicly ethtool -k i think\n\nits been a decade since i orcstated addign those traits to libivrt so that nova could encode them in the db and eventully reprot them to placment\n\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1390-L1402\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1600-L1631\n\nthe feature predates placment and the usage of those and reproting to placment never got done in the end but if we wante ot reprot useful traits about the device capablity they exist.\n\nas doesn HW_NIC_SRIOV but im not sure that is patically insightful\n\nhttps://github.com/openstack/os-traits/blob/master/os_traits/hw/nic/__init__.py#L17\n\nincidnetlly HW_NIC_PROGRAMMABLE_PIPELINE was also added for smart nics and never used...","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":198,"context_line":"required for Path B to function — the physnet in the attach handle"},{"line_number":199,"context_line":"is what Nova needs, not the trait."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"5. Broaden DevStack plugin ``port_device_profile`` guard"},{"line_number":202,"context_line":"--------------------------------------------------------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"``devstack/plugin.sh:24`` only enables the ``port_device_profile``"},{"line_number":205,"context_line":"ML2 extension when ``CYBORG_ENABLED_DRIVERS`` matches"},{"line_number":206,"context_line":"``nic_driver``. Broaden the guard to also match ``pci_driver``, or"},{"line_number":207,"context_line":"unconditionally enable the extension whenever Cyborg is enabled"},{"line_number":208,"context_line":"(the extension is harmless when no ``accelerator-direct`` ports"},{"line_number":209,"context_line":"exist)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"6. Populate ``parent_addr`` for PF→VF expansion"},{"line_number":212,"context_line":"-----------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"119963f7_21561deb","line":209,"range":{"start_line":201,"start_character":0,"end_line":209,"end_character":7},"updated":"2026-09-11 16:27:10.000000000","message":"ya i think either works the devstack bit i think are implemetion detail so i woudl proably remove them form the spec and we can review it when you update the jobs/plugin","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4ea3623915396415b0aeeac136c081ed8836d2b0","unresolved":false,"context_lines":[{"line_number":198,"context_line":"required for Path B to function — the physnet in the attach handle"},{"line_number":199,"context_line":"is what Nova needs, not the trait."},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"5. Broaden DevStack plugin ``port_device_profile`` guard"},{"line_number":202,"context_line":"--------------------------------------------------------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"``devstack/plugin.sh:24`` only enables the ``port_device_profile``"},{"line_number":205,"context_line":"ML2 extension when ``CYBORG_ENABLED_DRIVERS`` matches"},{"line_number":206,"context_line":"``nic_driver``. Broaden the guard to also match ``pci_driver``, or"},{"line_number":207,"context_line":"unconditionally enable the extension whenever Cyborg is enabled"},{"line_number":208,"context_line":"(the extension is harmless when no ``accelerator-direct`` ports"},{"line_number":209,"context_line":"exist)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"6. Populate ``parent_addr`` for PF→VF expansion"},{"line_number":212,"context_line":"-----------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9f998f1e_184a5131","line":209,"range":{"start_line":201,"start_character":0,"end_line":209,"end_character":7},"in_reply_to":"119963f7_21561deb","updated":"2026-09-12 01:11:41.000000000","message":"Done","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":207,"context_line":"unconditionally enable the extension whenever Cyborg is enabled"},{"line_number":208,"context_line":"(the extension is harmless when no ``accelerator-direct`` ports"},{"line_number":209,"context_line":"exist)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"6. Populate ``parent_addr`` for PF→VF expansion"},{"line_number":212,"context_line":"-----------------------------------------------"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"``_discover_pcis()`` sets ``parent_addr \u003d None``"},{"line_number":215,"context_line":"(``pci/sysinfo.py:157``), so a PF address in the whitelist does"},{"line_number":216,"context_line":"not expand to its VFs. For each discovered device, check if it is"},{"line_number":217,"context_line":"a VF (has a ``physfn`` symlink) and populate ``parent_addr`` with"},{"line_number":218,"context_line":"the PF address. This enables operators to whitelist a PF address"},{"line_number":219,"context_line":"and have all its VFs discovered, matching the NIC driver\u0027s"},{"line_number":220,"context_line":"behavior."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"This is a convenience — operators can already whitelist VFs"},{"line_number":223,"context_line":"directly by address glob."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"7. NIC device emulation in pci-sim"},{"line_number":226,"context_line":"----------------------------------"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"aec6473c_b5ffd425","line":224,"range":{"start_line":210,"start_character":1,"end_line":224,"end_character":1},"updated":"2026-09-11 16:27:10.000000000","message":"actully this is kind of a bug\n\nwe shoudl alrady be detechign that relathip as we shoudl not allow both the pf and its vfs to be listed at the same tiem.\n\none or the other is valid but not both.\n\nthis is not just for nics either.\n\nthe nvida l4 uses the same vendor it and product id for the PF and VF which is a bit of a pain but you have to manually selefct only the VFs when you want to use them\n\ni have been considering adding a epxlciy excldue cpaablity to the pci whitelisht in teh future to make this simpler to manage\n\nanywya hte only time a pf adress should whitelist the VFs is if you use the PF adress and the VF vendor id and product id\n\nand we would only do that to keep aprtiy with nova.\n\nits a complex bevahior that im not sure we want to keep but if we do then we shoudl make sure that he PF is not reported to hte device table in this case","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":239,"context_line":"  against the emulated VF."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"This would be the first CI coverage for the"},{"line_number":242,"context_line":"Cyborg→Nova→Neutron SR-IOV port path."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"8. Deprecate ``intel_nic_driver``"},{"line_number":245,"context_line":"---------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"674944da_e7273ddb","line":242,"updated":"2026-09-11 16:27:10.000000000","message":"this is a nice to have i woudl usggest e1000 as its old and there is exsitign emultion coode for it and use a tap or veth device on the hsot side as the representor  netdev.\n\nif that does nto mean anything to you this basicly need to look like the switthdev api where there is a vf adn a resprestor netdev on the hsot\nyou pass the vf to the vm and you plug the netdev itnto an ovs or linux bridge \n\nfor example if its a linxu breidge you woud add a real nic, or veth pair to neutron ovs br-ex to provide networkign to the vms\n\nthat could have its onw spec to defien the detail but we can likely take that off lien and write s developer docuemnt in the pci-sim module.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":274,"context_line":"work. This unblocks Path B but leaves the PCI driver as a"},{"line_number":275,"context_line":"second-class option for NICs (wrong device type, wrong resource"},{"line_number":276,"context_line":"class, no physnet traits). Operators would need to accept these rough edges"},{"line_number":277,"context_line":"or continue using ``intel_nic_driver``."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"**Move NIC support into a new driver.** Instead of extending"},{"line_number":280,"context_line":"``pci_driver``, create a new ``generic_nic_driver`` that combines"}],"source_content_type":"text/x-rst","patch_set":2,"id":"79d34f1e_c63e0bcb","line":277,"updated":"2026-09-11 16:27:10.000000000","message":"so the more i read the sepc the more i think there is a bug on the nova side adn we shoudl add it to the launchpad bug\n\nbut lets dig into that more and see if this is really only a cybrog issue or if the\nnova side fo https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html is incorrectly hadnelign the phsynet trait.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":281,"context_line":"the PCI driver\u0027s whitelist approach with the NIC driver\u0027s physnet"},{"line_number":282,"context_line":"plumbing. This avoids complexity in the PCI driver but adds a"},{"line_number":283,"context_line":"third driver to maintain, which is the opposite of"},{"line_number":284,"context_line":"consolidation."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Data Model Impact"},{"line_number":287,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"076dbd6f_ff14e2eb","line":284,"updated":"2026-09-11 16:27:10.000000000","message":"this is also a posiblity.\n\ni think we may eventully replace the curent pci driver with a ground up rewtie.\n\ni had hoped to start on that his cycle but i think that may be 2027.2 now so i think this is fine to include for now.\n\n\none of the big change i want to make in the v2 driver is to group VFs by there pf instead of having 1 placement resouce provider per VF which we have today...\n\nif we dont create a seprate v2 dirver for that we will need to instead resahpe all fo the pci inventories and allcoations.\nthat doabel but non tivitial.","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"28cead66752bb31d93af0dfb6063270d232a4adc","unresolved":true,"context_lines":[{"line_number":451,"context_line":"emulated NIC VF to pci-sim that exercises the full"},{"line_number":452,"context_line":"``accelerator-direct`` port flow in the gate. This is the first"},{"line_number":453,"context_line":"CI coverage for the Cyborg→Nova→Neutron SR-IOV path and requires"},{"line_number":454,"context_line":"no specialized hardware."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6cc91fc4_2c8d28a2","line":454,"updated":"2026-09-11 16:27:10.000000000","message":"so we need to invstatge exactly what that mens\n\nnvoa supprot neutron port sriov attach and detach whcih shoudl in thory include cybrog prots as they are just sriov ports however i would be very surpsied if taht actully works properly\n\nso we need to be abel to suprot creatign a vm with a cyrbog neutron port and we shoudl be able to add/remvoe them at runtime but we need to test that and docuemt what the full flow actully means\n\nidd you test any atach/detach actions with the intel driver?","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c72aa622a776ead550fd5a3bd86a05f03fcde782","unresolved":true,"context_lines":[{"line_number":451,"context_line":"emulated NIC VF to pci-sim that exercises the full"},{"line_number":452,"context_line":"``accelerator-direct`` port flow in the gate. This is the first"},{"line_number":453,"context_line":"CI coverage for the Cyborg→Nova→Neutron SR-IOV path and requires"},{"line_number":454,"context_line":"no specialized hardware."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5b4d1207_cde30029","line":454,"in_reply_to":"6cc91fc4_2c8d28a2","updated":"2026-09-11 17:31:15.000000000","message":"Just tried this and it\u0027s actually intentionally blocked currently:\n```\n$ openstack --os-cloud devstack-admin server add port test-pci-flavor sriov-port\nBadRequestException: 400: Client Error for url: http://10.37.137.45/compute/v2.1/servers/08372eca-55f4-4e70-b226-950f122d7877/os-interface, Feature not supported with Ports that have accelerators.\n```","commit_id":"edee31714c07cbfaa4183dbbac2057c53dd31378"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"f7bcff2c68538c41cdbae1c528e2dc009e84e25f","unresolved":false,"context_lines":[{"line_number":280,"context_line":"``DriverAttribute``, ``DriverDevice.type``). No new database"},{"line_number":281,"context_line":"columns or migrations are required."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"REST API Impact"},{"line_number":284,"context_line":"---------------"},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"None. The devices API will report the correct ``type`` field"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fc8e8ab_842fd1f5","line":283,"updated":"2026-09-12 01:21:31.000000000","message":"The REST API Impact section begins \u0027None.\u0027 but then describes the devices API reporting a different \u0027type\u0027 field (NIC instead of GPU) for PCI-driver-discovered devices. Changing the value of a returned parameter is an API behavior change: today every pci_driver device is reported with type\u003dGPU; after this change non-GPU devices report NIC or PCI. The repo\u0027s spec template requires specs that change returned parameters to carry the APIImpact flag in the commit message; the commit message for this change has none.\n\n**Severity**: WARNING | **Confidence**: 0.8\n\n**Impact**: API consumers (dashboards, CLI filters, automation) that select devices by type will see different results for existing generic PCI devices after the change; labeling the section \u0027None\u0027 hides this from spec reviewers, and the missing APIImpact flag keeps the change out of the project\u0027s API-impact query that exists to apply higher scrutiny to API changes.\n\n**Suggestion**:\nRewrite the section to describe the observable change (which devices change type, from what to what, and that no schema change is needed), and add the APIImpact flag to the commit message per the template guidance.","commit_id":"b356f43082df2a0f25b65d64c606b40e96ee88b2"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"f7bcff2c68538c41cdbae1c528e2dc009e84e25f","unresolved":false,"context_lines":[{"line_number":365,"context_line":"Upgrade Impact"},{"line_number":366,"context_line":"--------------"},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"The change is additive. Existing ``pci_driver`` deployments"},{"line_number":369,"context_line":"(GPU/generic PCI passthrough) are unaffected — the new whitelist"},{"line_number":370,"context_line":"tags are optional and the default behavior is unchanged."},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"59b1e4a6_4065e1c5","line":368,"updated":"2026-09-12 01:21:31.000000000","message":"The Upgrade Impact section states the change is additive and existing pci_driver deployments are unaffected because the new whitelist tags are optional and the default behavior is unchanged. But item 3 changes the default reported resource class from CUSTOM_PCI (reported for every device today) to CUSTOM_PCI_\u003cVENDOR_ID\u003e_\u003cPRODUCT_ID\u003e, and item 2 changes the devices API type value for every non-GPU PCI device from the hardcoded DEVICE_GPU to DEVICE_NIC/DEVICE_PCI. Both are default-behavior changes that apply with no new whitelist tag.\n\n**Severity**: HIGH | **Confidence**: 0.85\n\n**Impact**: If implemented as specified, an operator upgrading an existing pci_driver deployment has device profiles targeting CUSTOM_PCI that stop matching, because resource providers get CUSTOM_PCI_\u003cVENDOR\u003e_\u003cPRODUCT\u003e instead. Allocation silently fails unless every deployment adds a resource_class\u003dCUSTOM_PCI override per whitelist entry or rewrites device profiles. A bounded but real set of upgrade paths breaks while the spec tells operators nothing changes.\n\n**Priority**: Before merge\n**Recommendation**:\nCorrect the Upgrade Impact section to state that the default resource class and reported device type change for existing pci_driver users, document the mitigation (set resource_class\u003dCUSTOM_PCI in existing whitelist entries to preserve behavior, or update device profiles), and consider keeping CUSTOM_PCI as the default unless an operator opts into the vendor/product scheme.","commit_id":"b356f43082df2a0f25b65d64c606b40e96ee88b2"}]}