)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"788117a3_4e8470ad","updated":"2026-04-17 14:37:25.000000000","message":"We have couple of questions to settle next week on the PTG.\n(I also left a bunch of overlapping comments in the PoC)","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"24334c49_34731358","updated":"2026-02-05 14:23:52.000000000","message":"couple of comments","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d557171a_7308a31d","updated":"2026-04-17 15:25:11.000000000","message":"quick respocne but ill see if i have tiem to review agian before the ptg","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"4cc58463_5a92c447","updated":"2026-04-28 15:49:11.000000000","message":"Here are my comments about an alternative structure. Some of these were pending from a few days ago and others I finished this morning after gibi\u0027s ask.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cd5052ac64ea46c63d254f7d610e482bfdcc2151","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c088a601_12a9fa1d","updated":"2026-05-07 17:45:50.000000000","message":"Sorry, I guess I never hit the submit button on this a couple days ago.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"21e92678_5528f5a1","updated":"2026-04-28 14:32:12.000000000","message":"Updated the spec after the PTG","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e39add709fc27f819b17d2af689f4c32ce1fad90","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"95b6a292_6afcedb7","updated":"2026-04-29 20:25:27.000000000","message":"i ment ot push those this morning but im just finsining for today so i pushed what i had locally","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0f9c0c4b7a2b2a09b8cbe2bc076c6587fbc2c8a1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"aa59b5a5_efd3f63b","in_reply_to":"4cc58463_5a92c447","updated":"2026-04-29 09:46:40.000000000","message":"Thanks for the proposal. I have to chew it a bit before I can meaningfully respond.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"683d6155_ba7583e9","updated":"2026-05-08 16:47:58.000000000","message":"+1 for now\n\ni want to understand if after all the remaing comment are considre do we still have opens we need to adress before graduating to +2\n\nhavign a seprate group_spec by anyther name was somethign i breifly consider in teh past and dicsonted as overly complex but as propsed i think its a workable solution\n\nim not entirly convice it less complext or easier to reason abut then what i propsoed orginally but there is a better sepreation of concurs\n\ndevspec remains in change fo filtering which devices nova can manage\nthe new group spec just aggreates and annotates the devices that form each group.\n\nthe veriosn i was thinkign of worked slightly diffently in that i was thing of havign a sepetae group_types fiels and only moving the triats/resouce_clas to the type isntead of also usign it to specify which devices were part of the group.\n\ni think you have motivated the current design better in teh spec then was done in the etherpad so i think tis somethign i can agree with given the constraits fo backward comaptibltiy and nova\u0027s legacy from teh exsting options.\n\nwhen thinking about how i would model it in cybborg i think i woudl make other tadeoffs but i agree this approch is valid for nova.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"65e2174a_8d2f8dc2","updated":"2026-05-08 15:18:45.000000000","message":"Just some comments about the new words and config arrangement.\n\nI definitely think having `group_spec` is better than before. I definitely still think that we\u0027re building more apartments on top of an existing house of cards by trying to bolt this into the existing syntax :(","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8c8e98be53987a6c5c94d1120e223407ce56ef86","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"895f42ba_e2375d09","updated":"2026-05-11 08:26:29.000000000","message":"thanks folks, I\u0027m working on answering the comments...","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"}],"specs/2026.2/approved/pci-passthrough-groups.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":14,"context_line":"request a group of PCI devices. These groups of PCI devices are tracked"},{"line_number":15,"context_line":"as a single indivisible unit within Placement. The default custom"},{"line_number":16,"context_line":"resource class used to track these PCI groups is derived from the"},{"line_number":17,"context_line":"PCI group type name, and the name of the inventory is derived from"},{"line_number":18,"context_line":"the PCI group name. The pci_alias config already supports mapping"},{"line_number":19,"context_line":"to a specific placement resource class."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a4c61260_cb864231","line":18,"range":{"start_line":17,"start_character":21,"end_line":18,"end_character":19},"updated":"2026-04-17 14:37:25.000000000","message":"I guess what this means is the name of the *Resource Provider* is derived from the name of the group.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":14,"context_line":"request a group of PCI devices. These groups of PCI devices are tracked"},{"line_number":15,"context_line":"as a single indivisible unit within Placement. The default custom"},{"line_number":16,"context_line":"resource class used to track these PCI groups is derived from the"},{"line_number":17,"context_line":"PCI group type name, and the name of the inventory is derived from"},{"line_number":18,"context_line":"the PCI group name. The pci_alias config already supports mapping"},{"line_number":19,"context_line":"to a specific placement resource class."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":2,"id":"cee654de_93cb3935","line":18,"range":{"start_line":17,"start_character":21,"end_line":18,"end_character":19},"in_reply_to":"a4c61260_cb864231","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Let us consider the specific case of the Graphcore C200 device,"},{"line_number":55,"context_line":"where a set of PCI cards are connected together via IPU-Link:"},{"line_number":56,"context_line":"https://docs.graphcore.ai/projects/C600-datasheet/en/latest/product-description.html#ipu-link-cables"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Each physical card presents two PCI devices. The card can be used"},{"line_number":59,"context_line":"independently of other cards if a matched pair of devices are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"43411dbe_acb6ee13","line":56,"updated":"2026-04-17 14:37:25.000000000","message":"I know this was the original use case and it is still valid but I\u0027m wondering if we want to mention NVLink and the rest that has more marketing value in my eyes.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Let us consider the specific case of the Graphcore C200 device,"},{"line_number":55,"context_line":"where a set of PCI cards are connected together via IPU-Link:"},{"line_number":56,"context_line":"https://docs.graphcore.ai/projects/C600-datasheet/en/latest/product-description.html#ipu-link-cables"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Each physical card presents two PCI devices. The card can be used"},{"line_number":59,"context_line":"independently of other cards if a matched pair of devices are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2245d50f_0f4e912f","line":56,"in_reply_to":"43411dbe_acb6ee13","updated":"2026-04-28 14:32:12.000000000","message":"I added some words","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":81,"context_line":"  Each group being a separate resource provider with a single inventory"},{"line_number":82,"context_line":"  item for the associated group type custom resource type, with a name"},{"line_number":83,"context_line":"  that is generated from the group_name rather than the PCI device address"},{"line_number":84,"context_line":"* extend ``[pci]alias`` to map to the resource class mentioned"},{"line_number":85,"context_line":"  above, such as ``CUSTOM_PCI_GROUP_\u003cgroup_type_name\u003e``."},{"line_number":86,"context_line":"* PCI tracker will have the ``group_name`` and ``group_type`` added to"},{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f7526ff_218e81c1","line":85,"range":{"start_line":84,"start_character":0,"end_line":85,"end_character":56},"updated":"2026-04-17 14:37:25.000000000","message":"I think the PoC also adds group_type to the alias to request groups. So there is both RC and group_type on the device_spec side and also RC and group_type on the alias side.\n\nOn the device_spec side this specification define a precedence that an explicit RC overrides an implicit RC derived from the group_type. Does the same precedence exists in case of the alias definition? Or we want to simplify there?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  Each group being a separate resource provider with a single inventory"},{"line_number":82,"context_line":"  item for the associated group type custom resource type, with a name"},{"line_number":83,"context_line":"  that is generated from the group_name rather than the PCI device address"},{"line_number":84,"context_line":"* extend ``[pci]alias`` to map to the resource class mentioned"},{"line_number":85,"context_line":"  above, such as ``CUSTOM_PCI_GROUP_\u003cgroup_type_name\u003e``."},{"line_number":86,"context_line":"* PCI tracker will have the ``group_name`` and ``group_type`` added to"},{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"}],"source_content_type":"text/x-rst","patch_set":2,"id":"80445e50_009673a9","line":85,"range":{"start_line":84,"start_character":0,"end_line":85,"end_character":56},"in_reply_to":"45bf1661_bd49190d","updated":"2026-04-28 14:32:12.000000000","message":"As discussed on the PTG both group_type and resource_class will be supported in the alias to request a specific group type. I documented it now.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":81,"context_line":"  Each group being a separate resource provider with a single inventory"},{"line_number":82,"context_line":"  item for the associated group type custom resource type, with a name"},{"line_number":83,"context_line":"  that is generated from the group_name rather than the PCI device address"},{"line_number":84,"context_line":"* extend ``[pci]alias`` to map to the resource class mentioned"},{"line_number":85,"context_line":"  above, such as ``CUSTOM_PCI_GROUP_\u003cgroup_type_name\u003e``."},{"line_number":86,"context_line":"* PCI tracker will have the ``group_name`` and ``group_type`` added to"},{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"}],"source_content_type":"text/x-rst","patch_set":2,"id":"45bf1661_bd49190d","line":85,"range":{"start_line":84,"start_character":0,"end_line":85,"end_character":56},"in_reply_to":"5f7526ff_218e81c1","updated":"2026-04-17 15:25:11.000000000","message":"yes group_type is the primary way to request a group and i envisioned you would not set both. so i am inclidned to require group_type for groups or at least stongly encurange it but we can ahve RC override it if you really hate the default nameing convetion.\n\ni dont recal which i did in the poc.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"},{"line_number":89,"context_line":"  in placement."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Configuration Tags"},{"line_number":92,"context_line":"------------------"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"0b5ebf8f_2bc0f968","line":90,"updated":"2026-02-05 14:23:52.000000000","message":"* Could a group of VFs from the same PF is supported?\n* Could a group of VFs across multiple parent PF is supported?\n\nDoes this cause complication in the PCI tracking?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"},{"line_number":89,"context_line":"  in placement."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Configuration Tags"},{"line_number":92,"context_line":"------------------"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"a682129b_b7ccd73b","line":90,"in_reply_to":"0b5ebf8f_2bc0f968","updated":"2026-02-05 15:43:27.000000000","message":"Is this answered on L143?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"da03409a5e264a0aa8d421547ca5216d73e4e13f","unresolved":false,"context_lines":[{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"},{"line_number":89,"context_line":"  in placement."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Configuration Tags"},{"line_number":92,"context_line":"------------------"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"e124e37d_27fab5f4","line":90,"in_reply_to":"358da548_72f9b4a3","updated":"2026-02-10 12:10:25.000000000","message":"@dms@danplanet.com originally I failed to spot the connection but I see it now.\n\n@smooney@redhat.com thanks sounds good","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":87,"context_line":"  each device that is being tracked, such that we can look up a group"},{"line_number":88,"context_line":"  of devices associated with each specific named group tracked"},{"line_number":89,"context_line":"  in placement."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Configuration Tags"},{"line_number":92,"context_line":"------------------"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"358da548_72f9b4a3","line":90,"in_reply_to":"a682129b_b7ccd73b","updated":"2026-02-05 17:16:57.000000000","message":"yes a group of VFs form teh same pf is suproted and its how i was testing it locally\n\nand also yes a group of VF across PFs shoudl also work.\n\ni have not tested that yet but i think i have second pf that i can use to verify it.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":96,"context_line":"* ``group_name``: A unique identifier for a specific group instance"},{"line_number":97,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":98,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":99,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."}],"source_content_type":"text/x-rst","patch_set":2,"id":"d1420cf9_3e9f1b2a","line":100,"range":{"start_line":99,"start_character":60,"end_line":100,"end_character":69},"updated":"2026-02-05 14:23:52.000000000","message":"This together with \n\u003e * **Inventory**: Always 1 (the group is an atomic unit)\n\nbelow and the fact that suffixed placement request groups can only be fulfilled form a single RP means that if the flavor asks for 2 groups from the same type/alias then such request needs to be split to two placement request groups. This is not different from the logic of requesting 2 device from the same alias today. So this is just a impl note from me here, no update needed in the spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"da03409a5e264a0aa8d421547ca5216d73e4e13f","unresolved":false,"context_lines":[{"line_number":96,"context_line":"* ``group_name``: A unique identifier for a specific group instance"},{"line_number":97,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":98,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":99,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."}],"source_content_type":"text/x-rst","patch_set":2,"id":"d5751e84_89997b83","line":100,"range":{"start_line":99,"start_character":60,"end_line":100,"end_character":69},"in_reply_to":"549caa21_9b4d1d2d","updated":"2026-02-10 12:10:25.000000000","message":"Acknowledged","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":96,"context_line":"* ``group_name``: A unique identifier for a specific group instance"},{"line_number":97,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":98,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":99,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."}],"source_content_type":"text/x-rst","patch_set":2,"id":"549caa21_9b4d1d2d","line":100,"range":{"start_line":99,"start_character":60,"end_line":100,"end_character":69},"in_reply_to":"d1420cf9_3e9f1b2a","updated":"2026-02-05 17:16:57.000000000","message":"yep.\n\nso i condiered if we shoudl consolidate grousp into a singel rp. \ni didnt do that becaue if we were to do that we proably woudl want to do that more generally and i belive that is firmly out of scope\n\nso for right now if you have 2 groups fo the same type on a host you will have 2 nested rps\n\nand if you want 2 of them in a single flvor we need to split the request into 2 request groups.\nbut we already have to do that for pci in placment today so it would be an extetion of the existing logic.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9f69782c_ba110997","line":103,"updated":"2026-02-05 15:43:27.000000000","message":"I\u0027m not sure I\u0027m understanding the two keys here.. The name is unique for the actual pair, and the type is shared amongst all the groups of this type of thing? such that you would have:\n- graphcore_1,c200_x1\n- graphcore_2,c200_x1\n- ...etc\n?\n\n(later) okay I see that I think the above is correct, and knowing the name is sort of the provider and the type is the inventory class helps. Might be worth an extra sentence here to clarify.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9f59dcb5e45b3886b3ecbfdd1d27e8ef8938e466","unresolved":true,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"78e70cfe_955f681a","line":103,"in_reply_to":"3f13cd88_00035d26","updated":"2026-04-17 17:44:02.000000000","message":"OK. Then I misunderstood the discussion here. So lets support all the spec-dev matching modes for devs in groups as well. Obviously we will have different level of validations at different point in the codebase. We can validate each spec individually. Then we can validate a group based on the specs in it. Then a group_type based on the groups belonging to it. And eventually we will validate things based on the devices matched to the groups. One thing that right now that is impossible to pre-validate on the compute level is that the same group_type means the same number of devices across multiple computes. We need that to live migraton to work, so that will be a pre-live-migration check I guess.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"16288b89_61b3d35e","line":103,"in_reply_to":"78e70cfe_955f681a","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aa08f580_d0e54731","line":103,"in_reply_to":"9f69782c_ba110997","updated":"2026-02-05 17:16:57.000000000","message":"ack i can work on some prose to make that clarer\n\na slightly sanitised version looks like this\n\n```\ndebian@hibernal01:~$ openstack --os-cloud devstack-admin resource provider list\n+--------------------------------------+-----------------------------------------------------------+------------+--------------------------------------+--------------------------------------+\n| uuid                                 | name                                                      | generation | root_provider_uuid                   | parent_provider_uuid                 |\n+--------------------------------------+-----------------------------------------------------------+------------+--------------------------------------+--------------------------------------+\n| 8a4fb119-1393-4d11-9394-e881433aad0a | hibernal01                                                |         13 | 8a4fb119-1393-4d11-9394-e881433aad0a | None                                 |\n| 5538f512-52f3-4b72-b6b8-55f9e917f0ca | hibernal01_group_nic_group_1                              |          5 | 8a4fb119-1393-4d11-9394-e881433aad0a | 8a4fb119-1393-4d11-9394-e881433aad0a |\n+--------------------------------------+-----------------------------------------------------------+------------+--------------------------------------+--------------------------------------+\n```\n\nbased on this nova config fragment conf\n```\n[pci]\nreport_in_placement \u003d True\n# Group 1: 3b:02.0 - 3b:02.7\ndevice_spec \u003d {\"address\": \"0000:3b:02.0\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.1\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.2\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.3\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.4\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.5\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.6\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.7\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\n\n# Group 2: 3b:03.0 - 3b:03.7\n#device_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\n\n# Group 3: 3b:04.0 - 3b:04.7\n#device_spec \u003d {\"address\": \"0000:3b:04.*\", \"group_name\": \"nic_group_3\", \"group_type\": \"NICx8\"}\n\n# Group 4: 3b:05.0 - 3b:05.7\n#device_spec \u003d {\"address\": \"0000:3b:05.*\", \"group_name\": \"nic_group_4\", \"group_type\": \"NICx8\"}\n\n# Group 5: 3b:06.0 - 3b:06.7\n#device_spec \u003d {\"address\": \"0000:3b:06.*\", \"group_name\": \"nic_group_5\", \"group_type\": \"NICx8\"}\n\n# Group 6: 3b:07.0 - 3b:07.7\n#device_spec \u003d {\"address\": \"0000:3b:07.*\", \"group_name\": \"nic_group_6\", \"group_type\": \"NICx8\"}\n\n# Group 7: 3b:08.0 - 3b:08.7\n#device_spec \u003d {\"address\": \"0000:3b:08.*\", \"group_name\": \"nic_group_7\", \"group_type\": \"NICx8\"}\n\n# Group 8: 3b:09.0 - 3b:09.7\n#device_spec \u003d {\"address\": {\"domain\": \"0000\", \"bus\": \"3b\", \"slot\": \"09\", \"function\": \".*\"}, \"group_name\": \"nic_group_8\", \"group_type\": \"NICx8\"}\n\n# Alias for requesting NICx8 groups via flavor\nalias \u003d {\"name\": \"NICx8\", \"resource_class\": \"CUSTOM_PCI_GROUP_NICX8\", \"group_type\": \"NICx8\"}\n```\n\ni need ot uncomemtn and test the other regex adn blob sytax but it shoudl work or will once i have time to test it again","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f13cd88_00035d26","line":103,"in_reply_to":"a6449ab0_8527bff7","updated":"2026-04-17 15:25:11.000000000","message":"well that preexisitng fucntionatly\n\nnot new so my baseline was we will supprot everyitng that is allowed in the device_spec for a normal function (i..e the blob/regex supprot) in the adress\nunless we had a reason not to of coruces i.e. no supprot for dev_name","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":100,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Both tags must be specified together - specifying only one results in"},{"line_number":103,"context_line":"a configuration error."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Validation Rules"},{"line_number":106,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a6449ab0_8527bff7","line":103,"in_reply_to":"aa08f580_d0e54731","updated":"2026-04-17 14:37:25.000000000","message":"There is some blob and regex related code in the PoC but first we need to settle what we support.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7e9e5d2d_e5b1425d","line":114,"updated":"2026-02-05 15:43:27.000000000","message":"And presumably devices here can only be specified by address and not vendor,model right?I assume that means we also have to make sure that we list all other device_spec devices (even those by vendor,model) and make sure that none of the devices here are grouped into those, right? I assume this also means that if you have four of the same device, and only two of the four share a link, then the two non-linked ones must be specified by address to avoid including the linked/grouped ones?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9f59dcb5e45b3886b3ecbfdd1d27e8ef8938e466","unresolved":true,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5319c425_43053bdc","line":114,"in_reply_to":"00811fd8_15b8b8e3","updated":"2026-04-17 17:44:02.000000000","message":"I guess we want to keep it simple but not breaking existing schemes. The main way will be address and address glob/regex to define groups. But I would not reject a group that defined by vendor_id,product_id even though that use case is pretty limited. Later, based on feedback we can think about extending the vendor_id,product_id case with a count or exclude list if somebody needs it.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"00811fd8_15b8b8e3","line":114,"in_reply_to":"10ae8a4e_a4117117","updated":"2026-04-17 15:25:11.000000000","message":"correct, i would like to requrie that i think but im open to other propsoals\n\nif we just use vendorid and product id unless we had someitng like a group_count\nto automaticly partion the matiching device in to groups of N\n\ni dont think that woudl be that useful so to keep it simple i want to required adresses for now but im oke with the idea fo adding an \"externaly_manged\" or exclude/negate flag to allow an easy way to say not this one.\n\nthat woudl be for the nic partitioning usecase.\nthat not striclty a grouping related feature but mroe a general refinment to the devstack format in genreal.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"10ae8a4e_a4117117","line":114,"in_reply_to":"1c66b637_bb6e3b41","updated":"2026-04-17 14:37:25.000000000","message":"\u003e i have been usign adress so far in my testing however and i think that makes teh most sence so i proably shoudl make adress requried.\n\nThis needs to be settled. The PoC does not mandate the usage of the address field for grouping.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"cb466607_d76358af","line":114,"in_reply_to":"5319c425_43053bdc","updated":"2026-04-28 14:32:12.000000000","message":"Updated the spec accordigly.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":111,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1c66b637_bb6e3b41","line":114,"in_reply_to":"7e9e5d2d_e5b1425d","updated":"2026-02-05 17:16:57.000000000","message":"yes adn no\n\ni woudl need to doublcheck that in my poc but if you specify  only a vendor id and product id it all matching devices would end up in one gorup\n\nwe can chosoe if that valid or not and i dont actully know if there is a usecase for that\n\ni have been usign adress so far in my testing however and i think that makes teh most sence so i proably shoudl make adress requried.\n\n\nin term of the interaction between \n```\ndevice_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"vendor_id\": \"8086\", \"product_id\":\"154c\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\n```\n\ni have generally lent in the direction that if you have a device refecne withsce in two diffent dev stpec that shoudl be a config error.\n\nbut we coudl choose to have teh group take precendce or add exclude_addresses or similar\n\n```\ndevice_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"vendor_id\": \"8086\", \"exclude_addresse\"\u003d\"0000:3b:03.*\" \"product_id\":\"154c\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\n```\n\nexclude adresses is just a geenrally useful thing to be ablel to do but obvously that need a littel more work to impement but it woudl be nice to have even with groups\n\n\ndo you have a prefernce\n\ntoday in my poc you woud need to use adresses to make sure the device specs  dont overlap as i belive i already have a check to make it a cofnig error if they do.\ni have soem protaction against overlapping groups but i dont knwo if that will catch this edgecase.\nhttps://review.opendev.org/c/openstack/nova/+/973604/3/nova/pci/whitelist.py#198\n\nim missing a functional test to validate this so that a vaild testing gap\nhttps://review.opendev.org/c/openstack/nova/+/973604/3/nova/tests/functional/libvirt/test_pci_in_placement.py","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"91541282_ae4fe915","line":115,"updated":"2026-04-17 14:37:25.000000000","message":"Couple of other validation rules we should discuss:\n\n* Dependent device support:\n  * parent PF and child VF within the same group. Do we allow it? PCI in Placement today does not allow them being configured at the same time.\n  * parent PF and child VF in two separate group\n  * parent PF and child VF where one of them is in a group while the other is not in any group but matched by spec.\n\n* Size of the groups within the group type: Can a group1 and group2 has different number of devices when both belong to group_typeX? At least in the PoC the NUMA scoring logic is sensitive to the size of the group.\n\n\n* What if two specs of the same group defines diverging RC or group_type? Or a combination where spec1 for group1 defines a group_type but spec2 to group1 defines an RC as well?\n\n* What if two specs of two different groups but the same group_type defines different RCs?\n\n---\n\nWe probably needs some validation rules for the PCI alias as well:\n* What will be the device_type field usage for an alias that targets a group of diverse set of devices (PF+VFs)?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":112,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":113,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":114,"context_line":"* No duplicate device addresses across groups"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Placement Integration"},{"line_number":117,"context_line":"---------------------"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"68156f13_b840e67c","line":115,"in_reply_to":"91541282_ae4fe915","updated":"2026-04-28 14:32:12.000000000","message":"Detailed it in the spec based on the PTG discussion","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":true,"context_lines":[{"line_number":119,"context_line":"Each PCI device group is represented in Placement as a single Resource"},{"line_number":120,"context_line":"Provider (RP) that is a child of the compute node RP:"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* **RP Naming**: ``{hostname}_group_{GROUP_NAME}`` (uppercase)"},{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6ebf8c96_d84189d1","line":122,"updated":"2026-04-28 14:32:12.000000000","message":"Why are we uppercasing the group_name? The hostname is kept as is, and the \"group\" specifier is lowercase.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Each PCI device group is represented in Placement as a single Resource"},{"line_number":120,"context_line":"Provider (RP) that is a child of the compute node RP:"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* **RP Naming**: ``{hostname}_group_{GROUP_NAME}`` (uppercase)"},{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8c44fc76_b0bf7e40","line":122,"in_reply_to":"6ebf8c96_d84189d1","updated":"2026-05-08 14:46:29.000000000","message":"removed the upper casing","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"6a980a43_64e1d1a1","line":126,"updated":"2026-02-05 15:43:27.000000000","message":"Merged meaning.. union? I guess it seems like they should all have the same set of traits set in device_spec, else that\u0027s an error.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9f59dcb5e45b3886b3ecbfdd1d27e8ef8938e466","unresolved":true,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"b144622a_b1851ae1","line":126,"in_reply_to":"37bf7100_7f42ffd5","updated":"2026-04-17 17:44:02.000000000","message":"PURPLE case:\n* {address\u003d\"0.0.1\", traits\u003dCUSTOM_RED, group_name\u003dgroup1, group_type\u003dtype1}\n* {address\u003d\"0.0.2\", traits\u003dCUSTOM_BLUE, group_name\u003dgroup1, group_type\u003dtype1}\n\nNow we have group1 with two devs, and an contradicting color :)\n\nBut colors can be mixed.\n\nWhat if \n* {address\u003d\"0.0.1\", traits\u003dCUSTOM_EMITS_SOUND, group_name\u003dgroup1, group_type\u003dtype1}\n* {address\u003d\"0.0.2\", traits\u003dCUSTOM_EDIBLE, group_name\u003dgroup1, group_type\u003dtype1}\n\nDoes group1 noisy?\nYes as there is a device in it that makes sound.\nDoes group1 edible\nNo, (or partially) as there is a device that is not edible.\n\nSo I dont see a good choice now. But I will sleep on it.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"638b6d14_d7c8f2b4","line":126,"in_reply_to":"628729c4_bbee753c","updated":"2026-04-17 14:37:25.000000000","message":"The problem is that the logic for one type of group might not applicable to other types of groups. For you GPU+audio case merging the traits make sense. But if somebody starts to group two differently sized VGPU together for reason X then the traits provided by those two VGPUs might not make sense to union. Similarly in the abstract case when on device says CUSTOM_BLUE the other in the same group CUSTOM_RED then the group can be striped with RED and BLUE colors, it can be shaded with PURPLE, or can be an error. Or similarly how live-migratable is not a union capability but a intersection one.:/\n\nI have no good proposal here as the combination strategy of the traits depends on the traits itself some combine differently then the others. Lets look at it on the PTG.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"37bf7100_7f42ffd5","line":126,"in_reply_to":"638b6d14_d7c8f2b4","updated":"2026-04-17 15:25:11.000000000","message":"ack. to me the group is the indivisable thing so the traits are an atibute of the group rather then the devices within it hence the merging\n\nbut if there are alternitive then sure.\n\ngroup cant overlap and are indivsiabel so im not sure the PUPEL case can happen. it not in socpe of this prosal as written from my perspective.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"628729c4_bbee753c","line":126,"in_reply_to":"6a980a43_64e1d1a1","updated":"2026-02-05 17:16:57.000000000","message":"yes a union.\n\nthe intent is to support groups fo different type of device.\nso if all the devices in teh group yes they woudl be the same\n\nhttps://review.opendev.org/c/openstack/nova/+/973604/3/nova/tests/functional/libvirt/test_pci_in_placement.py#2894\n\n\none reason for this si a consumer  nvida job like a rtx4080 has one pf that is the gpu and a secodn pf that is the audo contoler.\n\nso i want to be able to group both and union the traits form both if we were to auto discover them\n\nthat not a great example as the only trait we auto discover todya come form nics and only nics via livbirt and ethtool","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":123,"context_line":"* **Resource Class**: ``CUSTOM_PCI_GROUP_{GROUP_TYPE}`` by default,"},{"line_number":124,"context_line":"  or a custom ``resource_class`` tag value if specified"},{"line_number":125,"context_line":"* **Inventory**: Always 1 (the group is an atomic unit)"},{"line_number":126,"context_line":"* **Traits**: Merged from all devices in the group"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1465aca7_ea83cf3b","line":126,"in_reply_to":"b144622a_b1851ae1","updated":"2026-04-28 14:32:12.000000000","message":"on the PTG we agreed to go with group_traits to avoid the need of defining a merging rule. It is basically a cleaner case of saying that traits definition of each dev_spec line cannot diverge.\n\nUpdated the spec accordingly.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."},{"line_number":130,"context_line":"This ensures atomic all-or-nothing allocation."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Pool and Allocation Design"},{"line_number":133,"context_line":"--------------------------"},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"c814e806_5bbc367b","line":131,"updated":"2026-02-05 14:23:52.000000000","message":"We need special care when we reconfigure nova in a way that a PCI device is moved to a group or devices from group moved out to be individual devices","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."},{"line_number":130,"context_line":"This ensures atomic all-or-nothing allocation."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Pool and Allocation Design"},{"line_number":133,"context_line":"--------------------------"},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"57f7b6ac_e9829df1","line":131,"in_reply_to":"44f7a821_db6385fc","updated":"2026-04-17 14:37:25.000000000","message":"A generalization of the problem is basically the question of the life-cycle of a group.\n\n* Can a user add more devices to the group via reconfiguration. When the group is allocated / free?\n* Can the user remove devices from a group via reconfiguration. When the group is allocated / free?\n* What happens when a device currently in group disappears from a host (i.e. dies). While the group is allocated / free?\n* If we enforce that the size of the groups (size \u003d num of devs in group) should be the same within a group_type, how does that effect the life-cycle of the group? I.e. growing a group or loosing a device from the group.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."},{"line_number":130,"context_line":"This ensures atomic all-or-nothing allocation."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Pool and Allocation Design"},{"line_number":133,"context_line":"--------------------------"},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"70ab69b2_275c6d89","line":131,"in_reply_to":"57f7b6ac_e9829df1","updated":"2026-04-17 15:25:11.000000000","message":"can i guess they can do anything but in gneraly no\n\n\nGroup types must map to same type of devices across all host in a cloud.\nwhne a group defiens a set of devices that compiese the exected device for a given group_type.\n\nonce a group_type is defiend it cannot be modifyed if its in used by any instance.\n\nas a result a operator cannot extend a group of a given GROUP_TYPE\nwith new devices unless they have draiend all usage of that group_type for ther exisitn instances.\n\nwhat they can do is add or remove groups of a given type\nso if they hage a group trype of 2 gpus and they add a \n4 more gpus ot a host the operator can define 2 more instance fo that group type in the dev spec.\n\nthis is effectively the same rules we have for PCI in placement and alias today.\ntwo instance of a single resouce class are intened to be interchangebale across host, its fine to repmore more inventoies of that resouce class if you install new hardware, and if it free its fine to remove them as well.\n\nthe exising logic we have that prevent use deleting device form the device table if they are allcoated to a vm woudl aslo provide protecion here from typoing the config.\n\n\"\"\"\nWhat happens when a device currently in group disappears from a host (i.e. dies). While the group is allocated / free?\n\"\"\"\n\nwhen allocate the vm is likely going to ehter have runtim issue in the gust or crash and go to the error state.\n\nthe slightly more interesitn question is what happens if the device \"disapers\" as a result from lspci\n\nin the allocated case we will still have the device recored in the db with the pci adress and if you tried to hard reboot the vm it fail in libvirt/qemu as the adres wioudl be \"invalid or a simielr issue\" basiclly libvirt/qemu will complain if it can use the device\n\nin the case where the devices were free it a little trickier\nunless we store how many devices we expect in the db and compare i dont think we can detect it in the case where we sue teh regex/glob syntax\n\nso i agree that we likely need to decifbe that edgace better.\n\ni think adding a atibute to track the number of device we expect in a group may indeed be a way forward here but i have not tought about the full lifecycle implciations\n\nin this failure case we woudl likely want to set resterved\u003dtotal wehn its free or annotate it with a trait or simialr to say \"this is broken\" with a load error/wranign in the compute agent logs.\n\n\nhopefully my splitign of the concept fo a groups (a bag of devices) and a group_type  (the opaque handel that descs an expecte set fo devices) helps\n\nwe coudl add a group_type list that would encode thing like expected number of devices declarity seperate form the devstpec if you think that woudl make it clearer.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."},{"line_number":130,"context_line":"This ensures atomic all-or-nothing allocation."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Pool and Allocation Design"},{"line_number":133,"context_line":"--------------------------"},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"793dcf4c_6d9e3c9f","line":131,"in_reply_to":"70ab69b2_275c6d89","updated":"2026-04-28 14:32:12.000000000","message":"Detailed my view in the spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":128,"context_line":"The group RP has inventory of 1 only when ALL devices in the group are"},{"line_number":129,"context_line":"available. If any device is in use, the group inventory becomes 0."},{"line_number":130,"context_line":"This ensures atomic all-or-nothing allocation."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Pool and Allocation Design"},{"line_number":133,"context_line":"--------------------------"},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"44f7a821_db6385fc","line":131,"in_reply_to":"c814e806_5bbc367b","updated":"2026-02-05 17:16:57.000000000","message":"yes we woould have to first only allow that if the devices are not in use and then delete the old RP and create teh new ones.\n\nwe have logic to detect that but we woudl have to extend it in all likelyhood.\n\nit might work as each device in the groups is stored in the pci_deivces table as its own row \n\nhttps://paste.opendev.org/show/bNb5QrWEubOo5VguSGND/\n\nso the logic the keep the old dev in the pci tracker and prevent freeing the row in teh pci_device tabel shoud lkick in but i have not tested that yet so there are proably bugs.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":141,"context_line":"* When a group is allocated, ALL devices are consumed atomically"},{"line_number":142,"context_line":"  with the same ``request_id``"},{"line_number":143,"context_line":"* The PCI tracker bypasses normal PF/VF dependency logic for group"},{"line_number":144,"context_line":"  devices since all devices are intentionally allocated together"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Live Migration Support"},{"line_number":147,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7b5b6a7a_4fb42799","line":144,"updated":"2026-04-17 14:37:25.000000000","message":"I feel like this is more complicated than it sounds as dependent devices cannot be configured today with PCI in Placement enabled (as it does not support them). So if we need to enable dependent devices within the same group then this needs to be explicitly re-enabled in the code.\n\nHow far we want to go with it:\n* parent PF and child VF within the same group.\n* parent PF and child VF in two separate group\n* parent PF and child VF where one of them is in a group while the other is not in any group but matched by spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":141,"context_line":"* When a group is allocated, ALL devices are consumed atomically"},{"line_number":142,"context_line":"  with the same ``request_id``"},{"line_number":143,"context_line":"* The PCI tracker bypasses normal PF/VF dependency logic for group"},{"line_number":144,"context_line":"  devices since all devices are intentionally allocated together"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Live Migration Support"},{"line_number":147,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b6d76c4c_35b4d58f","line":144,"in_reply_to":"5f8440ff_e4bb51f7","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":141,"context_line":"* When a group is allocated, ALL devices are consumed atomically"},{"line_number":142,"context_line":"  with the same ``request_id``"},{"line_number":143,"context_line":"* The PCI tracker bypasses normal PF/VF dependency logic for group"},{"line_number":144,"context_line":"  devices since all devices are intentionally allocated together"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Live Migration Support"},{"line_number":147,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f8440ff_e4bb51f7","line":144,"in_reply_to":"7b5b6a7a_4fb42799","updated":"2026-04-17 15:25:11.000000000","message":"i want to supprot PFs and VFs in the same group but if a PF is listed it must not have VFs listed as a group or not.\n\nso i woudl codier it an error to PF and there child VF in the same group ro diffent groups.\n\ni need to make this clearer.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":143,"context_line":"* The PCI tracker bypasses normal PF/VF dependency logic for group"},{"line_number":144,"context_line":"  devices since all devices are intentionally allocated together"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Live Migration Support"},{"line_number":147,"context_line":"----------------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"A PCI device group is live-migratable only if ALL devices in the group"}],"source_content_type":"text/x-rst","patch_set":2,"id":"327edfae_466c5b8e","line":146,"updated":"2026-04-17 14:37:25.000000000","message":"I think it worth mentioning that live migration of a VM with multiple PCI devices means a mapping of source PCI device - dest PCI device needs to be calculated. As we support such thing without the groups already we assume that devices in groups will be handled similarly when need to map. \n\nBut this also points to the fact that two group from the same group_type needs to have the same number of device otherwise the mapping during live migration will not work.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":143,"context_line":"* The PCI tracker bypasses normal PF/VF dependency logic for group"},{"line_number":144,"context_line":"  devices since all devices are intentionally allocated together"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Live Migration Support"},{"line_number":147,"context_line":"----------------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"A PCI device group is live-migratable only if ALL devices in the group"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5722f1c8_50434920","line":146,"in_reply_to":"327edfae_466c5b8e","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":153,"context_line":"* If all devices have ``live_migratable\u003d\u0027true\u0027``, the group supports"},{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8f24cf76_c0cbee04","line":156,"updated":"2026-02-05 15:43:27.000000000","message":"I\u0027m a bit confused - would the constituent devices have their own `device_spec` entries, and then one for the group also?\n\n(later)\n\nOh, I see, you have to group devices by listing them independently and using the same group name. I guess I was expecting `address` to be a list or something.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":153,"context_line":"* If all devices have ``live_migratable\u003d\u0027true\u0027``, the group supports"},{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"db4ad882_6eca3ff4","line":156,"in_reply_to":"7a28ee3c_3de9a77b","updated":"2026-04-28 14:32:12.000000000","message":"Acknowledged","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":153,"context_line":"* If all devices have ``live_migratable\u003d\u0027true\u0027``, the group supports"},{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a28ee3c_3de9a77b","line":156,"in_reply_to":"8f24cf76_c0cbee04","updated":"2026-02-05 17:16:57.000000000","message":"we supprot exact addressees, bash globs or regex today so i dint want to also supprot it being a list\n\nbut glob syntax \n```\n# Group 8: 3b:03.0 - 3b:03.7\ndevice_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\", \"live_migratable\": true}\n```\nand regex syntax\n```\n# Group 8: 3b:09.0 - 3b:09.7\ndevice_spec \u003d {\"address\": {\"domain\": \"0000\", \"bus\": \"3b\", \"slot\": \"09\", \"function\": \"[1-7]\"}, \"group_name\": \"nic_group_8\", \"group_type\": \"NICx8\"}\n```\n\nallow you do defien a group in one line.\nin this case you can the capablities of the device woudl have to be the same for that line\n\ni decied adsress was complciate enough today without making it also possibel a list.\n\nalthough i can supprot that if you like as well\n\ndevspec is json. so \n\n```\ndevice_spec \u003d {\"address\": [\"0000:3b:03.1\", \"0000:3b:03.1\"], \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\", \"live_migratable\": true}\n```\nis easy to parse if needed","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"6e009569_8dde8fdf","line":157,"updated":"2026-02-05 14:23:52.000000000","message":"Similarly what is the relationship with other fields like:\n* physical_network: I\u0027m fairly sure that it is not supported for groupped devices as PCI is Placement needed for the groups but physical_network is not supported (yet) in PCI in Placement.\n* remote_managed: I feel that it is not supported for devices in groups)\n* trusted: I\u0027m not sure\n* managed: Probably useful still for each individual device in the group and does can be diverse within the group. But please double check my thinking\n* resource_class: Supported but cannot be divergent across devices in the same group\n* traits: Do we want to union/intersect/or reject if diverse the traits of the devices in the group?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"984489fb_8fb66c2e","line":157,"in_reply_to":"1bab4a26_d0636c9e","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1bab4a26_d0636c9e","line":157,"in_reply_to":"5dcc2a4c_9f6abad7","updated":"2026-04-17 14:37:25.000000000","message":"* Lets document with agreement above about physnet, remote_managed and trusted.\n\n* managed, live_migratbale,one_time_use, resouce_class and traits are all valid in teh devsspec for a group and have the same effect as a normal devspec\n  * live_migratable handled below that is OK\u003e\n  * managed is libvirt domain only and not schedulable so that is good too\n  * traits are being discussed above \n  * one_time_use creates needs to be documented here that if any of the device are marked as one_time_use in the spec then the whole group is one_time_use in nature as the placement inventory of the whole group will be reserved during deallocation.\n  * resouce_class and group_type overlap and therefore precedence needs to be documented in the spec","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":154,"context_line":"  live migration"},{"line_number":155,"context_line":"* If any device has ``live_migratable\u003d\u0027false\u0027`` or the tag is unset,"},{"line_number":156,"context_line":"  the group does not support live migration"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"NUMA Affinity Handling"},{"line_number":159,"context_line":"----------------------"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5dcc2a4c_9f6abad7","line":157,"in_reply_to":"6e009569_8dde8fdf","updated":"2026-02-05 17:16:57.000000000","message":"grouping required pci in placment and we do not supprot physical_network when using that so that out of scope but if we suproted that in the future we would apply it on a per devspc basis\n\nwith that said you can only allocate groups all or nothign and i dont think we would want to allwo you to geta group via a neutorn port so my intet was to consifer it a config error if you specify physical_network on a group\n\nremote_managed and trusted both also only apply to neutron nics so they are not valid\n\nmanaged, live_migratbale,one_time_use, resouce_class and traits are all valid in teh devsspec for  a group and have the same effect as a normal devspec\n\n\nresource_class is kind of redudatn with group_type since the placement rescoue class for the groups is derived form group_type but we can allow you to overwrite it\n\n```\ndebian@hibernal01:~$ openstack --os-cloud devstack-admin resource provider inventory list 5538f512-52f3-4b72-b6b8-55f9e917f0ca\n+------------------------+------------------+----------+----------+----------+-----------+-------+------+\n| resource_class         | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used |\n+------------------------+------------------+----------+----------+----------+-----------+-------+------+\n| CUSTOM_PCI_GROUP_NICX8 |              1.0 |        1 |        1 |        0 |         1 |     1 |    0 |\n+------------------------+------------------+----------+----------+----------+-----------+-------+------+\n```\n\n```\ndebian@hibernal01:~$ openstack --os-cloud devstack-admin resource provider trait list 5538f512-52f3-4b72-b6b8-55f9e917f0ca\n+----------------------------+\n| name                       |\n+----------------------------+\n| COMPUTE_MANAGED_PCI_DEVICE |\n+----------------------------+\n```","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":160,"context_line":""},{"line_number":161,"context_line":"NUMA affinity policies are evaluated across ALL devices in a group:"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* **REQUIRED/STRICT**: All devices in the group must have NUMA"},{"line_number":164,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":165,"context_line":"* **SOCKET**: All devices must be on the same socket as the guest"},{"line_number":166,"context_line":"* **PREFER/LEGACY**: Groups are sorted by NUMA affinity score (count"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0149f8f1_107efa67","line":163,"range":{"start_line":163,"start_character":13,"end_line":163,"end_character":19},"updated":"2026-04-17 14:37:25.000000000","message":"Do we have STRICT as a possible value for NUMA policy?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":160,"context_line":""},{"line_number":161,"context_line":"NUMA affinity policies are evaluated across ALL devices in a group:"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* **REQUIRED/STRICT**: All devices in the group must have NUMA"},{"line_number":164,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":165,"context_line":"* **SOCKET**: All devices must be on the same socket as the guest"},{"line_number":166,"context_line":"* **PREFER/LEGACY**: Groups are sorted by NUMA affinity score (count"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9daa639d_648b0c2a","line":163,"range":{"start_line":163,"start_character":13,"end_line":163,"end_character":19},"in_reply_to":"0149f8f1_107efa67","updated":"2026-04-17 15:25:11.000000000","message":"\"strict\" was the intel name for \"required\" so that just an old habit\n\nill fix that\n\n\"the required policy enfoces strict affinty\"\n\nis how i think of this in my head.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":160,"context_line":""},{"line_number":161,"context_line":"NUMA affinity policies are evaluated across ALL devices in a group:"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* **REQUIRED/STRICT**: All devices in the group must have NUMA"},{"line_number":164,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":165,"context_line":"* **SOCKET**: All devices must be on the same socket as the guest"},{"line_number":166,"context_line":"* **PREFER/LEGACY**: Groups are sorted by NUMA affinity score (count"}],"source_content_type":"text/x-rst","patch_set":2,"id":"78f3d175_b368a883","line":163,"range":{"start_line":163,"start_character":13,"end_line":163,"end_character":19},"in_reply_to":"9daa639d_648b0c2a","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":163,"context_line":"* **REQUIRED/STRICT**: All devices in the group must have NUMA"},{"line_number":164,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":165,"context_line":"* **SOCKET**: All devices must be on the same socket as the guest"},{"line_number":166,"context_line":"* **PREFER/LEGACY**: Groups are sorted by NUMA affinity score (count"},{"line_number":167,"context_line":"  of devices with affinity), but no groups are rejected"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Configuration Examples"}],"source_content_type":"text/x-rst","patch_set":2,"id":"70b7908e_48511825","line":166,"range":{"start_line":166,"start_character":4,"end_line":166,"end_character":10},"updated":"2026-04-17 14:37:25.000000000","message":"\"preferred\" I guess","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":163,"context_line":"* **REQUIRED/STRICT**: All devices in the group must have NUMA"},{"line_number":164,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":165,"context_line":"* **SOCKET**: All devices must be on the same socket as the guest"},{"line_number":166,"context_line":"* **PREFER/LEGACY**: Groups are sorted by NUMA affinity score (count"},{"line_number":167,"context_line":"  of devices with affinity), but no groups are rejected"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Configuration Examples"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f9fce99a_2746d675","line":166,"range":{"start_line":166,"start_character":4,"end_line":166,"end_character":10},"in_reply_to":"70b7908e_48511825","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":184,"context_line":"    device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":185,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":186,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":187,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":188,"context_line":"    alias \u003d {\"name\": \"c200_x1\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X1\"}"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"But exposing the two cards, exposed as four PCI devices,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7fa01eda_80306bd2","line":187,"updated":"2026-02-05 15:43:27.000000000","message":"This feels laborious and clumsy to me, and also that automated (like CRUD) maintenance of this list becomes harder (granted, it\u0027s already hard and clumsy).","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":184,"context_line":"    device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":185,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":186,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":187,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":188,"context_line":"    alias \u003d {\"name\": \"c200_x1\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X1\"}"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"But exposing the two cards, exposed as four PCI devices,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c433d5b9_a28559d0","line":187,"in_reply_to":"0405494d_9a04bd62","updated":"2026-05-08 14:46:29.000000000","message":"Actually we can simplify the device_spec in the example :) Done.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":true,"context_lines":[{"line_number":184,"context_line":"    device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":185,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x1\"}"},{"line_number":186,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":187,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_2\", \"group_type\": \"c200_x1\"}"},{"line_number":188,"context_line":"    alias \u003d {\"name\": \"c200_x1\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X1\"}"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"But exposing the two cards, exposed as four PCI devices,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0405494d_9a04bd62","line":187,"in_reply_to":"7fa01eda_80306bd2","updated":"2026-04-28 14:32:12.000000000","message":"We did not touched on this during the PTG. But lets discuss it in the spec now if needed. This design comes from the original 2023.1 spec. \n\nAn alternative could be keeping the device_spec as is and adding a separate config that defines a grouping of the devices. But then we would somehow re-identify the devices when defining the group in a similar way how we identify device in the device_spec. So that would not be easier.\n\n@dms@danplanet.com do you have some specific direction we should investigate about a better configuration model for the groups?\n\nThe minimum req of any config model is:\n* A way to define what can be requested from the pci alias, i.e. a group_type\n* A way to define instances of the group_type (to support multiple groups of the same group_type on the same compute)\n* A way to assign devices to a group\n* A way to assign extra properties to a group like traits\n* A way to assign extra properties to a group_type like the resource_class to override the default one if needed.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"09be9125_fab5f203","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"updated":"2026-02-05 14:23:52.000000000","message":"as configuring the alias this way needs the knowledge of the RC generation logic in nova do we want to add support for group_type as a syntactic sugar to the alias as well?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9f59dcb5e45b3886b3ecbfdd1d27e8ef8938e466","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"50d42a85_f4e0c3f7","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"01ebffea_50f79a23","updated":"2026-04-17 17:44:02.000000000","message":"if we allow any RC to be used in the group definition in the device_spec then that group is only requestable in the alias if we allow resource_class in the alias too. So we need to decide the device_spec suport case first then that will inform what we need to support in the alias","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c867fb12_a397e2f9","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"09be9125_fab5f203","updated":"2026-02-05 17:16:57.000000000","message":"no this is a bug you need group_type in the alias\n```\n# Alias for requesting NICx8 groups via flavor\nalias \u003d {\"name\": \"NICx8\", \"resource_class\": \"CUSTOM_PCI_GROUP_NICX8\", \"group_type\": \"NICx8\"}\n```\n\"resource_class\": \"CUSTOM_PCI_GROUP_NICX8\" is optional in this case it was there because i orgianlly had a bug in may poc \n\nso this is what i woudl expect folks to actully use.\n```\nalias \u003d {\"name\": \"NICx8\", \"group_type\": \"NICx8\"}\n```\n\nbut you jsut need to know the group_type to make it work.\n\n\nif i really wanted i could probaly make this work without pci in placmeent if im behing honest\n\ni dont specificly see a blocker to supproting that but it was out of scope fo the spec before so i didnt want to bring it in in the new revision.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"94887c50_254096a4","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"50d42a85_f4e0c3f7","updated":"2026-04-28 14:32:12.000000000","message":"As discussed on the PTG we support both group_type and resource_class override in the [pci]alias. I\u0027ve updated the spec accordingly.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9607833603cda3df579ebe4390b09569506d2c33","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"01ebffea_50f79a23","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"8c43b9f1_127aeb69","updated":"2026-04-17 15:31:31.000000000","message":"just to clarify the exeact way we implemnt the resouce class in placment feels like an implemation detail that operators shoudl not need to understand in the happy path. group_type gives us an indriection where we can hide those details behind a afordance that also makes the overcall ux cleaner.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ed806da121e5c620c8c0fe5ddae79618b67e681","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8c43b9f1_127aeb69","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"b6c4f752_1e368222","updated":"2026-04-17 15:25:11.000000000","message":"well alias \u003d {\"name\": \"NICx8\", \"group_type\": \"NICx8\"} is the inteded way for it to work\n\nbut the example was before i fixed the bug i had in the poc\n\nalias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}\nwill also work.\n\nalias \u003d {\"name\": \"c200_x2\", \"group_type\": \"C200_X2\"}\n\nis identical and less typing.\n\nwe have speical resource_class normalistation logic toady that will take\n\n\"resource_class\": \"c200\" and convert it to  \"CUSTOM_PCI_C200\"\n\ni.e. it handel the PREFIXING wiht CUSTOM_ and making it uppercase with undersores\n\ngroup_type play the same role for groups","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":195,"context_line":"    device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":196,"context_line":"    device_spec \u003d {\"address\": \"0000:89:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":197,"context_line":"    device_spec \u003d {\"address\": \"0000:8a:00.0\", \"group_name\": \"graphcore_1\", \"group_type\": \"c200_x2\"}"},{"line_number":198,"context_line":"    alias \u003d {\"name\": \"c200_x2\", \"resource_class\": \"CUSTOM_PCI_GROUP_C200_X2\"}"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Alternatives"},{"line_number":201,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b6c4f752_1e368222","line":198,"range":{"start_line":198,"start_character":32,"end_line":198,"end_character":76},"in_reply_to":"c867fb12_a397e2f9","updated":"2026-04-17 14:37:25.000000000","message":"I guess we then need both group_type and RC support in the alias and then define the precedence there as well.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":206,"context_line":"Data model impact"},{"line_number":207,"context_line":"-----------------"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"The following internal data structures and classes are modified or added:"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"**PciDeviceSpec (nova/pci/devspec.py)**"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* New constants: ``GROUP_NAME_TAG``, ``GROUP_TYPE_TAG``"},{"line_number":214,"context_line":"* New method: ``get_group_info()`` returns ``(group_name, group_type)``"},{"line_number":215,"context_line":"  tuple if the device is part of a group, otherwise ``None``"},{"line_number":216,"context_line":"* New validation: ``_validate_group_tags()`` enforces mutual dependency"},{"line_number":217,"context_line":"  of both group tags and requires ``report_in_placement \u003d True``"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"**Whitelist (nova/pci/whitelist.py)**"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* New method: ``get_groups()`` returns a dict mapping group names to"},{"line_number":222,"context_line":"  lists of device specs in each group"},{"line_number":223,"context_line":"* New method: ``_validate_groups()`` enforces validation rules (minimum"},{"line_number":224,"context_line":"  2 devices per group, same group_type, no duplicate addresses)"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"**PciDeviceStats (nova/pci/stats.py)**"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"* Pool keys extended with ``group_name`` and ``group_type``"},{"line_number":229,"context_line":"* New method: ``_is_group_pool()`` identifies group pools"},{"line_number":230,"context_line":"* New method: ``_allocate_group()`` atomically consumes all devices"},{"line_number":231,"context_line":"* New method: ``_update_group_pool_live_migratable()`` applies most"},{"line_number":232,"context_line":"  restrictive live_migratable value across group devices"},{"line_number":233,"context_line":"* New NUMA filtering methods for group pools"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"**PciGroupResourceProvider (nova/compute/pci_placement_translator.py)**"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"* New class to represent a group as a single Placement resource provider"},{"line_number":238,"context_line":"* Manages list of devices, resource class, and traits"},{"line_number":239,"context_line":"* ``total`` property returns 1 only when ALL devices are available"},{"line_number":240,"context_line":"* ``update_provider_tree()`` creates/updates the group RP in Placement"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"**PciDevTracker (nova/pci/manager.py)**"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"* Atomic claim/allocate operations bypass PF/VF dependency logic for"},{"line_number":245,"context_line":"  group devices (identified by ``request_id`` field)"},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"No database schema changes are required. Group membership is tracked"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c5d40efb_5063fc81","line":244,"range":{"start_line":209,"start_character":0,"end_line":244,"end_character":56},"updated":"2026-04-28 14:32:12.000000000","message":"Dropping it as very much an implementation detail","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":286,"context_line":"* Each group must contain at least 2 devices"},{"line_number":287,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"**Error Messages:**"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Operators will encounter the following errors for invalid configurations:"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"* ``\"group_name and group_type must be specified together\"`` - when only"},{"line_number":294,"context_line":"  one tag is provided"},{"line_number":295,"context_line":"* ``\"PCI groups require report_in_placement to be enabled\"`` - when"},{"line_number":296,"context_line":"  groups are configured without Placement tracking"},{"line_number":297,"context_line":"* ``\"PCI group \u0027X\u0027 must have at least 2 devices, but only has 1\"`` - when"},{"line_number":298,"context_line":"  a group has insufficient devices"},{"line_number":299,"context_line":"* ``\"PCI group \u0027X\u0027 has mixed group_type values\"`` - when devices in the"},{"line_number":300,"context_line":"  same group have different group_type values"},{"line_number":301,"context_line":"* ``\"Device \u0027X\u0027 is configured in multiple groups\"`` - when the same"},{"line_number":302,"context_line":"  device address appears in multiple groups"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"**Live Migration Configuration:**"},{"line_number":305,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"82200835_af8de5c5","line":302,"range":{"start_line":289,"start_character":0,"end_line":302,"end_character":43},"updated":"2026-04-28 14:32:12.000000000","message":"This feels like an implementation detail. Dropping it.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":328,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":329,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":330,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"**Rolling upgrade considerations:**"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"When upgrading a deployment:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1c2d0e49_07e6987f","line":331,"updated":"2026-02-05 14:23:52.000000000","message":"Similarly we might want to have the reverse procedure in the spec (outside of upgrade) saying how can one remove an individual device from a group and consume it as an individual device.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"49196a3c5bcc21bd7a3e5aa77b403e3596a9d578","unresolved":true,"context_lines":[{"line_number":328,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":329,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":330,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"**Rolling upgrade considerations:**"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"When upgrading a deployment:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"621fb278_5d77ac42","line":331,"in_reply_to":"1c2d0e49_07e6987f","updated":"2026-02-05 15:43:27.000000000","message":"What happens if they skip step 1 above? Will compute survey instances before modifying the config in placement?","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":328,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":329,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":330,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"**Rolling upgrade considerations:**"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"When upgrading a deployment:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5cac01e4_1f399579","line":331,"in_reply_to":"1d5022a8_bffc1bd6","updated":"2026-04-17 14:37:25.000000000","message":"\u003e i suggested makign that a start up error that block nova-comptue starting in the past but we desied that was too extreame and just log a large warning\n\nThe reason of it is the following. If you have 20 VMs on a host. One allocated PCI device dies and dissapearse from the host then 1 VM is probably in trouble. But by preventing nova-compute to be restarted in this state casues that the other 19 VM becomes unmanageable (other than evacuation).\n\nWe need to agree that we do the same for the groups and then mention that in the spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":328,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":329,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":330,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"**Rolling upgrade considerations:**"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"When upgrading a deployment:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0e27e5a7_1f6ba4e2","line":331,"in_reply_to":"5cac01e4_1f399579","updated":"2026-04-28 14:32:12.000000000","message":"My current working assumption but we need to test is:\n* When a device_spec change removes a device from the config while the device is allocated nova keeps the device in the tracker. (I\u0027m pretty sure about this behavior today with non groupped devices)\n* If this device re-appear without further changes then nova keep using it. (i.e. temporary mistake in the config that is fixed, or a device replacement with the same type)\n* if this pci address reappears with different config / type / then the that should be a hard error at nova-compute starutp. I\u0027m not sure this is in place today. But it will be even more important when grouping is implemented to avoid removing a device from a group while it is in use and re-adding the same device but now in a different group. We need to prevent that.\n\nI added wording about it in the spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":328,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":329,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":330,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"**Rolling upgrade considerations:**"},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"When upgrading a deployment:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1d5022a8_bffc1bd6","line":331,"in_reply_to":"621fb278_5d77ac42","updated":"2026-02-05 17:16:57.000000000","message":"we have some productions in teh pci tracker today but i likely need to harden it more\n\nso today if you modify the pci devspecs and remove a device that is assgiend to a vm we keep the device in the pci tracker and in the database assinted to that vm and it only gets removed when the vm is deleted or mvoed\n\n\ni suggested makign that a start up error that block nova-comptue starting in the past but we desied that was too extreame and just log a large warning \n\nso i woudl proably block the reportign fo the group until this is fix and issue a warning on startup.\n\ngoing backward i thinks is basiclly the same procedure it just make sure the group is not in use.  and update the config, nova will need to delete the rp for the group and then create the new rps for the indiviual devices","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":339,"context_line":"  older nodes will not report the new group resource classes"},{"line_number":340,"context_line":"* No API or conductor changes are required"},{"line_number":341,"context_line":"* Flavors with group aliases can be created before all computes are"},{"line_number":342,"context_line":"  upgraded; scheduling will only select upgraded hosts"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"**Backward compatibility:**"},{"line_number":345,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1b17eab3_25ae3357","line":342,"updated":"2026-04-17 14:37:25.000000000","message":"yepp this seems OK. PCI in Placement gating is there and after that Placement will gate the scheduling.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":339,"context_line":"  older nodes will not report the new group resource classes"},{"line_number":340,"context_line":"* No API or conductor changes are required"},{"line_number":341,"context_line":"* Flavors with group aliases can be created before all computes are"},{"line_number":342,"context_line":"  upgraded; scheduling will only select upgraded hosts"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"**Backward compatibility:**"},{"line_number":345,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"71beb2e1_f3098923","line":342,"in_reply_to":"1b17eab3_25ae3357","updated":"2026-04-28 14:32:12.000000000","message":"Done","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0f750ce8d7b02c412195b5294d44a0f7ab128b1","unresolved":true,"context_lines":[{"line_number":360,"context_line":"---------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Feature liaison:"},{"line_number":363,"context_line":"  gibi?"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"781e92fb_866861df","line":363,"updated":"2026-02-05 14:23:52.000000000","message":"sure but depending on capacity/priority/scheduling","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":true,"context_lines":[{"line_number":360,"context_line":"---------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Feature liaison:"},{"line_number":363,"context_line":"  gibi?"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d9302e16_937672a1","line":363,"in_reply_to":"5cbf194c_3cd762e9","updated":"2026-04-28 14:32:12.000000000","message":"Plan are in flux. I was asked to discuss this feature on the PTG and hinted towards taking it over entirely. So after the PTG took the liberty and updated the spec with the discussion points from the PTG. At the same time I\u0027m tentatively flipping Primary assignee and Feature liaison here. As soon as my employer decided the resource allocation firmly I will finalized these assignments as well in the spec.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"47b7d76fdaa9811d6ec29d52d2efc4c5b7b2b1de","unresolved":true,"context_lines":[{"line_number":360,"context_line":"---------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Feature liaison:"},{"line_number":363,"context_line":"  gibi?"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dc7f44e4_5ccb3e23","line":363,"in_reply_to":"781e92fb_866861df","updated":"2026-02-05 17:16:57.000000000","message":"this is here just because your name with a question mark was in the previsly appvoed spec https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/pci-passthrough-groups.html#feature-liaison 😊\n\nand i was hoping you would be ok with it but if not i can update.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":360,"context_line":"---------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Feature liaison:"},{"line_number":363,"context_line":"  gibi?"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"abf71c2c_474ead10","line":363,"in_reply_to":"d9302e16_937672a1","updated":"2026-05-08 16:47:58.000000000","message":"Ack we can work out how to progress this together as the cycle progresses\nas i said im happy to review, test or implement as required.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1eff459d5bab7d67ea321a7b0c6b2fc5d85edf4a","unresolved":true,"context_lines":[{"line_number":360,"context_line":"---------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Feature liaison:"},{"line_number":363,"context_line":"  gibi?"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5cbf194c_3cd762e9","line":363,"in_reply_to":"dc7f44e4_5ccb3e23","updated":"2026-04-17 14:37:25.000000000","message":"Commitment from more than 2 years ago is non-transferable automatically :) \nBut it very much seems that I\u0027m the lucky guy this time again.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":365,"context_line":"Work Items"},{"line_number":366,"context_line":"----------"},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"1. **Configuration Layer (nova/conf/pci.py, nova/pci/devspec.py)**"},{"line_number":369,"context_line":""},{"line_number":370,"context_line":"   * Add ``group_name`` and ``group_type`` tag documentation"},{"line_number":371,"context_line":"   * Implement tag parsing and validation in ``PciDeviceSpec``"},{"line_number":372,"context_line":"   * Add ``get_group_info()`` method to retrieve group membership"},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"2. **Whitelist Validation (nova/pci/whitelist.py)**"},{"line_number":375,"context_line":""},{"line_number":376,"context_line":"   * Add ``get_groups()`` method to collect devices by group name"},{"line_number":377,"context_line":"   * Add ``_validate_groups()`` to enforce group constraints"},{"line_number":378,"context_line":""},{"line_number":379,"context_line":"3. **Placement Integration (nova/compute/pci_placement_translator.py)**"},{"line_number":380,"context_line":""},{"line_number":381,"context_line":"   * Create ``PciGroupResourceProvider`` class"},{"line_number":382,"context_line":"   * Implement group RP creation with inventory\u003d1 semantics"},{"line_number":383,"context_line":"   * Add group device routing in ``PlacementView``"},{"line_number":384,"context_line":""},{"line_number":385,"context_line":"4. **Pool Management (nova/pci/stats.py)**"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"   * Extend pool keys with group_name and group_type"},{"line_number":388,"context_line":"   * Add ``_is_group_pool()`` identification method"},{"line_number":389,"context_line":"   * Implement ``_allocate_group()`` for atomic allocation"},{"line_number":390,"context_line":"   * Add ``_update_group_pool_live_migratable()`` for live migration"},{"line_number":391,"context_line":"   * Add NUMA affinity filtering methods for group pools"},{"line_number":392,"context_line":""},{"line_number":393,"context_line":"5. **Claim and Allocation (nova/pci/manager.py)**"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"   * Modify ``_claim_instance()`` to handle group devices"},{"line_number":396,"context_line":"   * Modify ``_allocate_instance()`` for atomic group allocation"},{"line_number":397,"context_line":"   * Bypass PF/VF dependency logic for group devices"},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"6. **Unit Tests**"},{"line_number":400,"context_line":""},{"line_number":401,"context_line":"   * test_devspec.py - group tag parsing and validation"},{"line_number":402,"context_line":"   * test_whitelist.py - group validation rules"},{"line_number":403,"context_line":"   * test_stats.py - group pool handling, live_migratable, NUMA"},{"line_number":404,"context_line":"   * test_pci_placement_translator.py - PciGroupResourceProvider"},{"line_number":405,"context_line":""},{"line_number":406,"context_line":"7. **Functional Tests**"},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"   * PlacementPCIGroupTests - inventory, allocation, scheduling"},{"line_number":409,"context_line":"   * PlacementPCIGroupLiveMigrationTests - live migration scenarios"},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"8. **Documentation**"},{"line_number":412,"context_line":""},{"line_number":413,"context_line":"   * Update admin guide for PCI passthrough"},{"line_number":414,"context_line":"   * Add developer reference documentation"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Dependencies"},{"line_number":417,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":418,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"04122edf_94d72046","line":415,"range":{"start_line":368,"start_character":0,"end_line":415,"end_character":0},"updated":"2026-04-28 14:32:12.000000000","message":"Simplified to remove implementation details like then names of private functions.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"60af217d4850a63d14db98e598fa2b6f86bfaa47","unresolved":false,"context_lines":[{"line_number":421,"context_line":"Testing"},{"line_number":422,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":423,"context_line":""},{"line_number":424,"context_line":"**Unit Tests (nova/tests/unit/pci/)**"},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"* ``test_devspec.py`` - Tests for group tag parsing:"},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"  * Extraction of group_name and group_type from device_spec"},{"line_number":429,"context_line":"  * Validation that both tags must be specified together"},{"line_number":430,"context_line":"  * Validation that report_in_placement must be enabled"},{"line_number":431,"context_line":""},{"line_number":432,"context_line":"* ``test_whitelist.py`` - Tests for group validation:"},{"line_number":433,"context_line":""},{"line_number":434,"context_line":"  * Groups with fewer than 2 devices are rejected"},{"line_number":435,"context_line":"  * Groups with 2+ devices are accepted"},{"line_number":436,"context_line":"  * Devices in multiple groups are rejected"},{"line_number":437,"context_line":"  * Mixed group_type values in same group are rejected"},{"line_number":438,"context_line":""},{"line_number":439,"context_line":"* ``test_stats.py`` - Tests for pool and allocation:"},{"line_number":440,"context_line":""},{"line_number":441,"context_line":"  * Group pools identified correctly by _is_group_pool()"},{"line_number":442,"context_line":"  * Atomic allocation consumes all devices"},{"line_number":443,"context_line":"  * live_migratable uses most restrictive value"},{"line_number":444,"context_line":"  * NUMA affinity filtering for group pools"},{"line_number":445,"context_line":""},{"line_number":446,"context_line":"* ``test_pci_placement_translator.py`` - Tests for Placement:"},{"line_number":447,"context_line":""},{"line_number":448,"context_line":"  * Group RP inventory is always 1"},{"line_number":449,"context_line":"  * Resource class generated from group_type"},{"line_number":450,"context_line":"  * All devices get same RP UUID"},{"line_number":451,"context_line":"  * Allocation updates all devices atomically"},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"**Functional Tests (nova/tests/functional/libvirt/test_pci_in_placement.py)**"},{"line_number":454,"context_line":""},{"line_number":455,"context_line":"* ``PlacementPCIGroupTests`` class:"},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"  * test_pci_group_rp_inventory_reported - Groups reported with inventory\u003d1"},{"line_number":458,"context_line":"  * test_pci_group_allocation_claims_all_devices - Atomic allocation"},{"line_number":459,"context_line":"  * test_pci_group_freed_on_delete - Devices freed on instance delete"},{"line_number":460,"context_line":"  * test_pci_group_scheduling_fails_insufficient_groups - NoValidHost"},{"line_number":461,"context_line":"  * test_pci_group_scheduling_with_alias - Flavor alias scheduling"},{"line_number":462,"context_line":"  * test_pci_group_with_heterogeneous_devices - Mixed device types"},{"line_number":463,"context_line":"  * test_pci_group_with_numa_affinity - NUMA policy handling"},{"line_number":464,"context_line":"  * test_pci_group_scheduling_respects_numa_strict - NUMA strict policy"},{"line_number":465,"context_line":""},{"line_number":466,"context_line":"* ``PlacementPCIGroupLiveMigrationTests`` class:"},{"line_number":467,"context_line":""},{"line_number":468,"context_line":"  * test_pci_group_live_migrate_success_all_devices_live_migratable"},{"line_number":469,"context_line":"  * test_pci_group_live_migrate_fails_one_device_not_live_migratable"},{"line_number":470,"context_line":"  * test_pci_group_live_migrate_fails_device_unset_live_migratable"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"These tests use the existing fake libvirt driver infrastructure and do"},{"line_number":473,"context_line":"not require specialized hardware."},{"line_number":474,"context_line":""},{"line_number":475,"context_line":"Documentation Impact"},{"line_number":476,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"758c2c4d_6e98990e","line":473,"range":{"start_line":424,"start_character":0,"end_line":473,"end_character":33},"updated":"2026-04-28 14:32:12.000000000","message":"Trimmed heavily as most of it is implementation detail.","commit_id":"f6ca110cad80c17846cfc1a3ed765bb068fb74f3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":24,"context_line":"Some PCI devices only make sense to be consumed as a group."},{"line_number":25,"context_line":"When you assign the grouped PCI devices to a VM, all of the"},{"line_number":26,"context_line":"devices in the group are always consumed together by a single VM."},{"line_number":27,"context_line":"Currently Nova does not understand any grouping other than"},{"line_number":28,"context_line":"NUMA affinity."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"While there are some cases where a device could be consumed by"}],"source_content_type":"text/x-rst","patch_set":3,"id":"38f62761_627e5305","line":27,"range":{"start_line":27,"start_character":39,"end_line":27,"end_character":47},"updated":"2026-04-29 20:24:41.000000000","message":"this is probaly form my or the orgininal specs wording but refelctign on some to the quetion that came up in the reviwe i have a general terminology suggestion to help with the clarity of this.\n\ninsted of grouping lets use `affinity` here.\n\nthe reaons to avoid grouping here is we are defineign groups as indivsiable\n\nwere as pci devices that happen to share a numa node can in general be allocated independently\n\nso in the problem statement wew shoudlsay the only wahy ot have aggreates of pci devices today based on a common trait is numa affinity of phsyical network\n\nwithin this spec lets try to use the term group \n\nwe could also add a very short terminology glossary if we wanted to make this more explity.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Some PCI devices only make sense to be consumed as a group."},{"line_number":25,"context_line":"When you assign the grouped PCI devices to a VM, all of the"},{"line_number":26,"context_line":"devices in the group are always consumed together by a single VM."},{"line_number":27,"context_line":"Currently Nova does not understand any grouping other than"},{"line_number":28,"context_line":"NUMA affinity."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"While there are some cases where a device could be consumed by"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f6f21b11_f5ef0835","line":27,"range":{"start_line":27,"start_character":39,"end_line":27,"end_character":47},"in_reply_to":"38f62761_627e5305","updated":"2026-05-08 14:46:29.000000000","message":"Changed the wording here. Let me know if this is better or not.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Each physical card presents two PCI devices. The card can be used"},{"line_number":59,"context_line":"independently of other cards if a matched pair of devices are"},{"line_number":60,"context_line":"presented to the VM. PCI groups allows this device to be correctly"},{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"155d3da0_ab7ffc61","line":60,"range":{"start_line":60,"start_character":21,"end_line":60,"end_character":38},"updated":"2026-04-28 15:49:11.000000000","message":"nit if you respin, this should be \"PCI grouping allows\" or \"PCI groups allow\"","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Each physical card presents two PCI devices. The card can be used"},{"line_number":59,"context_line":"independently of other cards if a matched pair of devices are"},{"line_number":60,"context_line":"presented to the VM. PCI groups allows this device to be correctly"},{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"747687f6_17980327","line":60,"range":{"start_line":60,"start_character":21,"end_line":60,"end_character":38},"in_reply_to":"155d3da0_ab7ffc61","updated":"2026-04-29 20:24:41.000000000","message":"alternitivly someting like this building on dans suggetion.\n\n```\npresented to the VM. PCI groups allow this set of devices to be correctly\n```\n\n```suggestion\npresented to the VM. PCI grouping allows these devices to be correctly\n```","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Each physical card presents two PCI devices. The card can be used"},{"line_number":59,"context_line":"independently of other cards if a matched pair of devices are"},{"line_number":60,"context_line":"presented to the VM. PCI groups allows this device to be correctly"},{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"c30d4446_dacb6eb8","line":60,"range":{"start_line":60,"start_character":21,"end_line":60,"end_character":38},"in_reply_to":"747687f6_17980327","updated":"2026-05-08 14:46:29.000000000","message":"Done","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"In addition, some servers can be statically configured to group"},{"line_number":65,"context_line":"either two devices, four devices or eight devices as a single group."},{"line_number":66,"context_line":"These can all be statically configured using PCI group to ensure"},{"line_number":67,"context_line":"we always respect the non-PCI connectivity between those PCI devices."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Other than Graphcore C200 devices, both major GPU vendors support connecting"},{"line_number":70,"context_line":"multiple GPU cards together (see Nvidia NVLink and AMD InfinityFabric) outside"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dc6cea9d_997d4732","line":67,"range":{"start_line":64,"start_character":0,"end_line":67,"end_character":69},"updated":"2026-04-28 15:49:11.000000000","message":"I don\u0027t think I understand this paragraph. \"some servers can group devices into a group\" ...? Is that referring to some behavior of physical servers? I assume the second sentence is referring to a *nova* PCI group being configured to reflect this physical grouping?","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"In addition, some servers can be statically configured to group"},{"line_number":65,"context_line":"either two devices, four devices or eight devices as a single group."},{"line_number":66,"context_line":"These can all be statically configured using PCI group to ensure"},{"line_number":67,"context_line":"we always respect the non-PCI connectivity between those PCI devices."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Other than Graphcore C200 devices, both major GPU vendors support connecting"},{"line_number":70,"context_line":"multiple GPU cards together (see Nvidia NVLink and AMD InfinityFabric) outside"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a7a06118_1cdff104","line":67,"range":{"start_line":64,"start_character":0,"end_line":67,"end_character":69},"in_reply_to":"b35ba6c1_0ed1e364","updated":"2026-05-08 14:46:29.000000000","message":"Done","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":61,"context_line":"passed through to VMs by ensuring a matched pair of PCI devices are"},{"line_number":62,"context_line":"always assigned to each VM."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"In addition, some servers can be statically configured to group"},{"line_number":65,"context_line":"either two devices, four devices or eight devices as a single group."},{"line_number":66,"context_line":"These can all be statically configured using PCI group to ensure"},{"line_number":67,"context_line":"we always respect the non-PCI connectivity between those PCI devices."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Other than Graphcore C200 devices, both major GPU vendors support connecting"},{"line_number":70,"context_line":"multiple GPU cards together (see Nvidia NVLink and AMD InfinityFabric) outside"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b35ba6c1_0ed1e364","line":67,"range":{"start_line":64,"start_character":0,"end_line":67,"end_character":69},"in_reply_to":"dc6cea9d_997d4732","updated":"2026-04-29 20:24:41.000000000","message":"let use teh term `compute node` or `hypervisor host` when we are talkign about the phsyical host for calrity\n\n\n\n```suggestion\nIn addition, some compute nodes can be statically configured to partition\neither two devices, four devices or eight devices as a single group.\nThese can all be statically configured using PCI group to ensure\nwe always allocate them as a single indivisible unit regardless of there\nconnectivity.\n```","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":72,"context_line":"to request connected sets of GPUs to utilize the extra performance"},{"line_number":73,"context_line":"provided via these cross connect technologies. PCI Grouping can model a"},{"line_number":74,"context_line":"static grouping to support this use case."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Proposed change"},{"line_number":77,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"591f2b43_21f318bb","line":75,"updated":"2026-04-29 20:24:41.000000000","message":"do we want to allso just call out that static grouping of any set of assingabel deivces is genericly possibel or just leave that implic.\n\n\ni.e. if you want to provide a gpu, and a usb contoler (that happens to have a keybaor and mouse)  to a vm sothat you can do thinkg like boot vms that can be used with a remote kvm (think nanokvm) can be done\n\nbasiclly any other usecase where you jsut have a set of pci device that shoudl be provide toghether.\n\nthe more concreate one that come to midn is a vituralised E-nodeB\nin the telco edge speace.\n\nthe eNodeB https://en.wikipedia.org/wiki/ENodeB\nis the phsycial element that iterconnect teh radio transcere on a cell tower to the backhaul fiber network and translates between teh two\n\nwe have had 5 moblie carrise build out nova compute at these edge site and manuall group them by booting vms in a specific order on the host to work aroudn this limitaiotn.\n\ni.e. each vm neede to be configure to use manage a specific downling and trnaserver and in there case they coudl nto reboot the vm once it was created so it was trully as static assignment.\n\nthey did mintance by deletign the vm and repovisoning it one at a time\n\nwith thi snew mecanium instead of havign to do that by orderign the vm deletion and creation they coudl describe each pair fo trancerver ancerver mangemnt card and donwlink nic as a group.\n\n\nthis is a case wehre logicly ther eis a corraltion between 2 indepented devices that need to be allcoated as a group but phsycialy there is no interconenctor other relation ship.\n\nthe corralation is prutly down to the management lay fo the vEPC deployemnt\n\nmy understading is they had soem sort of configuration database that used a cartoristic fo the device i.e. it sserial to lookup what there applcation should do so whne the vm boots it introspected the device it was provided and then bootstrap the vm to perfom that funciton.\n\nhow that worked was entirly out of band of openstack but im just providign this as an addtionl usecase that we have had custoerm on our osp 16 and later relases successfully deploy into production even if the operatioanl overhead fo that is high.\n\nwith pci groupign the OPex of that woudl be much impvoed.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":72,"context_line":"to request connected sets of GPUs to utilize the extra performance"},{"line_number":73,"context_line":"provided via these cross connect technologies. PCI Grouping can model a"},{"line_number":74,"context_line":"static grouping to support this use case."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Proposed change"},{"line_number":77,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7d666dd4_77055f46","line":75,"in_reply_to":"591f2b43_21f318bb","updated":"2026-05-08 14:46:29.000000000","message":"I tried to capture this logical grouping in a new use case without going into too much details (I don\u0027t hav) about ENodeB. :)","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":82,"context_line":"  line now either will define a set of matched PCI devices from the host as"},{"line_number":83,"context_line":"  individual devices or directly include them into a named group of devices"},{"line_number":84,"context_line":"  depending on the fields in the spec used."},{"line_number":85,"context_line":"* Devices are linked by both a group type name, and a specific group name. The"},{"line_number":86,"context_line":"  ``group_type`` defines what can be requested via the PCI alias later. While"},{"line_number":87,"context_line":"  the ``group_name`` is just an identifier for the given instance of the"},{"line_number":88,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"faa5e4cf_c9f0f7d7","line":85,"range":{"start_line":85,"start_character":31,"end_line":85,"end_character":41},"updated":"2026-04-29 20:24:41.000000000","message":"if we add a termonolary referece i woudl also defien group_type as a distinct term form pci_group or group_name\n\n\nwhere group_type is a logical colelction pci devices\na pci_group is a concreate set of devics that correspond to a given group_type\nand the group_name is a partial uniqe identifyer for a concreate pci_groups of a give\ngroup type on a speicfic host.\n\n\nthis is defiend in prose below and i understand this implcitly i just recall how useful https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/cpu-resources.html#definitions was to keep everyone on the same page.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":82,"context_line":"  line now either will define a set of matched PCI devices from the host as"},{"line_number":83,"context_line":"  individual devices or directly include them into a named group of devices"},{"line_number":84,"context_line":"  depending on the fields in the spec used."},{"line_number":85,"context_line":"* Devices are linked by both a group type name, and a specific group name. The"},{"line_number":86,"context_line":"  ``group_type`` defines what can be requested via the PCI alias later. While"},{"line_number":87,"context_line":"  the ``group_name`` is just an identifier for the given instance of the"},{"line_number":88,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b851144e_a554842d","line":85,"range":{"start_line":85,"start_character":31,"end_line":85,"end_character":41},"in_reply_to":"9b2dd4da_fa1dc8c0","updated":"2026-05-08 16:47:58.000000000","message":"Acknowledged","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":true,"context_lines":[{"line_number":82,"context_line":"  line now either will define a set of matched PCI devices from the host as"},{"line_number":83,"context_line":"  individual devices or directly include them into a named group of devices"},{"line_number":84,"context_line":"  depending on the fields in the spec used."},{"line_number":85,"context_line":"* Devices are linked by both a group type name, and a specific group name. The"},{"line_number":86,"context_line":"  ``group_type`` defines what can be requested via the PCI alias later. While"},{"line_number":87,"context_line":"  the ``group_name`` is just an identifier for the given instance of the"},{"line_number":88,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9b2dd4da_fa1dc8c0","line":85,"range":{"start_line":85,"start_character":31,"end_line":85,"end_character":41},"in_reply_to":"faa5e4cf_c9f0f7d7","updated":"2026-05-08 14:46:29.000000000","message":"This is changed now as we renamed name to key. And I think that helps a bit already.\n\nI can add a terminology section to the PCI passthrough admin guide when I update it.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"41eb974b_c91d9e9a","line":108,"updated":"2026-04-28 15:49:11.000000000","message":"I just want to say that I re-read this set of bullets, even after previously studying to understand the mechanism here, and it still took me quite a while to re-grok how this is supposed to work. I think part of the problem is that we\u0027re really stretching the already over-stretched representation of things here. Some ideas:\n\n1. I wonder if it would be simpler (less flexible, but simpler) to make `device_spec` take a list of addresses to form a group. I feel like by-address is the only sane way you could make this work anyway, so I don\u0027t think we need to consider `device_spec` by vendor or product matching. Doing this would eliminate the confusing (to me) overlap between `group_name` and `group` and would maybe allow us to renamethe latter to just `group`. The example below would then look like:\n\n```\n# GPU-audio1\ndevice_spec \u003d {\"address\": [\"0000:4a:00.0\", \"0000:4b:00.0\"], group\u003d\"nvidia-gpu-2x\"}\n# GPU-audio2\ndevice_spec \u003d {\"address\": [\"0000:4e:00.0\", \"0000:4f:00.0\"], group\u003d\"nvidia-gpu-2x\"}\nalias \u003d {\"name\": \"gpu-2x\", \"group\": \"nvidia-gpu-2x\"}\n```\n\n(alternately \"address\" could take a single string, with comma-separated addresses if it makes people happier about the duck typing)\n\n2. Changing all the \"group_*\" naming to make them more distinct. Something like `grouping_key` or just \u0027key\u0027 instead of `group_name` would help I think, as it helps convey that the purpose of it is purely to link multiple `device_spec` lines together. I don\u0027t have a very good suggestion for `group_type` but I wonder if we would consider just making the writer specify the `resource_class` for groups and using that to link it to a given alias?\n\n3. Maybe it would be more clear to do the grouping in `alias` itself? Instead of multiple `device_spec` lines grouped by a key, which each need an additional seemingly-duplicative-but-different key to link it to an alias, maybe we do some or all of that in `alias` itself?\n\nOn option:\n```\n# GPU-audio1\ndevice_spec \u003d {\"address\": \"0000:4a:00.0\", \"group\": \"group1\"}\ndevice_spec \u003d {\"address\": \"0000:4b:00.0\", \"group\": \"group1\"}\n# GPU-audio2\ndevice_spec \u003d {\"address\": \"0000:4e:00.0\", \"group\": \"group2\"}\ndevice_spec \u003d {\"address\": \"0000:4f:00.0\", \"group\": \"group2\"}\n ...\nalias \u003d {\"name\": \"gpu-2x\", \"groups\": [\"group1\", \"group2\"]}\n```\nI imagine the reason not to do this is because it becomes more verbose or not flexible enough at some point of real-world complexity, but I don\u0027t immediately see it.\n\nAny of these would be easier to understand to me. Just some ideas. I think a lot of this stems from the fact that when I read this, \"group_name\" and \"group_type\" don\u0027t convey to me the differences between these two things in their name.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ef21e161_374342dd","line":108,"in_reply_to":"1d69293d_265731b0","updated":"2026-05-08 14:46:29.000000000","message":"Introduced group_spec with addresses, type, and key fields.\n\n---\n\n\u003e Also a weak argument I think. If the OTU flag is only on one of the two devices, but we track them in placement as a single provider, I don\u0027t think the agent will have any more information because one is tagged in the config as OTU when the other is not. It will still notice only a single reserved\u003d1 placement provider and will need to know what to do there. In fact, the one example of an agent requires the placement provider\u0027s name to have the PCI address encoded (IIRC) which means being in a group will already probably make the usual OTU workflow hard...right?\n\nI think cleanup agent can take the nova compute config and read out the device_spec and group_spec to be able to break down the group into individual devices.\n\n\n\u003e I understand. I feel like this whole approach is a bit of a \"design corner\" because we\u0027re building more complexity on a data structure that feels ill-suited even for the current amount of needed expressivity.\n\nAt the moment I don\u0027t see a better config modeling without re-doing the whole PCI configuration. And I really don\u0027t want to start blowing that up as part of this feature.\n\n\u003e  And, it seems unfortunate to only have the group for \u003e1 device groups. I\u0027d really rather make this group-native than group-adjacent. But, I should probably just squash that feeling.\n\nWe can allow groups with a single devices. But I guess that alone does not change much.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"16babbaec43509e62e3c5aa1ef32abace4c6c55f","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e061cb42_efa99ec9","line":108,"in_reply_to":"3d0f923b_ac2bc49c","updated":"2026-05-04 16:14:13.000000000","message":"@smooney@redhat.com\n\n\u003e you cannot use this today\n\u003e \"address\": \"0000:0[6-9]:\"\n\nYou are correct. I can reformulate the example with the same meaning but not relying on that syntax to:\n```\n[pci]\n# the 4 devices, 06-07 and 08-09 are two cross connected pairs. Each has the same config so we can glob them today\ndevice_spec \u003d {\"address\": {\"domain\":\"0000\", \"bus\": \"0[6-9]\", \"slot\":\"00\", \"function\": \"0\"}, \"managed\":\"false\", \"live_migratable\":\"true\"} \n\n# Now define groups by explicit address only. But keep the device_spec to define per device parameters.\ngroup_spec \u003d {\"name\": \"gpu-group1\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:06:00\", \"0000:07:00\"]}\ngroup_spec \u003d {\"name\": \"gpu-group2\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:08:00\", \"0000:09:00\"]}\nalias \u003d { \"name\": \"gpu-2x\", \"group_type\":\"gpu-2x\", \"live_migratable\":\"true\", \"numa_policy\":\"required\"}\n```\n\n---\n@dms@danplanet.com\n\nSo we discussed some of this with Dan over IRC on Thursday https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2026-04-30.log.html#openstack-nova.2026-04-30.log.html#t2026-04-30T15:47:18\n\nHere is a summary of the above with some further thoughts occurred to me since:\n\n\u003e My main concern is the \"group name\" and \"group type\" are not intuitively understandable to me.\n...\n\u003e I don\u0027t understand why groups need a name and a type. The type is important of course, but is the name purely just because we need a name for the resource provider? For someone not intimately familiar with the plumbing that will go behind this, it feels like just extra things that need to be typed (or in reality, generated in a stable way from ansible) that doesn\u0027t add any benefit.\n\nIn this `group_spec` config `name` is only needed due to ugly implementation reasons. The code needs to name the resource provider in placement with a stable name. This info is not use for anything else. I thought about generating the name in nova but I failed to find a stable naming function that I like.\nI tried:\n* use somehow the address of the devices in the group. It does not work as we agreed that a group content can be changed if it is not allocated. Such change will change the name of the group. This would create a need to delete an old RP and add a new RP to placement.\n\n* use a running index. I.e. the first group in our config gets the name group_type-\u003c0\u003e the second group_type-\u003c1\u003e etc. This would make our group_spec config order dependent.\n\n* generate a uuid. This would require us to persist that uuid in nova to be able to map a group from the config to the group in Placement. The PciDevice extra field is a json blob so we could put it there. So maybe this is the closest I could accept as a way forward. **How do you feel about it?**\n\nI\u0027m open to suggestion and Dan suggested to then at least rename this from `name` to `key` which I\u0027m OK to do.\n\n---\n\n\u003e I guess I also don\u0027t understand why we need device_spec to support matching but the group_spec to be explicit. Seems like for groups we could just be explicit always. I also don\u0027t really understand when/where we need device_spec to differ much between items in the group (except for managed).\n\nThe main reason to keep device_spec used even if we introduce group_spec to define a group is to allow defining per device tags even if the device is grouped. Examples:\n1. managed. That tag has no meaning on the group level and we can group diverse set of devices one need managed\u003dfalse the other might not.\n2. live_migratable. While the group could express that today it should not in my eyes as it is not a property of a group but a property of each device in the group. In theory in the future we can introduce live_migratable\u003dunplug to support stateless, flavor requested PCI devices during live migration. Then it is defiitely something we need to express pre device and not per group.\n3. one_time_use. In the real world this is also a parameter of a device even if nova can ignore that as it only need to reserve the whole group inventory in placement Only the external agent needs to figure out which device to run the cleanup on within that group.\n\n---\n\nObviously we can say we only support grouping of non-diverse set of devices and therefore `group_spec` can be the source of all device specific parameters as well (managed, live_migratable, one_time_use) and then device_spec can be ignored in grouping. But that makes the feature pretty limited and not future proof. I know we discussed cyborg eventually implementing grouping instead of nova, but for me that is not a reason to build a half useful feature now. I cannot point to cyborg as a replacement if somebody needs a diverse set of devices. Neither I see a timeline when it will happen. I have to assume that if we do any grouping in nova it will be always easier to add the next grouping related features to nova than to start from scratch in cyborg. So I rather not design ourselves into a corner if possible.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"de9db105_c09f5052","line":108,"in_reply_to":"41eb974b_c91d9e9a","updated":"2026-04-29 20:24:41.000000000","message":"you usage of group at lesat in the later exampel is combining group_type and group_name\n\nwhich to me is harder to reason about then the current proosal.\n\nthe device_spec is a json feld so we can use any valid json construct an array of adresses or a list of object are valid\n\nwe already supprot adrss beign a string with or without glob syntax or it can be a dictionary with regex supprot so we could add a list of adresses without conflciting im just not sure if that is requried but im not agsint it provide we supprot that array syntax for non groups as well\n\ni.e. as just another alternitive way to spciyfy mulple device that can be manged by nova.\n\ni woudl be -1 on any group speicifc usage of adresses","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"476fb50666ac853c4f242adca5bcf7d3178305c6","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"86491db0_29ff4dfc","line":108,"in_reply_to":"61cd3cea_3e627eff","updated":"2026-04-30 14:45:18.000000000","message":"Corrected example. The alias now refers to the group properly via the \"group_type\" field\n```\n[pci]\n# the 4 devices, 06-07 and 08-09 are two cross connected pairs. Each has the same config so we can glob them today\ndevice_spec \u003d {\"address\": \"0000:0[6-9]:\", \"managed\":\"false\", \"live_migratable\":\"true\"} \n\n# Now define groups by explicit address only. But keep the device_spec to define per device parameters.\ngroup_spec \u003d {\"name\": \"gpu-group1\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:06:00\", \"0000:07:00\"]}\ngroup_spec \u003d {\"name\": \"gpu-group2\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:08:00\", \"0000:09:00\"]}\nalias \u003d { \"name\": \"gpu-2x\", \"group_type\":\"gpu-2x\", \"live_migratable\":\"true\", \"numa_policy\":\"required\"}\n```","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0f59414d796aeb62b67080359657445e5145dcc1","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3d0f923b_ac2bc49c","line":108,"in_reply_to":"86491db0_29ff4dfc","updated":"2026-04-30 15:38:26.000000000","message":"My main concern is the \"group name\" and \"group type\" are not intuitively understandable to me when I just look at the example. I really hate to add another weird duplicated key (`group_spec`) to this already confusing section, but I agree it\u0027s better than trying to overload everything into `device_spec` as was originally proposed. I was trying to reduce the cognitive load of needing to mentally link `device_spec` items together.\n\nI don\u0027t understand why groups need a name and a type. The type is important of course, but is the name purely just because we need a name for the resource provider? For someone not intimately familiar with the plumbing that will go behind this, it feels like just extra things that need to be typed (or in reality, generated in a stable way from ansible) that doesn\u0027t add any benefit.\n\nI guess I also don\u0027t understand why we need `device_spec` to support matching but the `group_spec` to be explicit. Seems like for groups we could just be explicit always. I also don\u0027t really understand when/where we need `device_spec` to differ much between items in the group (except for `managed`).\n\nSo I dunno, it\u0027s just really feeling like a lot of (confusing) hoops to jump through. Having the explicit grouping is definitely better.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d14b97b5ca6112aeff40a07b8165e4bb00f92ebd","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d12004c6_9e4a3c53","line":108,"in_reply_to":"86491db0_29ff4dfc","updated":"2026-04-30 14:59:59.000000000","message":"you cannot use this today\n```\n\"address\": \"0000:0[6-9]:\"\n```\nyou can only use * \nit better to say we supprot wiled card then genic full bash globing\n\nthis is how we implemtn the glob supprot\n\nhttps://github.com/openstack/nova/blob/master/nova/pci/devspec.py#L125-L164\n\nand here is the regex form\n\nhttps://github.com/openstack/nova/blob/master/nova/pci/devspec.py#L167-L195\n\nthe match function for the glob type only accept *\n\nwe determin which on to use here\n\nhttps://github.com/openstack/nova/blob/master/nova/pci/devspec.py#L232-L243\n\nso it woudl be ease to add list to that if chain but\n\n`\"address\": \"0000:0[6-9]:\"`  will not work today","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9a7dc652f91956ba8a7907d6a74d293d252ca88a","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"61cd3cea_3e627eff","line":108,"in_reply_to":"de9db105_c09f5052","updated":"2026-04-30 14:41:52.000000000","message":"I\u0027m a bit afraid of further overloading the meaning of \"address\". As Sean said it can be:\n* a string: then it defined substring address match with glob support\n* a dict: then it supports named address fields (bus, function etc) with regex support\n* and now list: then it support listing exact addresses AND it switch the matched devices to form a group.\n\nBut the idea of making a group defined with explicit addresses appeals to me. (Honestly the current device_spec matching logic is just to much to grok) But also I think we need a way to add paramters like managed, live_migratable, one_time_use to individual devices even when they are grouped. \n\nSo what if:\n\n* we keep the device_spec as is today to define what devices are available for nova and enhance those devices with extra data like live_migratable.\n* add a new config option `group_spec` that defines a group by listing pci addresses fully and explicitly.\n* allow to name a group\n* defines the group type / resouce class / traits for the group\n* BUT can only list addresses that are also matching a device via device_spec. And nova will track that device as part of a group and not as individually consumable device.\n\nExample:\n```\n[pci]\n# the 4 devices, 06-07 and 08-09 are two cross connected pairs. Each has the same config so we can glob them today\ndevice_spec \u003d {\"address\": \"0000:0[6-9]:\", \"managed\":\"false\", \"live_migratable\":\"true\"} \n\n# Now define groups by explicit address only. But keep the device_spec to define per device parameters.\ngroup_spec \u003d {\"name\": \"gpu-group1\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:06:00\", \"0000:07:00\"]}\ngroup_spec \u003d {\"name\": \"gpu-group2\", \"type\": \"gpu-2x\", addresses\u003d[\"0000:08:00\", \"0000:09:00\"]}\nalias \u003d { \"name\": \"gpu-2x\", \"live_migratable\":\"true\", \"numa_policy\":\"required\"}\n```\n\nFurther examples are in https://etherpad.opendev.org/p/nova-pci-grouping\n\n---\n\n* This allows us to keep device_spec as is and not complicate it further with fields, tags, and meaning (ok a bit of new meaning needed).\n* This allows us to keep the group defined separately and very explcitly\n* We can define all the group level tags on the group_spec\n* We can keep defining per device tags in the device_spec like live_migratable or managed and inherit them to the group if we want to.\n* The only new meaning for the device_spec is that if an address matched by a device_spec and that address is also in a group_spec then and only then that device is tracked as part of a group and not as an individual device.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cd5052ac64ea46c63d254f7d610e482bfdcc2151","unresolved":true,"context_lines":[{"line_number":105,"context_line":"  in placement."},{"line_number":106,"context_line":"* The PCI stats and pools used for the PCI scheduling will be extended to"},{"line_number":107,"context_line":"  support grouping via a unique pool type that tracks each group as an"},{"line_number":108,"context_line":"  individual pool."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Here is a simple example defining a single group of two devices and the"},{"line_number":111,"context_line":"corresponding alias requesting such a group. Note that the value of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1d69293d_265731b0","line":108,"in_reply_to":"e061cb42_efa99ec9","updated":"2026-05-07 17:45:50.000000000","message":"\u003e * generate a uuid. This would require us to persist that uuid in nova to be able to map a group from the config to the group in Placement. The PciDevice extra field is a json blob so we could put it there. So maybe this is the closest I could accept as a way forward. **How do you feel about it?**\n\nI guess I\u0027m not sure how this would really work, if we generate a uuid and then the operator changes a group in the right way, I would think we could lose track of which group matches which uuid. I know that you shouldn\u0027t be able to change a group with allocations, but it could happen and if we corrupt all our data as a result that\u0027s going to be bad.\n\n\u003e I\u0027m open to suggestion and Dan suggested to then at least rename this from `name` to `key` which I\u0027m OK to do.\n\nYeah, I think that is probably the best we can do. I think this highlights why this \"should be simple, just group some devices\" approach is not nearly as simple or clean as it may seem. I worry about us taking an already-overloaded syntax here, adding a lot of potential complexity, and then trying to build the next thing (yes, there will be a next thing) on top of this house of cards.\n\n\u003e 1. managed. That tag has no meaning on the group level and we can group diverse set of devices one need managed\u003dfalse the other might not.\n\nYes, this is the strongest reason I think.\n\n\u003e 2. live_migratable. While the group could express that today it should not in my eyes as it is not a property of a group but a property of each device in the group. In theory in the future we can introduce live_migratable\u003dunplug to support stateless, flavor requested PCI devices during live migration. Then it is defiitely something we need to express pre device and not per group.\n\nThis holds less weight with me, I guess because it seems like the justification relies on something that doesn\u0027t exist, and I also just wonder about the \"track two devices as one, but only migrate state for one of those things\" use-case.\n\n\u003e 3. one_time_use. In the real world this is also a parameter of a device even if nova can ignore that as it only need to reserve the whole group inventory in placement Only the external agent needs to figure out which device to run the cleanup on within that group.\n\nAlso a weak argument I think. If the OTU flag is only on one of the two devices, but we track them in placement as a single provider, I don\u0027t think the agent will have any more information because one is tagged _in the config_ as OTU when the other is not. It will still notice only a single reserved\u003d1 placement provider and will need to know what to do there. In fact, the one example of an agent requires the placement provider\u0027s name to have the PCI address encoded (IIRC) which means being in a group will already probably make the usual OTU workflow hard...right?\n\n\u003e Obviously we can say we only support grouping of non-diverse set of devices and therefore `group_spec` can be the source of all device specific parameters as well (managed, live_migratable, one_time_use) and then device_spec can be ignored in grouping. But that makes the feature pretty limited and not future proof. I know we discussed cyborg eventually implementing grouping instead of nova, but for me that is not a reason to build a half useful feature now. I cannot point to cyborg as a replacement if somebody needs a diverse set of devices. Neither I see a timeline when it will happen. I have to assume that if we do any grouping in nova it will be always easier to add the next grouping related features to nova than to start from scratch in cyborg. So I rather not design ourselves into a corner if possible.\n\nI understand. I feel like this whole approach is a bit of a \"design corner\" because we\u0027re building more complexity on a data structure that feels ill-suited even for the current amount of needed expressivity.\n\nAnyway, we\u0027re kinda stuck here I guess. Adding an intermediate `group_spec` is probably the best option. I like it in that it makes it a lot less confusing I think (assuming we can go with name/key) but it does increase the labor required to do all this. And, it seems unfortunate to only have the group for \u003e1 device groups. I\u0027d really rather make this group-native than group-adjacent. But, I should probably just squash that feeling.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":116,"context_line":"  device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":117,"context_line":"  device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"Note that this PCI grouping feature is building on top of the pre-existing"},{"line_number":122,"context_line":"PCI in Placement feature and inherits all the limitations of it. See"}],"source_content_type":"text/x-rst","patch_set":3,"id":"664b6007_f40cebcc","line":119,"updated":"2026-04-28 15:49:11.000000000","message":"I think it might be good to have this example be a little more representative of a real-world scenario (i.e. more than just a single group, as my examples above). It will get pretty long if you have eight cards of two subdevices each.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":116,"context_line":"  device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":117,"context_line":"  device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"Note that this PCI grouping feature is building on top of the pre-existing"},{"line_number":122,"context_line":"PCI in Placement feature and inherits all the limitations of it. See"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8438be47_f9f04be6","line":119,"in_reply_to":"664b6007_f40cebcc","updated":"2026-04-29 20:24:41.000000000","message":"i provided actual examples in a comment in a previous version\n\n```\n[pci]\nreport_in_placement \u003d True\n\n# Group 1: 3b:02.0 - 3b:02.7\ndevice_spec \u003d {\"address\": \"0000:3b:02.0\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.1\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.2\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.3\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.4\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.5\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.6\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\ndevice_spec \u003d {\"address\": \"0000:3b:02.7\", \"group_name\": \"nic_group_1\", \"group_type\": \"NICx8\"}\n\n# Group 2: 3b:03.0 - 3b:03.7\n#device_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\n\n# Group 3: 3b:04.0 - 3b:04.7\n#device_spec \u003d {\"address\": \"0000:3b:04.*\", \"group_name\": \"nic_group_3\", \"group_type\": \"NICx8\"}\n\n# Group 4: 3b:05.0 - 3b:05.7\n#device_spec \u003d {\"address\": \"0000:3b:05.*\", \"group_name\": \"nic_group_4\", \"group_type\": \"NICx8\"}\n\n# Group 5: 3b:06.0 - 3b:06.7\n#device_spec \u003d {\"address\": \"0000:3b:06.*\", \"group_name\": \"nic_group_5\", \"group_type\": \"NICx8\"}\n\n# Group 6: 3b:07.0 - 3b:07.7\n#device_spec \u003d {\"address\": \"0000:3b:07.*\", \"group_name\": \"nic_group_6\", \"group_type\": \"NICx8\"}\n\n# Group 7: 3b:08.0 - 3b:08.7\n#device_spec \u003d {\"address\": \"0000:3b:08.*\", \"group_name\": \"nic_group_7\", \"group_type\": \"NICx8\"}\n\n# Group 8: 3b:09.0 - 3b:09.7\n#device_spec \u003d {\"address\": {\"domain\": \"0000\", \"bus\": \"3b\", \"slot\": \"09\", \"function\": \".*\"}, \"group_name\": \"nic_group_8\", \"group_type\": \"NICx8\"}\n\n# Alias for requesting NICx8 groups via flavor\nalias \u003d {\"name\": \"NICx8\", \"group_type\": \"NICx8\"}\n```\n\nthat show most of the ways you can express a group in the current poc\n\nwhat i didnt show is \n```\n# Group 6: 3b:07.0 - 3b:07.7\n#device_spec \u003d {\"address\": \"0000:3b:07.*\", \"group_name\": \"nic_group_6\", \"group_type\": \"NICx8\"}\n\n# Group 7: 3b:08.0 - 3b:08.7\n#device_spec \u003d {\"address\": \"0000:3b:08.*\", \"group_name\": \"nic_group_7\", \"group_type\": \"NICx8\"}\n```\n\ncan also be \n```\n# Group 6: 3b:07.0 - 3b:07.7 and Group 7: 3b:08.0 - 3b:08.7\ndevice_spec \u003d [{\"address\": \"0000:3b:07.*\", \"group_name\": \"nic_group_6\", \"group_type\": \"NICx8\"}, {\"address\": \"0000:3b:08.*\", \"group_name\": \"nic_group_7\", \"group_type\": \"NICx8\"}]\n```\n\ndevice_spec is defiend as both a multiOPT so you can repeated it and it will be merged and as i said above the value of it is also json\n\nso you can have a singel entry that contianes a list of devics.\n\ni woudl suggest adnign a singel exampel of each approch here?\n\nperhaps we coudl also show diffent group type sso this is me deviign up 64vf into 8 groups of 8 but we coudl show some groups or 2 and 4","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":116,"context_line":"  device_spec \u003d {\"address\": \"0000:4e:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":117,"context_line":"  device_spec \u003d {\"address\": \"0000:4f:00.0\", \"group_name\": \"group1\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\"}"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"Note that this PCI grouping feature is building on top of the pre-existing"},{"line_number":122,"context_line":"PCI in Placement feature and inherits all the limitations of it. See"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0b3d6d81_f53ecd7a","line":119,"in_reply_to":"8438be47_f9f04be6","updated":"2026-05-08 14:46:29.000000000","message":"Extended the example","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":132,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":133,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":134,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":135,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ae3e4c1b_cbe62952","line":135,"updated":"2026-04-28 15:49:11.000000000","message":"This `group_type` description misses the most important characteristic for understanding what this does (IMHO) which is that it sort of creates a virtual device from multiple physical ones that can be referenced from a single alias. The fact that it informs the resource class is sort of the very implementation-specific detail about how/why but I don\u0027t think it\u0027s very straightforward for understanding.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":132,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":133,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":134,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":135,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"}],"source_content_type":"text/x-rst","patch_set":3,"id":"db3bcf0e_f4319dbb","line":135,"in_reply_to":"ae3e4c1b_cbe62952","updated":"2026-04-29 20:24:41.000000000","message":"yes group_type is the logacal handel to a template for what group to select\n\nits kind of the diffent beween a CRD (group type) and a CR (actual pci group on a given host) if we were to borrow/abuse a k8s concept.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":132,"context_line":"  (e.g., \"graphcore_1\"). This identifies which devices belong together."},{"line_number":133,"context_line":"* ``group_type``: A category name used to generate the resource class"},{"line_number":134,"context_line":"  (e.g., \"c200_x1\" generates ``CUSTOM_PCI_GROUP_C200_X1``). All groups"},{"line_number":135,"context_line":"  of the same type are interchangeable from a scheduling perspective."},{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"}],"source_content_type":"text/x-rst","patch_set":3,"id":"77c4284e_b021d7fb","line":135,"in_reply_to":"db3bcf0e_f4319dbb","updated":"2026-05-08 14:46:29.000000000","message":"I impoved the wording.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"},{"line_number":139,"context_line":"  for ``device_spec`` lines defining a group."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Both ``group_name`` and ``group_type`` tags must be specified together -"},{"line_number":142,"context_line":"specifying only one results in a configuration error."}],"source_content_type":"text/x-rst","patch_set":3,"id":"f67ba270_e43e7c30","line":139,"updated":"2026-04-29 20:24:41.000000000","message":"so my concern with this is that group_traits need to be use to defien the traits for a given group_type\n\ni woudl prefer if instead of this we intoduced \n\ngroup_traits as a top level key in the pci section and made it a map/json streing\n\nwhere the key is the group_type and the value is the lsit of triats\n```\n[pci]\n...\ndevice_spec \u003d {\"address\": \"0000:3b:03.*\", \"group_name\": \"nic_group_2\", \"group_type\": \"NICx8\"}\n...\ngroup_traits \u003d {\"NICx8\":[\u0027CUSTOM_VLAN_TRANSPARENT\u0027], \"ENODEB\":\"CUSTOM_EDGE\"}\n\n```\n\nthis way you only defien the traits for a group once in teh config so they can never be out of sync.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"},{"line_number":139,"context_line":"  for ``device_spec`` lines defining a group."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Both ``group_name`` and ``group_type`` tags must be specified together -"},{"line_number":142,"context_line":"specifying only one results in a configuration error."}],"source_content_type":"text/x-rst","patch_set":3,"id":"0f1535b7_02cad988","line":139,"in_reply_to":"6aa9bfa9_fdc17bd1","updated":"2026-05-08 16:47:58.000000000","message":"im ok ot resolve this base don the v4 spec defintion\n\nif needed we can alwsy supprot it also on the device_spec in an apend only model in the future so we are not locked into this if we need to evolve it for some reason but i think just havign it in the group_spec is fine and it elimiate any quesion of do the traits apply to a specific device or to the group ectra.\n\nwe should just make sure tha tyou can do\n\ndevice_spec \u003d {\"vendor_id\": \"10de\", \"product_id\": \"233b\", \"managed\": \"false\", \"triats\": \"foo\"}\n\nand when have a device that is in a group form that just without the foo trait reported for the gorup.\n\nbasicly we woudl clear/overiead the traits defintion form the device spec as part of making that device a member of a groups\n\nill resolve this for now since i belive this aligns to how v4 is propsoed to wrok","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":true,"context_lines":[{"line_number":136,"context_line":"* ``group_traits``: A list of placement trait names similar to the existing"},{"line_number":137,"context_line":"  ``traits`` tag. It can only be defined in one of the ``device_spec`` lines"},{"line_number":138,"context_line":"  contributing devices to a group. The existing ``traits`` tag cannot be used"},{"line_number":139,"context_line":"  for ``device_spec`` lines defining a group."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"Both ``group_name`` and ``group_type`` tags must be specified together -"},{"line_number":142,"context_line":"specifying only one results in a configuration error."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6aa9bfa9_fdc17bd1","line":139,"in_reply_to":"f67ba270_e43e7c30","updated":"2026-05-08 14:46:29.000000000","message":"I\u0027m hesitant attaching trait to the group_type instead of attaching it just to the group. I think both has meaning. An alias today allows asking for the same RC but different traits, the same way an alias tomorrow could ask for the same group_type but different traits.\n\nThe current version of the spec connects the trait to the group def, so it allows two groups with the same group_type to have different traits. But we can be more restrictive by going to your direction.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* ``live_migratable``: Only if every device in a group has the tag"},{"line_number":148,"context_line":"  ``live_migratable`` set to ``true`` then the group is considered live"},{"line_number":149,"context_line":"  migratable."},{"line_number":150,"context_line":"* ``physical_network``: Is not applicable for devices added to a group. This is"},{"line_number":151,"context_line":"  due to the limitation that PCI in Placement feature does not support"},{"line_number":152,"context_line":"  devices having ``physical_network`` tag today."}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf5cc346_e53a6333","line":149,"updated":"2026-04-28 15:49:11.000000000","message":"Making groups a single `device_spec` that takes a list of addresses (suggestion 1 above) would eliminate the need to make this clarification, which is a sign to me that it\u0027s simpler.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* ``live_migratable``: Only if every device in a group has the tag"},{"line_number":148,"context_line":"  ``live_migratable`` set to ``true`` then the group is considered live"},{"line_number":149,"context_line":"  migratable."},{"line_number":150,"context_line":"* ``physical_network``: Is not applicable for devices added to a group. This is"},{"line_number":151,"context_line":"  due to the limitation that PCI in Placement feature does not support"},{"line_number":152,"context_line":"  devices having ``physical_network`` tag today."}],"source_content_type":"text/x-rst","patch_set":3,"id":"c653758a_1fa0ac19","line":149,"in_reply_to":"bf5cc346_e53a6333","updated":"2026-04-29 20:24:41.000000000","message":"we dont need to change teh adress to do that as i noted int a previosu version\n\nwe can do that fi that is the prefenc ebut we shoudl also supprto the regex and glob state.\n\nhonestly it really does nto simpfy thing much to force the singel line constraits\nand it makes it harder in some respeocts but im open to that chagne if we think it will elimante foot guns.\n\ni dotn think it will but we could go either way and still ahve someting logiclly consitent.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* ``live_migratable``: Only if every device in a group has the tag"},{"line_number":148,"context_line":"  ``live_migratable`` set to ``true`` then the group is considered live"},{"line_number":149,"context_line":"  migratable."},{"line_number":150,"context_line":"* ``physical_network``: Is not applicable for devices added to a group. This is"},{"line_number":151,"context_line":"  due to the limitation that PCI in Placement feature does not support"},{"line_number":152,"context_line":"  devices having ``physical_network`` tag today."}],"source_content_type":"text/x-rst","patch_set":3,"id":"913e1963_454236b0","line":149,"in_reply_to":"c653758a_1fa0ac19","updated":"2026-05-11 15:11:41.000000000","message":"Acknowledged","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":155,"context_line":"* ``resource_class``: Supported to override the automatically generated"},{"line_number":156,"context_line":"  resource_class for the group, but different groups of the same type and"},{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5c08bb0d_7e7bfb7a","line":158,"updated":"2026-04-28 15:49:11.000000000","message":"This is a runtime check we need to do, correct? To make sure that `two device_spec` things that belong to the same `group_type` (is that the right one?) don\u0027t specify divergent classes? I guess option 1 above doesn\u0027t make this less important, but it does halve the number of places that you could make that mistake I think.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":155,"context_line":"* ``resource_class``: Supported to override the automatically generated"},{"line_number":156,"context_line":"  resource_class for the group, but different groups of the same type and"},{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d8f59a86_313bf2d6","line":158,"in_reply_to":"5c08bb0d_7e7bfb7a","updated":"2026-04-29 20:24:41.000000000","message":"it would be a startup check when we validat the config option yes.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":155,"context_line":"* ``resource_class``: Supported to override the automatically generated"},{"line_number":156,"context_line":"  resource_class for the group, but different groups of the same type and"},{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"}],"source_content_type":"text/x-rst","patch_set":3,"id":"581daf62_09cb922f","line":158,"in_reply_to":"d8f59a86_313bf2d6","updated":"2026-05-08 14:46:29.000000000","message":"this is at least partially eliminated with group_spec","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f2aeab98_974d2fd1","line":160,"updated":"2026-04-28 15:49:11.000000000","message":"I think option 1 above eliminates the need to have this group_ specific alternative right?","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9bdf645f_b17c8104","line":160,"in_reply_to":"b9fd1b25_f54e8d32","updated":"2026-05-08 14:46:29.000000000","message":"the trait divergence is eliminated (at least partially) with the group_spec config.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":157,"context_line":"  different spec lines contributing to the same ``group_type`` cannot define"},{"line_number":158,"context_line":"  divergent resource class names for the ``group_type``."},{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b9fd1b25_f54e8d32","line":160,"in_reply_to":"f2aeab98_974d2fd1","updated":"2026-04-29 20:24:41.000000000","message":"yes but i think you missed that option one is already psosibe today  to some extend usign the glob and regex form\n\ni.e. the ablity to refence many devices in a singel line\n\nto me adding the arry syntax for adress it actully a seprete feature unrelated to grouping that may be nice to do anyway\n\nso we can do that regardless fo groupign but if we do it should also work for normal device specs without the use fo the group tags.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"},{"line_number":164,"context_line":"  ``one_time_use\u003dtrue`` then the whole group is considered as one time use"},{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"}],"source_content_type":"text/x-rst","patch_set":3,"id":"76d36100_3892429c","line":162,"updated":"2026-04-28 15:49:11.000000000","message":"Maybe this is the thing that makes option 1 above not viable? I\u0027m not sure if it\u0027s important to mark one thing as managed and not the other, but perhaps?","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"},{"line_number":164,"context_line":"  ``one_time_use\u003dtrue`` then the whole group is considered as one time use"},{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e0a98290_b1e02ba5","line":162,"in_reply_to":"76d36100_3892429c","updated":"2026-04-29 20:24:41.000000000","message":"if you need any of the flags to be divergent they yes you need to have more then 1 line\n\ni dont see your option 1 and this propasl as comepteing they are complementry.\n\nwe shoudl be ablt to set this diffently on each device in a group.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* ``traits``: Not supported for group definitions. Use the ``group_traits``"},{"line_number":160,"context_line":"  instead."},{"line_number":161,"context_line":"* ``managed``: Supported. This information is only used to decide how to handle"},{"line_number":162,"context_line":"  the device toward the hypervisor; it has no effect on group handling at all."},{"line_number":163,"context_line":"* ``one_time_use``: Supported. If any of the devices in a group is marked as"},{"line_number":164,"context_line":"  ``one_time_use\u003dtrue`` then the whole group is considered as one time use"},{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ee044f6_1451df8c","line":162,"in_reply_to":"e0a98290_b1e02ba5","updated":"2026-05-08 14:46:29.000000000","message":"Acknowledged","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"},{"line_number":166,"context_line":"  will be reserved at allocation time. The external system that handles the"},{"line_number":167,"context_line":"  cleanup of such devices needs to unreserve this group inventory in placement"},{"line_number":168,"context_line":"  when every device in this group is cleaned."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Note that ``vendor_id``, ``product_id`` and ``address`` can be used the same"},{"line_number":171,"context_line":"way to match devices as in case of non-grouped devices. Also note that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2773d9fa_1b6de42a","line":168,"updated":"2026-04-28 15:49:11.000000000","message":"Same as earlier - a clarification not needed in option 1 above.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"},{"line_number":166,"context_line":"  will be reserved at allocation time. The external system that handles the"},{"line_number":167,"context_line":"  cleanup of such devices needs to unreserve this group inventory in placement"},{"line_number":168,"context_line":"  when every device in this group is cleaned."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Note that ``vendor_id``, ``product_id`` and ``address`` can be used the same"},{"line_number":171,"context_line":"way to match devices as in case of non-grouped devices. Also note that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e9354b83_57aed6cf","line":168,"in_reply_to":"2773d9fa_1b6de42a","updated":"2026-04-29 20:24:41.000000000","message":"one time use is interesting becuase even if only 1 device require that we would have to implemnt it for the entire group.\n\nbut i think that is ok it does mena the system or person that is resettign the reserved value in placement need to be group aware in this case.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":165,"context_line":"  only and therefore the placement resource inventory representing the group"},{"line_number":166,"context_line":"  will be reserved at allocation time. The external system that handles the"},{"line_number":167,"context_line":"  cleanup of such devices needs to unreserve this group inventory in placement"},{"line_number":168,"context_line":"  when every device in this group is cleaned."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Note that ``vendor_id``, ``product_id`` and ``address`` can be used the same"},{"line_number":171,"context_line":"way to match devices as in case of non-grouped devices. Also note that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"371acfb8_d95e0913","line":168,"in_reply_to":"e9354b83_57aed6cf","updated":"2026-05-08 14:46:29.000000000","message":"answered above, but the complication to the cleanup agent is real","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":191,"context_line":"  for groups."},{"line_number":192,"context_line":"* ``resource_class``: Supported as an override for the default resource class"},{"line_number":193,"context_line":"  generated from the ``group_type``."},{"line_number":194,"context_line":"* ``traits``: Supported. It is matched with the traits provided by the"},{"line_number":195,"context_line":"  group via the ``group_traits`` tag."},{"line_number":196,"context_line":"* ``live_migratable``: Supported to request a live_migratable group."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"299f5d4b_87005d56","line":194,"updated":"2026-04-28 15:49:11.000000000","message":"What does \"matched\" mean here? I assume we union any `group_traits` with `traits` here?","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  for groups."},{"line_number":192,"context_line":"* ``resource_class``: Supported as an override for the default resource class"},{"line_number":193,"context_line":"  generated from the ``group_type``."},{"line_number":194,"context_line":"* ``traits``: Supported. It is matched with the traits provided by the"},{"line_number":195,"context_line":"  group via the ``group_traits`` tag."},{"line_number":196,"context_line":"* ``live_migratable``: Supported to request a live_migratable group."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"53a26ac5_92ac1dc3","line":194,"in_reply_to":"299f5d4b_87005d56","updated":"2026-05-08 14:46:29.000000000","message":"The group need to provide all the traits the alias requests. Clarified the text","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":202,"context_line":"``[pci]device_spec``:"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"}],"source_content_type":"text/x-rst","patch_set":3,"id":"52f36656_9c4cebac","line":205,"updated":"2026-04-28 15:49:11.000000000","message":"Why? In my suggestions above I was thinking \"maybe we could simplify this by just making every single device a group of one\". I didn\u0027t make that suggestion because it might involve some syntax migration or whatever. But, why would we want to eliminate the possibility fundamentally?","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":202,"context_line":"``[pci]device_spec``:"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c7d45999_ab90b0f3","line":205,"in_reply_to":"52f36656_9c4cebac","updated":"2026-04-29 20:24:41.000000000","message":"for what its wortin i aslo didnt enfoce this in my poc\n\nwe could but its not requried for ti to be logiclly correct","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":true,"context_lines":[{"line_number":202,"context_line":"``[pci]device_spec``:"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1d2ae632_d5f19e58","line":205,"in_reply_to":"c7d45999_ab90b0f3","updated":"2026-05-08 14:46:29.000000000","message":"We can allow group definition with size one, but I feel you want more than that here. Something more automatic.","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"67de49e704d137c102b0813d6e9263306dd31bf5","unresolved":true,"context_lines":[{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"},{"line_number":209,"context_line":"* ``resource_class`` override should be consistent for the whole"},{"line_number":210,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"aa36225d_6e4a6823","line":207,"updated":"2026-04-28 15:49:11.000000000","message":"Another thing that would be structurally obvious with option 1 above :)","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"95c595c59632445fc6af09993617db3aa10df548","unresolved":false,"context_lines":[{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"},{"line_number":209,"context_line":"* ``resource_class`` override should be consistent for the whole"},{"line_number":210,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e46e0cb9_da4af5e7","line":207,"in_reply_to":"00f7365b_effcfe93","updated":"2026-05-08 14:46:29.000000000","message":"eliminated by group_spec","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"959bbf4222c06061dff80b29fb8d4b344a1c8bfc","unresolved":true,"context_lines":[{"line_number":204,"context_line":"* PCI groups are only supported when ``[pci]report_in_placement \u003d True``"},{"line_number":205,"context_line":"* All device groups must have two or more PCI devices"},{"line_number":206,"context_line":"* Each physical PCI device can only be in one group"},{"line_number":207,"context_line":"* All devices in a group must have the same ``group_type`` value"},{"line_number":208,"context_line":"* No duplicate device addresses across groups"},{"line_number":209,"context_line":"* ``resource_class`` override should be consistent for the whole"},{"line_number":210,"context_line":"  ``group_type``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"00f7365b_effcfe93","line":207,"in_reply_to":"aa36225d_6e4a6823","updated":"2026-04-29 20:24:41.000000000","message":"or by \n`device_spec \u003d {\"address\": {\"domain\": \"0000\", \"bus\": \"3b\", \"slot\": \"09\", \"function\": \".*\"}, \"group_name\": \"nic_group_8\", \"group_type\": \"NICx8\"}`\nand\n`device_spec \u003d {\"address\": \"0000:3b:08.*\", \"group_name\": \"nic_group_7\", \"group_type\": \"NICx8\"}`\n\nwhich i gave as examples prevosly\n\nbut yes agian your option 1 of haveing adress be a list is just another way to express that whic we can do but its not an either or propastion.\n\ni have some concrete exampel fo this in my unit tests\n\nhttps://review.opendev.org/c/openstack/nova/+/973604/3/nova/tests/unit/pci/test_whitelist.py\n\nand functionla tests\n\nhttps://review.opendev.org/c/openstack/nova/+/973604/3/nova/tests/functional/libvirt/test_pci_in_placement.py\n\ni am not asserting i covered all the edege cases form the orginl propal but i covered quite a few in my poc","commit_id":"9012288d3b9c82e299b1f053b232fa1e40f94243"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":65,"context_line":"In addition, some compute nodes can be statically configured to partition"},{"line_number":66,"context_line":"either two devices, four devices or eight devices as a single group."},{"line_number":67,"context_line":"These can all be statically configured using PCI group to ensure"},{"line_number":68,"context_line":"we always allocate them as a single indivisible unit regardless of their"},{"line_number":69,"context_line":"connectivity."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Other than Graphcore C200 devices, both major GPU vendors support connecting"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d045e9db_d5d9aef7","line":68,"updated":"2026-05-08 15:18:45.000000000","message":"I still don\u0027t think this makes sense to me. Isn\u0027t this just describing a preference? Like \"Operators may want to take the eight GPUs a compute node has and pair them up as consumable units of two cards each\"?\n\nI know you\u0027re trying to salvage the words that were here initially, but it reads like there\u0027s some hardware support we\u0027re trying to account for here, but that\u0027s not really it, right? Or is it? Or is it really just a verbose lead-in to the next paragraph about linked GPUs?","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":65,"context_line":"In addition, some compute nodes can be statically configured to partition"},{"line_number":66,"context_line":"either two devices, four devices or eight devices as a single group."},{"line_number":67,"context_line":"These can all be statically configured using PCI group to ensure"},{"line_number":68,"context_line":"we always allocate them as a single indivisible unit regardless of their"},{"line_number":69,"context_line":"connectivity."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Other than Graphcore C200 devices, both major GPU vendors support connecting"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b5ab5c38_6d2b5bba","line":68,"in_reply_to":"d045e9db_d5d9aef7","updated":"2026-05-11 15:11:41.000000000","message":"you are right. As far as I understand this is just preference not actual HW feature. So I will drop this and probably mention bigger than 2 devices per group in the GPU case where it is a HW feature.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":77,"context_line":""},{"line_number":78,"context_line":"There are situations, for example in the telco space, where PCI devices"},{"line_number":79,"context_line":"are logically grouped by function, connectivity, or location and expressing"},{"line_number":80,"context_line":"that grouping in Nova allows reducing operational complexity of the deployment."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9487497d_d38de926","line":80,"updated":"2026-05-08 16:47:58.000000000","message":"+1 for distiling this form the enode-b comment\n\nthe exact details of that limiation are less imporant then the fact that this pain point and usecase exist and is impoved by this proposal.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":87,"context_line":"------------------"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* We add a new multi value config option ``[pci]group_spec``. Each value of"},{"line_number":90,"context_line":"  this config defines a single PCI group by listing the PCI address of the"},{"line_number":91,"context_line":"  devices belonging to the group."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Each group in the ``[pci]group_spec`` is defined by 3 mandatory parameters:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"c2a54859_f912469a","line":90,"range":{"start_line":90,"start_character":60,"end_line":90,"end_character":67},"updated":"2026-05-08 15:18:45.000000000","message":"\"addresses\" .. non-pluralized it sounds like there\u0027s an address of a group.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":87,"context_line":"------------------"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* We add a new multi value config option ``[pci]group_spec``. Each value of"},{"line_number":90,"context_line":"  this config defines a single PCI group by listing the PCI address of the"},{"line_number":91,"context_line":"  devices belonging to the group."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Each group in the ``[pci]group_spec`` is defined by 3 mandatory parameters:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"33f33238_ceb62ca4","line":90,"range":{"start_line":90,"start_character":60,"end_line":90,"end_character":67},"in_reply_to":"c2a54859_f912469a","updated":"2026-05-11 15:11:41.000000000","message":"Done","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* We add a new multi value config option ``[pci]group_spec``. Each value of"},{"line_number":90,"context_line":"  this config defines a single PCI group by listing the PCI address of the"},{"line_number":91,"context_line":"  devices belonging to the group."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Each group in the ``[pci]group_spec`` is defined by 3 mandatory parameters:"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"2586d7dc_659e47c1","line":91,"updated":"2026-05-08 16:47:58.000000000","message":"one thing\n\nhttps://docs.openstack.org/nova/latest/configuration/config.html#pci.device_spec\n\nthe devspec is a multi-valued stropt of json vlaues\n\nbut it also supprot json list syntax\n\nso instead of repeating device_spec over and over again and then composting all of the value into a list internally\n\nyou can just do \n\n```\ndevice_spec \u003d [{\"product_id\":\"0001\", \"vendor_id\":\"8086\"},\n               {\"product_id\":\"0002\", \"vendor_id\":\"8086\"}]\n```\n\nwhich is muich eaiser to generate in installers becase\n\nthe idea of multi valued config option that are meted is part of the oslo.cofnig formatnat that is not part of ini.\n\nsince most automation tools use ini tools to generate config or validate them\nthe list verison is more protabl then the repoated config option as most of the tools wiil either that the first or last defiention and ignore the rest.\n\nso can we also supprot\n```\ngroup_spec \u003d [{...},\n              {...}]\n\n```\nits alwasy been a pain point that when we added that for devsepc we didnt add it for the alias\n\nhttps://docs.openstack.org/nova/latest/configuration/config.html#pci.alias\n\nso it could be nice to do that there but im not going to block on this one way or another\n\n\ni just think it woudl be nice to normalise the behvior between these 3 config option so you can either repoet them \nor use lists or both","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* We add a new multi value config option ``[pci]group_spec``. Each value of"},{"line_number":90,"context_line":"  this config defines a single PCI group by listing the PCI address of the"},{"line_number":91,"context_line":"  devices belonging to the group."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Each group in the ``[pci]group_spec`` is defined by 3 mandatory parameters:"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"cfc8d603_edf34280","line":91,"in_reply_to":"2586d7dc_659e47c1","updated":"2026-05-11 15:11:41.000000000","message":"I\u0027m fine adding the list syntax. We need to make sure to document it properly as this is not super obvious today in the device_spec config description as the two bullet points are too far from each other and therefore the list syntax is visible just like the last config example instead of a totally different config syntax possibility.\n\nI added a specific example for this syntax in the Configuration Examples section.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Each group in the ``[pci]group_spec`` is defined by 3 mandatory parameters:"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  * ``addresses`` is a list of strings of PCI addresses. No wildcarding is"},{"line_number":96,"context_line":"    supported. Each address listed should also be made available to nova by"},{"line_number":97,"context_line":"    configuring a matching ``[pci]device_spec`` value."},{"line_number":98,"context_line":"  * ``key`` is the ID of the group. It needs to be unique within a compute"},{"line_number":99,"context_line":"    node. It is only used to name the Resource Provider in Placement"},{"line_number":100,"context_line":"    that represents the group."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ebc19b2c_906d3877","line":97,"range":{"start_line":95,"start_character":0,"end_line":97,"end_character":54},"updated":"2026-05-08 16:47:58.000000000","message":"this is kind of unfortunetate that we have to do this in two places.\n\ni personally fint that harder to reason about then the original proposal but guess i can live with that compromise.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":96,"context_line":"    supported. Each address listed should also be made available to nova by"},{"line_number":97,"context_line":"    configuring a matching ``[pci]device_spec`` value."},{"line_number":98,"context_line":"  * ``key`` is the ID of the group. It needs to be unique within a compute"},{"line_number":99,"context_line":"    node. It is only used to name the Resource Provider in Placement"},{"line_number":100,"context_line":"    that represents the group."},{"line_number":101,"context_line":"  * ``type`` is the type of the group. It is a free form string that then"},{"line_number":102,"context_line":"    can be used to request a group via the ``[pci]alias``. Multiple groups of"}],"source_content_type":"text/x-rst","patch_set":4,"id":"717f18af_07b958d1","line":99,"updated":"2026-05-08 15:18:45.000000000","message":"I think `key` is massively better than `name` so that\u0027s great. However, you immediately have to explain that \"key is the ID\" so I wonder if `id` would actually be a better thing? I thought there was some reason I didn\u0027t suggest `id` in the previous round, because of confusion with something else but I don\u0027t know why now.\n\nEither way, `key` or `id` make it much easier to grok, IMHO so I\u0027m happy with either.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":96,"context_line":"    supported. Each address listed should also be made available to nova by"},{"line_number":97,"context_line":"    configuring a matching ``[pci]device_spec`` value."},{"line_number":98,"context_line":"  * ``key`` is the ID of the group. It needs to be unique within a compute"},{"line_number":99,"context_line":"    node. It is only used to name the Resource Provider in Placement"},{"line_number":100,"context_line":"    that represents the group."},{"line_number":101,"context_line":"  * ``type`` is the type of the group. It is a free form string that then"},{"line_number":102,"context_line":"    can be used to request a group via the ``[pci]alias``. Multiple groups of"}],"source_content_type":"text/x-rst","patch_set":4,"id":"21dcd11a_7b144a2f","line":99,"in_reply_to":"717f18af_07b958d1","updated":"2026-05-11 15:11:41.000000000","message":"I keep the key.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":102,"context_line":"    can be used to request a group via the ``[pci]alias``. Multiple groups of"},{"line_number":103,"context_line":"    the same type can be defined within the deployment and within a compute"},{"line_number":104,"context_line":"    node as well. However a group type should mean the same logical thing"},{"line_number":105,"context_line":"    across the whole deployment, e.g. two interconnected GPUs of a given type."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"* Each group in the ``[pci]group_spec`` can have optional parameters:"},{"line_number":108,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"63dbe982_923e92d6","line":105,"updated":"2026-05-08 15:18:45.000000000","message":"This still seems like it might be hard to understand to me without the context loaded. If I had to define this, it would probably be something like this:\n\n\u003e ``type`` identifies the resulting configuration of devices in a group. It should be the same for any exact arrangement of identical devices that can be passed to a guest. In effect, it is a \"virtual device type\" that is formed by the combination of multiple devices that can be assigned as a single unit to an instance. A given ``type`` should be assigned to any group (across all compute nodes in a deployment) that is composed of the same number and type of devices, with the same characteristics (traits, flags, etc).\n\nFeel free to use some or all of that if you think it\u0027s better, and none of it if you think it\u0027s not.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":true,"context_lines":[{"line_number":102,"context_line":"    can be used to request a group via the ``[pci]alias``. Multiple groups of"},{"line_number":103,"context_line":"    the same type can be defined within the deployment and within a compute"},{"line_number":104,"context_line":"    node as well. However a group type should mean the same logical thing"},{"line_number":105,"context_line":"    across the whole deployment, e.g. two interconnected GPUs of a given type."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"* Each group in the ``[pci]group_spec`` can have optional parameters:"},{"line_number":108,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"65167c16_7df6e4cd","line":105,"in_reply_to":"63dbe982_923e92d6","updated":"2026-05-11 15:11:41.000000000","message":"I built on your \"virtual device\" idea. But I think \"logical device\" is clearer as a virtual function is a virtual device too. So that term is overloaded. Let me know how you like the new text.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":111,"context_line":"    group inventory in Placement. Having two groups with the same type but with"},{"line_number":112,"context_line":"    different ``resource_class`` fields is possible and nova-compute will"},{"line_number":113,"context_line":"    apply the requested ``resource_class``. However such configuration is"},{"line_number":114,"context_line":"    unnecessarily complicated and therefore discouraged."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"  * ``traits`` is a list of strings defining Placement custom traits nova will"},{"line_number":117,"context_line":"    add to the Resource Provider representing the group."}],"source_content_type":"text/x-rst","patch_set":4,"id":"e562bb89_35ece311","line":114,"updated":"2026-05-08 15:18:45.000000000","message":"Is it not going to cause problems? Why would we allow this?\n\nAlso, don\u0027t we need to say that `device_spec` values for members in the group can\u0027t have the resource class set? It just seems way too confusing to allow multiple groups with different resource classes, each composed of devices which all have resource_class set to different values. I think that was in the old text and I don\u0027t see it here.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":111,"context_line":"    group inventory in Placement. Having two groups with the same type but with"},{"line_number":112,"context_line":"    different ``resource_class`` fields is possible and nova-compute will"},{"line_number":113,"context_line":"    apply the requested ``resource_class``. However such configuration is"},{"line_number":114,"context_line":"    unnecessarily complicated and therefore discouraged."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"  * ``traits`` is a list of strings defining Placement custom traits nova will"},{"line_number":117,"context_line":"    add to the Resource Provider representing the group."}],"source_content_type":"text/x-rst","patch_set":4,"id":"27bbe865_fc6aceeb","line":114,"in_reply_to":"e562bb89_35ece311","updated":"2026-05-11 15:11:41.000000000","message":"I tried to be flexible but I don\u0027t have to be. \n \n* (with intentionally riskingh over-correction) I removed the possibility to define a resource class in the group_spec. The type is already a free form string and the resource_class is derived from it, so we don\u0027t need yet another knob to override it.\n\n* The rc and trait definition of the grouped devices are actually defined at L162 as \n\u003e * ``resource_class`` and ``traits`` are not inherited to the group. If they\n\u003e  are defined in the ``[pci]device_spec`` for a grouped device then they are\n\u003e   ignored. \n\n  I would like to to keep this ignoring behavior as a single device_spec line can match multiple devices and some of those devices might not be groupped.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":120,"context_line":"  ``group_type`` to define a named alias for a group of the given type."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* Additionally the existing ``resource_class`` field of ``[pci]alias`` can also"},{"line_number":123,"context_line":"  be used instead of ``group_type`` to request a group."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Assume a machine with 10 PCI devices 0000:b0:00.0 - 0000:b9:00.0. Each with"}],"source_content_type":"text/x-rst","patch_set":4,"id":"724bfd5c_049b0297","line":123,"updated":"2026-05-08 15:18:45.000000000","message":"But why? Why not just make it required for groups? Or are you maybe pointing out that you can already do this (insanely obscure) thing and that it has to work for groups as well? le sigh.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":true,"context_lines":[{"line_number":120,"context_line":"  ``group_type`` to define a named alias for a group of the given type."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* Additionally the existing ``resource_class`` field of ``[pci]alias`` can also"},{"line_number":123,"context_line":"  be used instead of ``group_type`` to request a group."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Assume a machine with 10 PCI devices 0000:b0:00.0 - 0000:b9:00.0. Each with"}],"source_content_type":"text/x-rst","patch_set":4,"id":"999fce4c_77f51b27","line":123,"in_reply_to":"724bfd5c_049b0297","updated":"2026-05-11 15:11:41.000000000","message":"As resource_class is already a field of the pci alias, and actually supporting that for groups is close to zero complexity I opted to keep it instead of trying to reject it with extra logic.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e1df34b7844a7ab6663a019cede0a2ff2dc236e","unresolved":true,"context_lines":[{"line_number":132,"context_line":"  [pci]"},{"line_number":133,"context_line":"  device_spec \u003d {\"vendor_id\": \"10de\", \"product_id\": \"233b\", \"managed\": \"false\", \"live_migratable\": \"true\"}"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b0:00.0\", \"0000:b1:00.0\", \"0000:b2:00.0\", \"0000:b3:00.0\"], \"type\": \"nvidia-gpu-4x\", \"key\": \"nvidia-gpu-4x-1\"}"},{"line_number":136,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b4:00.0\", \"0000:b5:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-1\"}"},{"line_number":137,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b6:00.0\", \"0000:b7:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-2\"}"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ad81b858_3adb7daf","line":135,"updated":"2026-05-08 15:18:45.000000000","message":"Perhaps it\u0027s just me, but using `type` and `key` values that are different would help make this more readable. In reality, I imagine people will do what you show here, but it\u0027s too easy to read this and miss the `-1` and thus get the impression that `type` and `key` are the same. Just something like `gpu1`, `gpu2` would be sufficiently different I think. Just an idea.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":132,"context_line":"  [pci]"},{"line_number":133,"context_line":"  device_spec \u003d {\"vendor_id\": \"10de\", \"product_id\": \"233b\", \"managed\": \"false\", \"live_migratable\": \"true\"}"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b0:00.0\", \"0000:b1:00.0\", \"0000:b2:00.0\", \"0000:b3:00.0\"], \"type\": \"nvidia-gpu-4x\", \"key\": \"nvidia-gpu-4x-1\"}"},{"line_number":136,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b4:00.0\", \"0000:b5:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-1\"}"},{"line_number":137,"context_line":"  group_spec \u003d {\"addresses\": [\"0000:b6:00.0\", \"0000:b7:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-2\"}"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"a44a5ead_20f3a94c","line":135,"in_reply_to":"ad81b858_3adb7daf","updated":"2026-05-11 15:11:41.000000000","message":"Done","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":139,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\", \"live_migratable\": \"true\"}"},{"line_number":140,"context_line":"  alias \u003d {\"name\": \"gpu-4x\", \"group_type\": \"nvidia-gpu-4x\", \"live_migratable\": \"true\"}"},{"line_number":141,"context_line":"  alias \u003d {\"name\": \"gpu-1x\", \"vendor_id\": \"10de\", \"product_id\": \"233b\", \"live_migratable\": \"true\"}"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."}],"source_content_type":"text/x-rst","patch_set":4,"id":"4a28e85b_bff9317b","line":142,"updated":"2026-05-08 16:47:58.000000000","message":"```\n\n[pci]\n  device_spec \u003d {\"vendor_id\": \"10de\", \"product_id\": \"233b\", \"managed\": \"false\", \"live_migratable\": \"true\"}\n\n  group_spec \u003d [{\"addresses\": [\"0000:b0:00.0\", \"0000:b1:00.0\", \"0000:b2:00.0\", \"0000:b3:00.0\"], \"type\": \"nvidia-gpu-4x\", \"key\": \"nvidia-gpu-4x-1\"},\n               {\"addresses\": [\"0000:b4:00.0\", \"0000:b5:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-1\"},\n               {\"addresses\": [\"0000:b6:00.0\", \"0000:b7:00.0\"], \"type\": \"nvidia-gpu-2x\", \"key\": \"nvidia-gpu-2x-2\"}]\n\n  alias \u003d [{\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\", \"live_migratable\": \"true\"},\n          {\"name\": \"gpu-4x\", \"group_type\": \"nvidia-gpu-4x\", \"live_migratable\": \"true\"},\n          {\"name\": \"gpu-1x\", \"vendor_id\": \"10de\", \"product_id\": \"233b\", \"live_migratable\": \"true\"}]\n\n```\n\nif we supprot the list syntax this coudl be written like this\nwhich feels liek a small ux win but that just a nice to have for consistency","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d51533a48bfe6a7709b559322b7314bb2a1877ac","unresolved":true,"context_lines":[{"line_number":139,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\", \"live_migratable\": \"true\"}"},{"line_number":140,"context_line":"  alias \u003d {\"name\": \"gpu-4x\", \"group_type\": \"nvidia-gpu-4x\", \"live_migratable\": \"true\"}"},{"line_number":141,"context_line":"  alias \u003d {\"name\": \"gpu-1x\", \"vendor_id\": \"10de\", \"product_id\": \"233b\", \"live_migratable\": \"true\"}"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7b50c74f_cedabcca","line":142,"in_reply_to":"127bcd9e_6ea97f7a","updated":"2026-05-12 08:14:34.000000000","message":"I think it is reasonable. I will extend the scope with that to have consistency.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":true,"context_lines":[{"line_number":139,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\", \"live_migratable\": \"true\"}"},{"line_number":140,"context_line":"  alias \u003d {\"name\": \"gpu-4x\", \"group_type\": \"nvidia-gpu-4x\", \"live_migratable\": \"true\"}"},{"line_number":141,"context_line":"  alias \u003d {\"name\": \"gpu-1x\", \"vendor_id\": \"10de\", \"product_id\": \"233b\", \"live_migratable\": \"true\"}"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."}],"source_content_type":"text/x-rst","patch_set":4,"id":"881edf4f_41969abc","line":142,"in_reply_to":"4a28e85b_bff9317b","updated":"2026-05-11 15:11:41.000000000","message":"I have added the alternative syntax for group_spec. Do you suggest to add it to the alias as well?","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306724d72e287768a84fdfeaf34c087021e9e1bd","unresolved":true,"context_lines":[{"line_number":139,"context_line":"  alias \u003d {\"name\": \"gpu-2x\", \"group_type\": \"nvidia-gpu-2x\", \"live_migratable\": \"true\"}"},{"line_number":140,"context_line":"  alias \u003d {\"name\": \"gpu-4x\", \"group_type\": \"nvidia-gpu-4x\", \"live_migratable\": \"true\"}"},{"line_number":141,"context_line":"  alias \u003d {\"name\": \"gpu-1x\", \"vendor_id\": \"10de\", \"product_id\": \"233b\", \"live_migratable\": \"true\"}"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."}],"source_content_type":"text/x-rst","patch_set":4,"id":"127bcd9e_6ea97f7a","line":142,"in_reply_to":"881edf4f_41969abc","updated":"2026-05-11 15:35:04.000000000","message":"yes ideally\nif that does not expand the scoep to much\n\nthis was a painpoitn we hit in ci of our new inteslal as anbsibel ini modules didnt suprpot the repeated option and it made configurign this via ansibel without just using jinia templating tricky","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Note that all PCI devices matched to a ``[pci]device_spec`` are made available"},{"line_number":148,"context_line":"to nova, but those devices that are listed in one of the ``[pci]group_spec``"},{"line_number":149,"context_line":"values can only be consumed as part of their group and cannot be consumed"},{"line_number":150,"context_line":"individually any more."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"The existing ``[pci]device_spec`` tags can be used in the configuration even if"},{"line_number":153,"context_line":"the matched devices are later used in a ``[pci]group_spec``. But some have"},{"line_number":154,"context_line":"restrictions and some have extra meaning:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ab5fbcce_c7528479","line":151,"range":{"start_line":146,"start_character":1,"end_line":151,"end_character":1},"updated":"2026-05-08 16:47:58.000000000","message":"this will need a minor change to how the poc works but really not huge.\n\neffectively you will need to do this in 2 passes.\nfirst we need to filter the full set of host devices to just the set allowed by devices_spec, then you will need to annotate the devices with the type and key if\nthe match a group_spec based on the adress\n\nthat is doable but the current poc assumes the device_spec has thsoe tag so it all done in one pass currently.\n\nim really not woried about the performace fo that becasue we will effectivly do this once on start up and it can be cached form then on since we have never supproted changign these via mutable config.\n\njust noting this here as a place where the poc will need to be modified to accomadate this change.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":143,"context_line":"This configuration ensures the flavors can request 2 types of groups and one"},{"line_number":144,"context_line":"type of individual device, the nova-compute tracks and can allocate 3 groups"},{"line_number":145,"context_line":"and 2 individually consumable PCI devices to VMs."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Note that all PCI devices matched to a ``[pci]device_spec`` are made available"},{"line_number":148,"context_line":"to nova, but those devices that are listed in one of the ``[pci]group_spec``"},{"line_number":149,"context_line":"values can only be consumed as part of their group and cannot be consumed"},{"line_number":150,"context_line":"individually any more."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"The existing ``[pci]device_spec`` tags can be used in the configuration even if"},{"line_number":153,"context_line":"the matched devices are later used in a ``[pci]group_spec``. But some have"},{"line_number":154,"context_line":"restrictions and some have extra meaning:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6c974041_0e4df6d7","line":151,"range":{"start_line":146,"start_character":1,"end_line":151,"end_character":1},"in_reply_to":"ab5fbcce_c7528479","updated":"2026-05-11 15:11:41.000000000","message":"thanks for the note. It is valid, but I think it is an implementation detail so I will not add it to the spec.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":164,"context_line":"  ignored. These tags can be defined in the ``[pci]group_spec`` instead for the"},{"line_number":165,"context_line":"  whole group."},{"line_number":166,"context_line":"* The rest of the tags are applied only on the individual device level and not"},{"line_number":167,"context_line":"  inherited to the group in any ways."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Some of the existing tags in the ``[pci]alias`` have different meaning when"},{"line_number":170,"context_line":"the alias is requesting a group via the new ``group_type`` tag:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"c9194627_a9fdee9f","line":167,"updated":"2026-05-08 16:47:58.000000000","message":"+1 this is aligned to how i think this should work","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":182,"context_line":"  the ``group_spec``, i.e. the group needs to provide all the traits the alias"},{"line_number":183,"context_line":"  requests."},{"line_number":184,"context_line":"* ``live_migratable``: Supported to request a live migratable group."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Note that the PCI grouping feature is building on top of the pre-existing"},{"line_number":187,"context_line":"PCI in Placement feature and inherits all the limitations of it. See"},{"line_number":188,"context_line":"https://docs.openstack.org/nova/latest/admin/pci-passthrough#pci-tracking-in-placement"}],"source_content_type":"text/x-rst","patch_set":4,"id":"156fbc44_5c2c73c9","line":185,"updated":"2026-05-08 16:47:58.000000000","message":"perhasp we shoudl make one addtion to this list, specifically as with pci in placement we will not support physical_network  on the grouped devices today. or perhaps a better way to express that is even if the devspec has physical network today you wont be able to to create a neutron sriov port and have it corralate to a grouped nic in this proposal.\n\nthat could eventually be a thing but we shoudl just call that out as out of scope explcitly.\n\n\na scketch of how this coudl work in the fugure woudl be vai provider networking\nwe could add a new neutron_network or neutron_subnet key to the device spec which nova woudl use to creeate a port for the device.\nfor that to work that woudl have to be a shared provider network.\n\nanything beyond that woudl need neutron work to enabel which we dont need to discuss in any real detail.\n\nthis woudl be sort of like how ironic port groups work where it creats the neutron ports for you based on knoldage it has of the phsyical server.\ni dont think we need to speculate to much on a feature we are not plannign to add as part of this work","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":182,"context_line":"  the ``group_spec``, i.e. the group needs to provide all the traits the alias"},{"line_number":183,"context_line":"  requests."},{"line_number":184,"context_line":"* ``live_migratable``: Supported to request a live migratable group."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Note that the PCI grouping feature is building on top of the pre-existing"},{"line_number":187,"context_line":"PCI in Placement feature and inherits all the limitations of it. See"},{"line_number":188,"context_line":"https://docs.openstack.org/nova/latest/admin/pci-passthrough#pci-tracking-in-placement"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9085beb0_5d35d5c8","line":185,"in_reply_to":"156fbc44_5c2c73c9","updated":"2026-05-11 15:11:41.000000000","message":"Good point. Added a note here that this is out of scope.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":205,"context_line":"``[pci]alias``:"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"* ``vendor_id``, ``product_id``, and ``device_type`` cannot be defined when"},{"line_number":208,"context_line":"  ``group_type`` is defined."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Placement Integration"},{"line_number":211,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6a8365ad_adc0217a","line":208,"updated":"2026-05-08 16:47:58.000000000","message":"ack, that makes sense\n\ndevice type only exists for legacy reasons\n\nit is in the alias because QAT devices use the same vendor id and porduct id for boht the pf and vf\nso we need a way to slect which one was allocated.\n\nfor grouping as defieend above we are lisiting the adress of the specific devices in the group.\n\nas a result we dont need this added lay of filtering for grouped devices\n\nexcluding vendor_id and product_id is also self evident both for the same reasons, extra filter is not requried because we are specifying exact devices and because the corralation betwheen the alsise is based on teh group type not the devices in teh group.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":257,"context_line":"that the number of devices on the source and destination nodes are the same."},{"line_number":258,"context_line":"As there is no way to prevent the same group type defined differently on"},{"line_number":259,"context_line":"different compute nodes, the live-migration pre-check should handle detecting"},{"line_number":260,"context_line":"such divergence and rejecting the migration with a clear configuration error."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"NUMA Affinity Handling"},{"line_number":263,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e243bcbc_720a6fb2","line":260,"updated":"2026-05-08 16:47:58.000000000","message":"we do not need to detail if this is doen in the dest or souce node check but it defintlly can be doen on the souce node after we get the set of devices back form the destioant node in the migrate data object but im 99% we can do it on the destaion even before that so this shoudl be fieaseable in either case.\n\ni woudl prefer to do it in the destination but this is an implemention detail.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":257,"context_line":"that the number of devices on the source and destination nodes are the same."},{"line_number":258,"context_line":"As there is no way to prevent the same group type defined differently on"},{"line_number":259,"context_line":"different compute nodes, the live-migration pre-check should handle detecting"},{"line_number":260,"context_line":"such divergence and rejecting the migration with a clear configuration error."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"NUMA Affinity Handling"},{"line_number":263,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"357ffc2e_17162beb","line":260,"in_reply_to":"e243bcbc_720a6fb2","updated":"2026-05-11 15:11:41.000000000","message":"ack","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":false,"context_lines":[{"line_number":267,"context_line":"* **required**: All devices in the group must have NUMA"},{"line_number":268,"context_line":"  affinity to the guest NUMA nodes"},{"line_number":269,"context_line":"* **socket**: All devices must be on the same socket as the guest"},{"line_number":270,"context_line":"* **preferred/legacy**: The group with the most devices with affinity to the"},{"line_number":271,"context_line":"  guest NUMA nodes is selected. Groups are sorted by NUMA affinity score,"},{"line_number":272,"context_line":"  count of devices with affinity, but no groups are rejected."},{"line_number":273,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"2ef2d9df_05af908a","line":270,"range":{"start_line":270,"start_character":14,"end_line":270,"end_character":20},"updated":"2026-05-08 16:47:58.000000000","message":"i will note that this diverges very slightly form what legacy means for non grouped devices intentionally\n\nlegacy mean required if the define report Numa affinity and preferred if not.\n\nfor this new feature makign that disction does not really make sense\nand we can just use preferred for that\n\nlegacy was inteded to be deprecated and replace by preferred orginally but there was never really enough motivation to actully do that so \nfor gorups i think we effectily shoudl just have the 3 policies\nrequired, socket and preferred\n\nand just treat legacy whihch is the default as an alias of preferred in the context of groups since we dont really have any legacy behavoior to maintain\n\nthere is no reason to change any of the wording here just noteing why those 2 polices were orgtinally grouped.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":321,"context_line":"config is fixed or the dead device is replaced with the same type of device)"},{"line_number":322,"context_line":"with the same config nova will continue using it as is. If the device"},{"line_number":323,"context_line":"re-appears but with different configuration, i.e. now belonging to a different"},{"line_number":324,"context_line":"group than before then nova-compute will refuse to start."},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"Dependent device handling"},{"line_number":327,"context_line":"-------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"52ade429_d26cc307","line":324,"updated":"2026-05-08 16:47:58.000000000","message":"```\ni.e. now belonging to a different\ngroup than before then nova-compute will refuse to start.\n```\ni agree but ionly if its allocated\n\nif you want to move device bwetten groups atomicly and both groups are currenly free we could allow that rather then requireign 2 restart.\n\ni think that is way you intended just not that this could be read as meaning this apples even when the groups are free.\n\ni.e. if you take your 2 groups or 2 gpus and want to update to 1 group of 4 or 4 devices not in any group that shoudl be allowed when all the affected devices are free provide you do not voilate any of the other rules of devices only being refence in at most 1 group at a time.\n\ni think what you have written is logically correct but we could clarify this example by making that distinction","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":321,"context_line":"config is fixed or the dead device is replaced with the same type of device)"},{"line_number":322,"context_line":"with the same config nova will continue using it as is. If the device"},{"line_number":323,"context_line":"re-appears but with different configuration, i.e. now belonging to a different"},{"line_number":324,"context_line":"group than before then nova-compute will refuse to start."},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"Dependent device handling"},{"line_number":327,"context_line":"-------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"01066caf_7927b86a","line":324,"in_reply_to":"52ade429_d26cc307","updated":"2026-05-11 15:11:41.000000000","message":"yeah this paragraph start with \n\n\u003e device disappears from an already allocated group\n\nSo the intention is that this last rule also only applies to allocated groups. I added clarification about moving devices between groups.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":332,"context_line":"configured to be part of a single group and by that whoever consuming that"},{"line_number":333,"context_line":"group gets the whole PF and can handle its VFs in the guest. Or the VFs of the"},{"line_number":334,"context_line":"PF can be configured but not the PF itself. In this case individual VFs can"},{"line_number":335,"context_line":"belong to the same or different groups without any further restriction."},{"line_number":336,"context_line":""},{"line_number":337,"context_line":"Alternatives"},{"line_number":338,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2c7448de_e561b041","line":335,"updated":"2026-05-08 16:47:58.000000000","message":"there is one edge case we need to take note of.\n\nif we do the 2 phase approhc i suggested above wehre first the device spec filter down to the device nova is allowed ot mange and then we annotate the device if they are part fo a group we can ignore this comment but the degecase i was thinkg of is as follwos\n\nin ``[pci]device_spec`` you can specify the adresss of a PF with the vendor id and product id of the VF\n\nand that is a shorthand for saying nova can use all the VFs whoes parte PF is denoted by the relevent adress\n\nso without groupign the PF is never consider manged by nova in that case and cant be requested.\n\nwe just need to make sure that that continues to work i.e. that you can have the adres of the pf in teh devsapec while grouping the VFs undereath it\n\npci in placement already handels this properly in the non group case so this is just me saying this is where one of the dragons lives and we shoudl confim we dont break this.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":true,"context_lines":[{"line_number":332,"context_line":"configured to be part of a single group and by that whoever consuming that"},{"line_number":333,"context_line":"group gets the whole PF and can handle its VFs in the guest. Or the VFs of the"},{"line_number":334,"context_line":"PF can be configured but not the PF itself. In this case individual VFs can"},{"line_number":335,"context_line":"belong to the same or different groups without any further restriction."},{"line_number":336,"context_line":""},{"line_number":337,"context_line":"Alternatives"},{"line_number":338,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"84552edf_b02e4c32","line":335,"in_reply_to":"2c7448de_e561b041","updated":"2026-05-11 15:11:41.000000000","message":"Hm. I keep this open for now as I have to look into this how this works today with PCI in Placement. Thanks for noting it.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ea54d9033dea492db8084cf51237af4724dd6011","unresolved":true,"context_lines":[{"line_number":332,"context_line":"configured to be part of a single group and by that whoever consuming that"},{"line_number":333,"context_line":"group gets the whole PF and can handle its VFs in the guest. Or the VFs of the"},{"line_number":334,"context_line":"PF can be configured but not the PF itself. In this case individual VFs can"},{"line_number":335,"context_line":"belong to the same or different groups without any further restriction."},{"line_number":336,"context_line":""},{"line_number":337,"context_line":"Alternatives"},{"line_number":338,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6d51985b_9afa4a1d","line":335,"in_reply_to":"84552edf_b02e4c32","updated":"2026-05-12 09:50:29.000000000","message":"i belive today we create a singel RP using the PF adress and create inventories of the VF withthe VF vendor id and product id\n\ni belive this does wok with pci in placmeent as we have had a conversation about this in the past\n\nits one of those thing that is very poorly documented outside fo the test and code coments","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":404,"context_line":"2. Remove existing device_spec entries for those devices"},{"line_number":405,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":406,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":407,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"**Rolling upgrade considerations:**"},{"line_number":410,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fc95ba78_812da7da","line":407,"updated":"2026-05-08 16:47:58.000000000","message":"so i know this workflow works in my poc so this is defintly the baselien\n\ni also believe we could eliminate 2 and 3\n\nand do this atomicly with one restart\n\npart of the reason for that is in the new model with group_spec the device_spec is still used to declare the device that are managable by nova and the the group spec is just grouping subset of thos edevcices.\n\n\nso the device_spec for will still need to exist and allow the device to be managed.\n\nall that we have to do is add the group type/key as tags on teh decie\n\nso as long as the device is not allcoated ot any isntance this coudl just be\n\n```\n1. Ensure no instances are using the devices\n2. Add the new group-based device_spec configuration\n3. Restart nova-compute to create the new group resource providers\n```\n\nthat woudl require you to first update the orginal RP to reduce the total\nand then create teh new RP for the group but that shoudl be possibel to sequence correfctly.\n\nthat is something i think we can leasge to the implemetion reivew to determin how much work makign that would would be in reality and if that complexity is really worth the beifit or one lese restart.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":false,"context_lines":[{"line_number":404,"context_line":"2. Remove existing device_spec entries for those devices"},{"line_number":405,"context_line":"3. Restart nova-compute to remove the old resource providers"},{"line_number":406,"context_line":"4. Add the new group-based device_spec configuration"},{"line_number":407,"context_line":"5. Restart nova-compute to create the new group resource providers"},{"line_number":408,"context_line":""},{"line_number":409,"context_line":"**Rolling upgrade considerations:**"},{"line_number":410,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"8b48e230_084bbb51","line":407,"in_reply_to":"fc95ba78_812da7da","updated":"2026-05-11 15:11:41.000000000","message":"Ohh I forgot to update this procedure when I introduced the group_spec. Done now. I agree that we should do the one restart approach.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba8ce10cfc4b1aa7266a5ca80bb19a2f095be20a","unresolved":true,"context_lines":[{"line_number":471,"context_line":"  implementation work of this feature we will re-evaluate the situation to see"},{"line_number":472,"context_line":"  if:"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"  * emulated IGB NIC is available in CI for testing. This depends on the node"},{"line_number":475,"context_line":"    provider\u0027s version of nova"},{"line_number":476,"context_line":"  * check the 3rd party RDO CI if it has IGB support"},{"line_number":477,"context_line":"  * check if the kernel module based SRIOV simulator trials in cyborg are in a"},{"line_number":478,"context_line":"    usable state for us."}],"source_content_type":"text/x-rst","patch_set":4,"id":"dab68e27_19716b9c","line":475,"range":{"start_line":474,"start_character":4,"end_line":475,"end_character":30},"updated":"2026-05-08 16:47:58.000000000","message":"so a slight wrinkel with this.\n\nwhe opendev moved to useing zuul to build image and zuul-laucher to providsion the workers instad of nodepool-builder and nodepool-laucher \nit lost the ablity to add glance metadata keys on the iagage it uploads because that feature was not ported form notpool when they did the reimpeljetion\n\nso until we work with the zuul comunity to adress that regression we do not have a path to testing this in the first party ci and we will likely loses that capablity in the thirdpary rdo ci if they also upgrade there zuul.\n\nwith that said i think we can still expore other options for this and we shoudl see if we can readd this capablity to zuul.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ea54d9033dea492db8084cf51237af4724dd6011","unresolved":true,"context_lines":[{"line_number":471,"context_line":"  implementation work of this feature we will re-evaluate the situation to see"},{"line_number":472,"context_line":"  if:"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"  * emulated IGB NIC is available in CI for testing. This depends on the node"},{"line_number":475,"context_line":"    provider\u0027s version of nova"},{"line_number":476,"context_line":"  * check the 3rd party RDO CI if it has IGB support"},{"line_number":477,"context_line":"  * check if the kernel module based SRIOV simulator trials in cyborg are in a"},{"line_number":478,"context_line":"    usable state for us."}],"source_content_type":"text/x-rst","patch_set":4,"id":"1f61a221_f0c5c028","line":475,"range":{"start_line":474,"start_character":4,"end_line":475,"end_character":30},"in_reply_to":"3295c7dd_19a12f95","updated":"2026-05-12 09:50:29.000000000","message":"yes\n\nso we have 2 trhings in flight first chandan is working on creating some docs of how to locally create vms for testing with devstack and simulating nvme devices \nhttps://review.opendev.org/c/openstack/cyborg/+/982711\n\nbut they also have devstack automation fo the same\n\nhttps://review.opendev.org/c/openstack/cyborg/+/977083\n\nwe have got as far as the deivce is visable to the kernel and lspci/libvirt\nbut we cannot boot a vm in the ci becasue we are missing the iommu.\n\nbecause of the cvew work i have been doing for the last few month i never got a chance to test my kernel driver\nhttps://github.com/SeanMooney/linux/tree/pci-sim\nor the kubvirt one that pretends to be a gpu\nbut i might see if i can spend a day or so on that and see if i cna get either working\n\nthe differce with my kernel module is im triing to use the soft iommu to remove the need for the vIOMMU so that it could run in an upstream ci without special lables.","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d51533a48bfe6a7709b559322b7314bb2a1877ac","unresolved":true,"context_lines":[{"line_number":471,"context_line":"  implementation work of this feature we will re-evaluate the situation to see"},{"line_number":472,"context_line":"  if:"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"  * emulated IGB NIC is available in CI for testing. This depends on the node"},{"line_number":475,"context_line":"    provider\u0027s version of nova"},{"line_number":476,"context_line":"  * check the 3rd party RDO CI if it has IGB support"},{"line_number":477,"context_line":"  * check if the kernel module based SRIOV simulator trials in cyborg are in a"},{"line_number":478,"context_line":"    usable state for us."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3295c7dd_19a12f95","line":475,"range":{"start_line":474,"start_character":4,"end_line":475,"end_character":30},"in_reply_to":"7e566b0d_beb8b671","updated":"2026-05-12 08:14:34.000000000","message":"that is sad. Then indeed we need to dig into zuul if we want to go this route. \n@smooney@redhat.com do you have pointers about plan C here to any work with a kernel module simulating sriov devs?","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306724d72e287768a84fdfeaf34c087021e9e1bd","unresolved":true,"context_lines":[{"line_number":471,"context_line":"  implementation work of this feature we will re-evaluate the situation to see"},{"line_number":472,"context_line":"  if:"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"  * emulated IGB NIC is available in CI for testing. This depends on the node"},{"line_number":475,"context_line":"    provider\u0027s version of nova"},{"line_number":476,"context_line":"  * check the 3rd party RDO CI if it has IGB support"},{"line_number":477,"context_line":"  * check if the kernel module based SRIOV simulator trials in cyborg are in a"},{"line_number":478,"context_line":"    usable state for us."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7e566b0d_beb8b671","line":475,"range":{"start_line":474,"start_character":4,"end_line":475,"end_character":30},"in_reply_to":"98829c6d_de9dcede","updated":"2026-05-11 15:35:04.000000000","message":"tags are differnt \n\nhttps://docs.openstack.org/api-ref/image/v2/#image-tags\nthey work like nova server tags as a quick way to filter images\n\nhttps://docs.openstack.org/api-ref/image/v2/#update-image\n\nis used for the image properties","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"23f61d4bb8cd42f5aed8183082593a1eb325d3e2","unresolved":true,"context_lines":[{"line_number":471,"context_line":"  implementation work of this feature we will re-evaluate the situation to see"},{"line_number":472,"context_line":"  if:"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"  * emulated IGB NIC is available in CI for testing. This depends on the node"},{"line_number":475,"context_line":"    provider\u0027s version of nova"},{"line_number":476,"context_line":"  * check the 3rd party RDO CI if it has IGB support"},{"line_number":477,"context_line":"  * check if the kernel module based SRIOV simulator trials in cyborg are in a"},{"line_number":478,"context_line":"    usable state for us."}],"source_content_type":"text/x-rst","patch_set":4,"id":"98829c6d_de9dcede","line":475,"range":{"start_line":474,"start_character":4,"end_line":475,"end_character":30},"in_reply_to":"dab68e27_19716b9c","updated":"2026-05-11 15:11:41.000000000","message":"Thanks. I looked at the zuul doc and I\u0027m wondering if `tags` https://acmegating.com/docs/zuul/latest/drivers/openstack.html#attr-provider[openstack].image-defaults.tags are actually image properties or not. Our CI does not have examples of such so I\u0027m not sure. (I only see https://opendev.org/opendev/zuul-providers/src/commit/a0079778af4fa32d62ff2aa922805fed22fbca68/zuul.d/providers.yaml#L9 )","commit_id":"519f90594561411547f6bf114bb5a01ba9c85232"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"539cf16b70445d9642ab536c222f9614cecbbc8f","unresolved":true,"context_lines":[{"line_number":322,"context_line":"--------------------------"},{"line_number":323,"context_line":""},{"line_number":324,"context_line":"Adding devices to or removing from a group is supported only if both"},{"line_number":325,"context_line":"the devices moved and the devices in the group are free, not allocated to any"},{"line_number":326,"context_line":"instance. Note that changing the size of a group in a way that the groups in"},{"line_number":327,"context_line":"the same type have a different number of devices is not supported. Each"},{"line_number":328,"context_line":"group in a type should always mean the same number of devices. If a"},{"line_number":329,"context_line":"device needs to be replaced in a group then removing the old one and adding a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f8a29949_bc8f9dfe","line":326,"range":{"start_line":325,"start_character":57,"end_line":326,"end_character":10},"updated":"2026-05-12 08:21:40.000000000","message":"and not reserved in placement as that could mean the device is a dirty one_time_use device.","commit_id":"793f271b0a471ec32371aecc6cc7298af9d38d8e"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"539cf16b70445d9642ab536c222f9614cecbbc8f","unresolved":true,"context_lines":[{"line_number":343,"context_line":"group than before then nova-compute will refuse to start."},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"Moving a device between groups is only allowed if the device and both groups"},{"line_number":346,"context_line":"are not allocated."},{"line_number":347,"context_line":""},{"line_number":348,"context_line":"Dependent device handling"},{"line_number":349,"context_line":"-------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"31eb1fec_65017550","line":346,"range":{"start_line":346,"start_character":8,"end_line":346,"end_character":18},"updated":"2026-05-12 08:21:40.000000000","message":"and the device is not reserved in placement as that means a dirty one_time_use device.","commit_id":"793f271b0a471ec32371aecc6cc7298af9d38d8e"}]}