)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d1405f8e8dddbfb330c61c6cac8f2cb596f5ec41","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4c101bb3_2e0611aa","updated":"2025-11-20 13:37:55.000000000","message":"I have couple of questions inline.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"adc614e2_97b323cb","updated":"2025-12-02 14:34:47.000000000","message":"looks to me mostly an implementation discussion rather than a spec, but I think we need to discuss more about how to be able to upgrade from the nova vgpus to the cyborg ones and how we could be sure that the operator is doing this correctly.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"24267f067f3a0898dc9979e094438d4e216571e7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"88055fad_fe0a17ad","in_reply_to":"52134e89_e365e403","updated":"2025-12-03 09:10:18.000000000","message":"it makes sense to specify that in the upgrade impact for mdevs devices, when changing its owner","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"56905721187e80abc767dc5d3efb35592899d453","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"52134e89_e365e403","in_reply_to":"7c91e68d_5325b0ab","updated":"2025-12-02 15:44:08.000000000","message":"im not sure what the concern is here.\n\nthe upgrade storage is simple. \nyou must resize the worklaods to a new flavor\n\nso its exactly the same as \nhttps://specs.openstack.org/openstack/nova-specs/specs/2025.1/implemented/enable-vfio-devices-with-kernel-variant-drivers.html\n\nnova live inplace conversion is possible because we need to enrole the devices in cybrog, change the instance flavor and the placment allcaotins\n\nthe way to do that is just via a resize.\n\nim puting a very stong line in the sand that a singel hardware device must not be manged by 2 services so to adopt cybrog device managemenet you need to drain the workload form the nova managed devices. remove the devices form nova\u0027s config and then install cyborg and enable it to manage the device.\n\nbut that is all out of scope fo the spec to document IMO.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fbd60686dcaf0cdd0c711b898adbfae7753d0bc2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0b4c750e_6d2e66e4","in_reply_to":"88055fad_fe0a17ad","updated":"2025-12-03 10:36:12.000000000","message":"This is not an upgrade impact since this is something you would only ever do post upgrade to the release that supports this. When upgrading the device will continue to be managed by nova exactly as they are today.\n\nif you want to adopt this feature post upgrade framing it as changing its owner is not the right way to think about htis. Its more like we are scaling it in and scaling it back out.\n\nwe are removing the mdev resource form the set that nova provides which will remove the placement resource provider for it. To do that we need to drain the exisign workloads form a compute node, then after that is complete we disable the compute service, remove the mdev config form nova and install cycborg,\nCyborg will then creeat its own rplacement resouce provider with diffent traits and resouce clases.once that is complete we can create the new device profiles and flavors that use that device profile and finable enable the compute service again.\n\nso the process is effectivly drain the node, reconfigure nova, install cycborg,\npotitally reconfigrue the gpu in cyborg, then create a device profiel and new flavors then renable the nova compute and start using it for new workloads.\n\n\nwhen upgrading you do none of that, you continue to use the existing nova supprot unchanged.\n\nwhen that is the upgrade path to using a feature we normally just say you need to resize the workload to use the new feature since the installation of the software is not normally in scope fo a spec or upgrades.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9b627c60ae1092ea278cc638c7f5ea804cd70317","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7c91e68d_5325b0ab","in_reply_to":"adc614e2_97b323cb","updated":"2025-12-02 14:37:35.000000000","message":"good point. IIUC Cyborg path only activates when device profile is in flavor and parent GPU is NOT in Nova config. That should be an upgrade requirement to switch if fron Nova to Cyborg, right?","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"63e69e23a581ae5bc3b05a56cac6f84be1fb421b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"bfe5a27a_ff7ea8bf","updated":"2025-12-04 18:08:34.000000000","message":"fixed pep8","commit_id":"156dd22f1eb3ecfb7874f227b238a6630b6975a5"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"4ca93fc9ea3a1388bd03f283503d775304208006","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"534c647b_a87bdb3b","updated":"2025-12-05 11:00:53.000000000","message":"thank you, this LGTM","commit_id":"156dd22f1eb3ecfb7874f227b238a6630b6975a5"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9e7862b68a6be65874b6eb500893f26f1de25406","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"11c18836_2773a880","updated":"2026-04-20 09:51:09.000000000","message":"Draft review (unpublished):\n\n(1) Upgrade impact: the section opens with \"None\" but then describes a new compute service version, a scheduler pre-filter gated on minimum compute version, and flavor migration via resize. Please reconcile so operators get one coherent story during rolling upgrades.\n\n(2) Mixed-version / Placement: when some computes have not yet applied OWNER_NOVA to Nova-owned vGPU RPs while Cyborg also reports the same hardware, what prevents double booking or ambiguous allocations? A short explicit paragraph and test plan would help core review.\n\n(3) Lifecycle: please spell out delete / ERROR / teardown when Nova creates persistent mdevs from Cyborg ARQs, and how that stays consistent with Cyborg ARQ state.\n\n(4) Launchpad blueprint text still reads Wallaby-era; consider updating the whiteboard or linking this reproposed MDEV spec so reviewers are not confused.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"a9ff4f976ac337935f689999e1b927cbe4dc5b05","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"90a246cf_e96d55bb","updated":"2026-04-20 09:52:37.000000000","message":"I missed to remove \"Draft review (unpublished)\", sorry, I did review the comments actually before submitting those suggestions generated with agentic review","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c4a279103805dd9e7f9dedf50dc5f345c5efd645","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"dac89271_0b2f2ba6","updated":"2026-03-27 13:55:07.000000000","message":"Please also cover the failure modes if the \"other side\" is unavailable during the operation. \n\nWhat happens to the ARQ in Cyborg when instance build with ARQ fails in Nova? It would presumably time out and the associated resources would be reclaimed.\n\nWhat if the information in the ARQ from Cyborg is stale? For example, if the parent device was removed from the host between Cyborg\u0027s discovery and Nova\u0027s build request. Nova\u0027s creation attempt would fail.\n\nAlso scenarios when Cyborg conductor is down when Nova needs to build an ARQ, or the Nova compute service fails after the mdev is created but before the VM is launched","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"}],"specs/2026.1/approved/cyborg-vgpu-support.rst":[{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"47c7c03ef260c8a45455d48b5b40f59720a2fcb4","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bb851996_4a3772a9","line":25,"updated":"2025-11-18 12:44:32.000000000","message":"How Nova (auto?)detects whether mdev is Cyborg-managed or self-managed?\nIf not auto, some API or data model change would be required to explicitly tell it about the wanted mdev source?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8cb44d866ad39bdd6ce7297c85c488fae5c21db3","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4649097f_eb7efd29","line":25,"in_reply_to":"0b875ab0_97d6a41a","updated":"2025-11-18 13:13:31.000000000","message":"that wont work.\n\ncyborg need to inventory and create the mdevs and report them ot placement when its managing them and we need to claim the device in its db as well as in placment\n\nso there is nothign we can put in nova config to make the selection on the compute node\n\neven in the api.schdluer this would be problemaitc as you need to have a cyborg device profile in cyborg api which is there version fo a flaovr for a given device.\n\nthere is no way to avoid using seperate falvors for nova managed mdev and cyborg managed ones without breaking backward compatibality  for nova managed vgpus\n\nthis si why we are not trying to do that in this spec.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c70a170036a79545abb7614fc1eb0130909ace61","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"6a0828fb_71b839af","line":25,"in_reply_to":"4649097f_eb7efd29","updated":"2025-11-18 13:27:49.000000000","message":"I see, thank you.\nIs that valid to state that there is a requirement that human operator must ensure parent GPU is NOT in Nova config when using Cyborg?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8907d98536ad1b599344aa8b808e062aac1122db","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"98139486_0d6d61ef","line":25,"in_reply_to":"4f0158c9_420d1520","updated":"2025-11-18 15:08:09.000000000","message":"while its techinally possible to look up the parent of an mdev im not sure if we should but that validation in nova but it might be reasonable to do.\nthat can only happen at server create time and the only option we woudl have is to raise a build error.\n\nit woudl not be reasonable for nova to parse the placment tree or to query cyborg for its devicecs on startup.\n\n\ncyborg and nova mange ment on the same host is valid and it is valid to have some device provide by nova and ohter provided by cyborg in the same vm.\nits only a misconfiugration if a single device is listed for both services to manage.\n\ndocumenation updated is covered by https://review.opendev.org/c/openstack/nova-specs/+/967515/1/specs/2026.1/approved/cyborg-vgpu-support.rst#275\n\nwe dont currently have a proper cyborg doc so im proposing creating one as part of this work.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"0f066f973fcb21c0895f1e6283f019bc93ef0095","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4f0158c9_420d1520","line":25,"in_reply_to":"6a0828fb_71b839af","updated":"2025-11-18 13:31:25.000000000","message":"If that assumption is correct, some docs impact and maybe oslo config validations for these:\n\n* Document that parent GPU must NOT be in Nova config when using Cyborg\n* Add validation warning if both Nova config and Cyborg ARQs present (misconfiguration)\n* Update operator documentation with clear separation guidelines\n\nWDYT?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f6b651446defd1a0f8fd8bcc7a350702cf3003a3","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"2c04b6d9_9ef5f70c","line":25,"in_reply_to":"6a0828fb_71b839af","updated":"2025-11-18 13:30:50.000000000","message":"yep https://review.opendev.org/c/openstack/nova-specs/+/967515/1/specs/2026.1/approved/cyborg-vgpu-support.rst#213","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"a98f0a755dd9252d1feb173c6116ced614ffb22a","unresolved":false,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f54b71a_e21e91f9","line":25,"in_reply_to":"98139486_0d6d61ef","updated":"2025-12-02 14:32:24.000000000","message":"ok","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"e4c27a45827e32b005cd24cf0e0bdaaefccb440a","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"0b875ab0_97d6a41a","line":25,"in_reply_to":"bb851996_4a3772a9","updated":"2025-11-18 13:04:34.000000000","message":"Maybe it could be a new config option to pointing which of mdev providers to use (or prefer), like\n\n   [cyborg]\n   delegate_mdev_management \u003d True  # Default: False for backward compat","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a1f227237ee10f4c6de73bdc83edae38d04b9e9a","unresolved":true,"context_lines":[{"line_number":22,"context_line":"the vGPUs, reports them to placement, and instruct nova to allocate a specific"},{"line_number":23,"context_line":"vfio-mdev to the instance."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Cyborg managed mdevs will not replace nova\u0027s native vGPU capabilities [1]_"},{"line_number":26,"context_line":"and will provide an alternative management mechanism in parallel to the"},{"line_number":27,"context_line":"existing nova feature."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7295743c_bbf30baf","line":25,"in_reply_to":"bb851996_4a3772a9","updated":"2025-11-18 12:55:30.000000000","message":"no, nova only manages mdevs if you list there parent device in its config.\n\nnova will know its a cyborg manged mdev because there will be a cyborg device profile in the flavor and the ARQ (acclerate request object) will be populated with a attach_handle_type of type MDEV with the mdev uuid\n\nso nova wont condier the cyborg manged mdev for its normal use bcuase you willnot list the parent gpu in nova\u0027s config\n\nand it know to include the mdev in the xml because of the respocne form cyborg within in the ARQ. so no api changes are needed in nova or cybrog since cyborg added the MDEV respocne type in wallaby as noted below in the proposed chagnes section.\n\nnova just need to be updated to wire it up in the xml.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d1405f8e8dddbfb330c61c6cac8f2cb596f5ec41","unresolved":true,"context_lines":[{"line_number":124,"context_line":"     on start up. Ideally it would set the binding state to \"provisioning\" on"},{"line_number":125,"context_line":"     start up also. And we would have anohter state \"unknown\" that cyborg-api"},{"line_number":126,"context_line":"     would report if the cyborg agent misses its heart beat."},{"line_number":127,"context_line":"     So on start up, when nova compute tries to get accel_info and reboot all"},{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ecb4fa1_fbbd6c24","line":128,"range":{"start_line":127,"start_character":5,"end_line":128,"end_character":19},"updated":"2025-11-20 13:37:55.000000000","message":"Nova by default does not reboot instances at host reboot or nova-compute startup. \n\nAlso nova-compute today does not distinguish between a nova-compute restart and a whole host restart. So whathever nova-compute needs to do if the host was restarted nova-compute will at least try to do it at every nova-compute startup even if only the nova-compute service was restarted but not the host. This should not lead to any disruption to already running VMs.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":124,"context_line":"     on start up. Ideally it would set the binding state to \"provisioning\" on"},{"line_number":125,"context_line":"     start up also. And we would have anohter state \"unknown\" that cyborg-api"},{"line_number":126,"context_line":"     would report if the cyborg agent misses its heart beat."},{"line_number":127,"context_line":"     So on start up, when nova compute tries to get accel_info and reboot all"},{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"528b4f77_37e21457","line":128,"range":{"start_line":127,"start_character":5,"end_line":128,"end_character":19},"in_reply_to":"1062c142_be7d762a","updated":"2025-12-04 17:18:50.000000000","message":"it turns out that in antelope cyborg added the informatoin reuqired for nova to persit the mdevs wo we will use the same code path nova uses to persit it across reboots.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c36506a5d035fad299cfbd88afd747adaa0eb8e5","unresolved":true,"context_lines":[{"line_number":124,"context_line":"     on start up. Ideally it would set the binding state to \"provisioning\" on"},{"line_number":125,"context_line":"     start up also. And we would have anohter state \"unknown\" that cyborg-api"},{"line_number":126,"context_line":"     would report if the cyborg agent misses its heart beat."},{"line_number":127,"context_line":"     So on start up, when nova compute tries to get accel_info and reboot all"},{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1062c142_be7d762a","line":128,"range":{"start_line":127,"start_character":5,"end_line":128,"end_character":19},"in_reply_to":"5ecb4fa1_fbbd6c24","updated":"2025-11-21 15:22:52.000000000","message":"ya i need to rework this.\n\ni actully am not sure i agree with what was organically accepted in the wallaby. \n\nthis is just a direct copy form the wallaby version documetnign what cyborg did\nbut its a secont i knew i would have to update.\n\nsince that time we added a call to cinder on \"hard reboot\" which is what called if you enable the config option to resume guest on host reboot.\nso if we want to extend that to cybrog as well on all hard reboots but im hopign we can modify how cyborg works to not need that.\n\nwe are also exploring pre creating the mdevs using a systemd service file simular\nto https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#enable-gpu-types-compute or using nvidia-parted.\n\nsince wallyable we also change how nova works to have libvirt manage the persitence fo the mdev across reboots using mdevctl under the covers to do that.\n\nif we dont do that i think cyborg should be update to use mdevctl to manage the persitance of the mdevs across reboots for partity with libvirt, that woudl remvoe the need for this special handleign for reboot and improve the overall ux.\n\nbasically my vision for this on the cyborg side si to ensure that on host reboot cyborg does not need to do anything for the mdev to be useable by nova and this\nrebinding of the ARQ should not be required at all\n\nwould it be better fi i rewrote this to just focus on teh nova side and remove the information about what cyborg already does?\n\n\nlater\n-----\nactully thinking about this one of the option woudl be to continue to use livbirt to do the persitence via the xml.\n\ncyborg need to persist th uuid in its db which it already does but we might be able to just remove this section entirly thanks to the work that melaine did in \nhttps://github.com/openstack/nova/commit/74befb68a79f8bff823fe067e0054504391ee179\n\nthis entire section is only here because in wallaby nova created the mdevs when it defiend the xml, but with the persistent-mdevs feature in nova none of this shoudl be required anymore. let me confirm that and ill update the spec to reflect it.\n\neven later\n---------\nno that wont work without changing the format of the  attachment handel returned by cybog ad it does not contian the mdev type or partent device info required for nova to create it\n\n```\n       {\n           \u0027attach_handle_type\u0027: \u0027MDEV\u0027,\n           \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,\n       }\n```\n\n\ni woudl have to change the api respocne format in cybrog to supprot this which might make sense for a future release\n\nill note this as one of the primary opens to adress and get back to you.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d1405f8e8dddbfb330c61c6cac8f2cb596f5ec41","unresolved":true,"context_lines":[{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"},{"line_number":132,"context_line":"     same binding complete event notification when it change the status form"},{"line_number":133,"context_line":"     \"provisioning\" to \"bound\" as it does during normal arq binding."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"4. Avoiding conflicts when cyborg vGPU management co-exists with nova"},{"line_number":136,"context_line":"   vGPU management. (partially completed in wallaby)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e7305bff_4e8b6930","line":133,"range":{"start_line":131,"start_character":57,"end_line":133,"end_character":68},"updated":"2025-11-20 13:37:55.000000000","message":"Do you suggest here that nova-compute during startup should start waiting for these bound events?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":false,"context_lines":[{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"},{"line_number":132,"context_line":"     same binding complete event notification when it change the status form"},{"line_number":133,"context_line":"     \"provisioning\" to \"bound\" as it does during normal arq binding."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"4. Avoiding conflicts when cyborg vGPU management co-exists with nova"},{"line_number":136,"context_line":"   vGPU management. (partially completed in wallaby)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b2dff856_d31d3a51","line":133,"range":{"start_line":131,"start_character":57,"end_line":133,"end_character":68},"in_reply_to":"000bcf0e_66bf5108","updated":"2025-12-02 15:39:02.000000000","message":"i have rewritent this to bettter clarify the persitence story and make it clear nova will not call cybrog on hard reboot.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c36506a5d035fad299cfbd88afd747adaa0eb8e5","unresolved":true,"context_lines":[{"line_number":128,"context_line":"     the instances, it would see 1 of 3 states, \"bound\" if the cyborg agent"},{"line_number":129,"context_line":"     started first and already completed bininding, \"unknown\" if the cyborg"},{"line_number":130,"context_line":"     agent has not heartbeat to the cyborg conductor yet, and \"provisioning\""},{"line_number":131,"context_line":"     if the agent is in the process of creating the mdev. Cyborg will send the"},{"line_number":132,"context_line":"     same binding complete event notification when it change the status form"},{"line_number":133,"context_line":"     \"provisioning\" to \"bound\" as it does during normal arq binding."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"4. Avoiding conflicts when cyborg vGPU management co-exists with nova"},{"line_number":136,"context_line":"   vGPU management. (partially completed in wallaby)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"000bcf0e_66bf5108","line":133,"range":{"start_line":131,"start_character":57,"end_line":133,"end_character":68},"in_reply_to":"e7305bff_4e8b6930","updated":"2025-11-21 15:22:52.000000000","message":"that was the suggetion in wallaby i dont like that see my comemnt above.\ni have not had the time to dedicate to reqorkign this spec that i was hopign for as my primary focus was the resouce provider weigher.\n\nthis only became a topic of interest for me the week before the ptg\nso im refining it as best i can but i acknowldage this need more work.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d1405f8e8dddbfb330c61c6cac8f2cb596f5ec41","unresolved":true,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"69c43441_e9318c7b","line":168,"updated":"2025-11-20 13:37:55.000000000","message":"The https://blueprints.launchpad.net/nova/+spec/owner-nova-trait-usage bp is still not implemented in nova. Do I understand correctly that such bp and the related spec will also be re-proposed for G and will be implemented first before we implement the feature discussed in this spec under review?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":false,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"568acaae_130ec32c","line":168,"in_reply_to":"594ba8e8_f69a469a","updated":"2025-12-02 15:39:02.000000000","message":"Done","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2aabea35f1ace9b66945af7f612afc44991f8262","unresolved":true,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fcb80d4f_5b2a5764","line":168,"in_reply_to":"603cab0f_bc839fbb","updated":"2025-11-25 14:03:56.000000000","message":"It is OK to me to get that included here and just keeping the implementation in separate independently landable patches. \n\nOne thing to note probably here is that owner trait might have an upgrade impact as the scheduler should not include the owner trait to the placement request if there are old computes in the system not providing the owner trait to placement in the compute RP, otherwise during the upgrade we limit the cloud to only schedule workload to the already upgraded compute. Which is probably not what we want.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"37748cd53f7f9ab11c29fdbcbcc1b9d0ecb18d12","unresolved":true,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ea68cbac_c9252e86","line":168,"in_reply_to":"69c43441_e9318c7b","updated":"2025-11-20 14:29:30.000000000","message":"I have also thought that owner-nova-trait-usage should be the 1st step for Nova","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c36506a5d035fad299cfbd88afd747adaa0eb8e5","unresolved":true,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"603cab0f_bc839fbb","line":168,"in_reply_to":"ea68cbac_c9252e86","updated":"2025-11-21 15:22:52.000000000","message":"no i was suggestion just using this spec to track this\n\nas it literally is just adding that single trait to every resource provider we create and adding it to resource request that come directly form the flavor  i didnt think that deserved its own spec since we have already added the trait to os-triat and cyborg is already adding its tratis to its resource classes.\n\ni do howeve need to rework this spec to clearly  call out what need to be done.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6c779cda761c5356cedbac1a12d04fbadfe1de39","unresolved":true,"context_lines":[{"line_number":165,"context_line":"    The nova side was repoposed in zed"},{"line_number":166,"context_line":"    https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html"},{"line_number":167,"context_line":"    but never completed. As part of this spec the OWNER_NOVA trait will be"},{"line_number":168,"context_line":"    added to nova managed resource providers."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Alternatives"},{"line_number":171,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"594ba8e8_f69a469a","line":168,"in_reply_to":"fcb80d4f_5b2a5764","updated":"2025-11-25 18:16:09.000000000","message":"oh yep that probaly shoudl be gated behind a min compute servcei version check.\n\ni dont think we will need a config option to opt into to this if we do that\n\nill add that to the spec","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d1405f8e8dddbfb330c61c6cac8f2cb596f5ec41","unresolved":true,"context_lines":[{"line_number":267,"context_line":""},{"line_number":268,"context_line":"unit and functional tests will be added to test the xml generation."},{"line_number":269,"context_line":"the cyborg job will be extended to create mdevs and bind arqs using"},{"line_number":270,"context_line":"the mtty/mdpy kernel modules."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Documentation Impact"},{"line_number":273,"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":1,"id":"c46ce5d4_3b1476ef","line":270,"updated":"2025-11-20 13:37:55.000000000","message":"Does it mean that the testing of this spec will depend on finishing the mtty testing support in https://review.opendev.org/q/topic:%22mtty_support%22 first?","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2aabea35f1ace9b66945af7f612afc44991f8262","unresolved":true,"context_lines":[{"line_number":267,"context_line":""},{"line_number":268,"context_line":"unit and functional tests will be added to test the xml generation."},{"line_number":269,"context_line":"the cyborg job will be extended to create mdevs and bind arqs using"},{"line_number":270,"context_line":"the mtty/mdpy kernel modules."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Documentation Impact"},{"line_number":273,"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":1,"id":"853cebd6_d85d875e","line":270,"in_reply_to":"5166d274_afcc04f9","updated":"2025-11-25 14:03:56.000000000","message":"sounds like a good plan.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":false,"context_lines":[{"line_number":267,"context_line":""},{"line_number":268,"context_line":"unit and functional tests will be added to test the xml generation."},{"line_number":269,"context_line":"the cyborg job will be extended to create mdevs and bind arqs using"},{"line_number":270,"context_line":"the mtty/mdpy kernel modules."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Documentation Impact"},{"line_number":273,"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":1,"id":"4dbe06d8_dd353b79","line":270,"in_reply_to":"853cebd6_d85d875e","updated":"2025-12-02 15:39:02.000000000","message":"Done","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c36506a5d035fad299cfbd88afd747adaa0eb8e5","unresolved":true,"context_lines":[{"line_number":267,"context_line":""},{"line_number":268,"context_line":"unit and functional tests will be added to test the xml generation."},{"line_number":269,"context_line":"the cyborg job will be extended to create mdevs and bind arqs using"},{"line_number":270,"context_line":"the mtty/mdpy kernel modules."},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Documentation Impact"},{"line_number":273,"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":1,"id":"5166d274_afcc04f9","line":270,"in_reply_to":"c46ce5d4_3b1476ef","updated":"2025-11-21 15:22:52.000000000","message":"yes and no.\n\nwe wont need to finish extending the nova mdev supprot to work with mtty, but i think we could/should to imporve the testing of the native supprot while we are workign in this area.\n\nwe have already merged the supprot for compliing the kernel module in the devstack plugin so my plan was ot make cybrog able to work with that by creating a generic_mdev driver that supprot it and any other device that support mdevs\n\nthat would be devleoped as part fo this work in cyborg and woudl use the mtty and/or mdpy module in the cyborg job to provide the \"real\" devices that we can pass to qemu.","commit_id":"7ee987570a378ab8ed96e33f46cf23aa8fa7a248"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"b92d3950f3c6275765ecf0db31b2628fc8ea7d6e","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fbd2f02f_85d99da6","line":58,"updated":"2025-12-02 14:22:36.000000000","message":"it also includes attach_handle_info, could you add an example?","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"57fe585de63ad08310d1ad5cbbb9a10f18da54d5","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"68d0ca55_2e2f00aa","line":58,"in_reply_to":"30f62a56_fff8e930","updated":"2025-12-03 15:05:14.000000000","message":"we cant retroactively do a microverion update.\n\nbut since 2023.1 is nolonger supproted and all supproted verson have this value we could use it.\n\ni put that doing the persistence as a streach goal to de risk the proposal by keeping it small i can include it but that increases the scope of work.","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"714a24c7_1dd04304","line":58,"in_reply_to":"68d0ca55_2e2f00aa","updated":"2025-12-04 17:18:50.000000000","message":"Acknowledged","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"8f9726797d93fbb641f711152c961d1d0a8e467e","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"30f62a56_fff8e930","line":58,"in_reply_to":"aa981b4b_459793a3","updated":"2025-12-03 13:00:26.000000000","message":"I am not certain the implementation plan should ignore attach_handle_info and rely on external installers. We should address that API microversion update and missing docs in Cyborg as of https://specs.openstack.org/openstack/cyborg-specs/specs/2023.1/implemented/vgpu-driver-proposal.html, as a dependency to this work","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aa981b4b_459793a3","line":58,"in_reply_to":"fbd2f02f_85d99da6","updated":"2025-12-02 15:39:02.000000000","message":"i coudl but im intentilly not because there isnt docuemtion for what shoudl be included \n\nif nova start depending on the ohter field and there semaitcs it from a hard api contract and im not conficed we shoudl depledn on those other field form cybrog at this point.","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"1c342fd31bb3704b926becae7d94c8d0e3dd0c7e","unresolved":true,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"  We will not use _create_mdev or the libvirt support for persistent"},{"line_number":110,"context_line":"  mdevs introduced in I7e1d10e66a260efd0a3f2d6522aeb246c7582178 as the"},{"line_number":111,"context_line":"  ARQ bindings do not contain the parent device or mdev type"},{"line_number":112,"context_line":"  information required to create a persistent mdev."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1b354db8_5e3d11a9","line":111,"updated":"2025-12-02 14:23:53.000000000","message":"it seems that it does contain that info, at least for Nvidia drivers as of \t\thttps://specs.openstack.org/openstack/cyborg-specs/specs/wallaby/approved/vgpu-driver-proposal.html","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"3a6cfc8e67eaeaa25fc94636d8569ad16afcf87f","unresolved":true,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"  We will not use _create_mdev or the libvirt support for persistent"},{"line_number":110,"context_line":"  mdevs introduced in I7e1d10e66a260efd0a3f2d6522aeb246c7582178 as the"},{"line_number":111,"context_line":"  ARQ bindings do not contain the parent device or mdev type"},{"line_number":112,"context_line":"  information required to create a persistent mdev."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4fdd9e9d_d6189104","line":111,"in_reply_to":"1b354db8_5e3d11a9","updated":"2025-12-02 14:26:14.000000000","message":"also the returning code https://opendev.org/openstack/cyborg/src/commit/4b34d897d206f30a5a0ac9a963b119242ded6488/cyborg/objects/arq.py#L63\n\nwe can omit required adjustments for this out of this spec, but we probably should enable devices persistence for this spec scope","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d06aaadba0757382767eb83199f112cdf7ed4d40","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"  We will not use _create_mdev or the libvirt support for persistent"},{"line_number":110,"context_line":"  mdevs introduced in I7e1d10e66a260efd0a3f2d6522aeb246c7582178 as the"},{"line_number":111,"context_line":"  ARQ bindings do not contain the parent device or mdev type"},{"line_number":112,"context_line":"  information required to create a persistent mdev."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"426f5bcc_9a4f7c3a","line":111,"in_reply_to":"4fdd9e9d_d6189104","updated":"2025-12-02 14:31:50.000000000","message":"ok I see you\u0027ve added that into stretched goals, thanks","commit_id":"2c0dc0db796a5b258693da77a7ae486453ce5361"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"},{"line_number":62,"context_line":"for the given mdev."}],"source_content_type":"text/x-rst","patch_set":3,"id":"bb730d87_790715ad","line":59,"updated":"2025-12-02 14:34:47.000000000","message":"that\u0027s the current support we have, right?","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"},{"line_number":62,"context_line":"for the given mdev."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5c21f882_b58350e2","line":59,"in_reply_to":"9e942552_9464aa6f","updated":"2025-12-04 17:18:50.000000000","message":"Acknowledged","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":56,"context_line":"    {"},{"line_number":57,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":58,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":59,"context_line":"    }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The libvirt driver will be extended to render the appropriate xml"},{"line_number":62,"context_line":"for the given mdev."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9e942552_9464aa6f","line":59,"in_reply_to":"bb730d87_790715ad","updated":"2025-12-02 15:39:02.000000000","message":"yes there is also an addtioanl filed called attach_handle_info\nwhich has \"asked_mdev\" and \"vgpu_mark\" filds which are undocumted\n\nthe attach_handle_info also has the pci address of the device that the mdev is allocated form.\n\nuntil we shure up the api contract aound those subfiled i do not want to depend on them yet","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"    def _get_guest_config(self, instance, network_info, image_meta,"},{"line_number":71,"context_line":"                          disk_info, rescue\u003dNone, block_device_info\u003dNone,"},{"line_number":72,"context_line":"                          context\u003dNone, mdevs\u003dNone, accel_info\u003dNone,"},{"line_number":73,"context_line":"                          share_info\u003dNone):"},{"line_number":74,"context_line":"      ..."},{"line_number":75,"context_line":"      if accel_info:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7bdfc209_dd8a91e8","line":72,"range":{"start_line":72,"start_character":52,"end_line":72,"end_character":67},"updated":"2025-12-02 14:34:47.000000000","message":"... and here we already get the ARQs list","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"    def _get_guest_config(self, instance, network_info, image_meta,"},{"line_number":71,"context_line":"                          disk_info, rescue\u003dNone, block_device_info\u003dNone,"},{"line_number":72,"context_line":"                          context\u003dNone, mdevs\u003dNone, accel_info\u003dNone,"},{"line_number":73,"context_line":"                          share_info\u003dNone):"},{"line_number":74,"context_line":"      ..."},{"line_number":75,"context_line":"      if accel_info:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d6f5cf24_9e04a4b7","line":72,"range":{"start_line":72,"start_character":39,"end_line":72,"end_character":51},"updated":"2025-12-02 14:34:47.000000000","message":"see we have the nova-supported mdevs list here...","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":90,"context_line":"                case \u0027PCI\u0027:"},{"line_number":91,"context_line":"                    pci_arq_list.append(arq)"},{"line_number":92,"context_line":"                case _:"},{"line_number":93,"context_line":"                    unsupported_types.add(other_type)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"        if unsupported_types:"},{"line_number":96,"context_line":"            LOG.info(\u0027Ignoring accelerator requests for instance %s. \u0027"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1bebfa2c_d2165ccf","line":93,"updated":"2025-12-02 14:34:47.000000000","message":"looks to me an implementation detail, we already have most of the code https://github.com/openstack/nova/blob/23b462d77df1a1d09c43d0918bca853ef3af1e3f/nova/virt/libvirt/driver.py#L7607-L7624","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":90,"context_line":"                case \u0027PCI\u0027:"},{"line_number":91,"context_line":"                    pci_arq_list.append(arq)"},{"line_number":92,"context_line":"                case _:"},{"line_number":93,"context_line":"                    unsupported_types.add(other_type)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"        if unsupported_types:"},{"line_number":96,"context_line":"            LOG.info(\u0027Ignoring accelerator requests for instance %s. \u0027"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dd0a6527_92686d80","line":93,"in_reply_to":"1bebfa2c_d2165ccf","updated":"2025-12-02 15:39:02.000000000","message":"yes this is the pusdo code for the change.\ni looked up the current code and used it as a baseline.\n\nthis si bsiclly just demonstrating that thsi si a pretty targeted chagne.\n\njust to supproting mdevs form the arqs instead of the current mdev list","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":90,"context_line":"                case \u0027PCI\u0027:"},{"line_number":91,"context_line":"                    pci_arq_list.append(arq)"},{"line_number":92,"context_line":"                case _:"},{"line_number":93,"context_line":"                    unsupported_types.add(other_type)"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"        if unsupported_types:"},{"line_number":96,"context_line":"            LOG.info(\u0027Ignoring accelerator requests for instance %s. \u0027"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7e923db6_b6cb6c4d","line":93,"in_reply_to":"dd0a6527_92686d80","updated":"2025-12-04 17:18:50.000000000","message":"Acknowledged","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":99,"context_line":"                      instance.uuid, unsupported_types)"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"        if mdev_arq_list:"},{"line_number":102,"context_line":"            self. _guest_add_mdevs(guest, mdev_arq_list)"},{"line_number":103,"context_line":"        if pci_arq_list:"},{"line_number":104,"context_line":"            self._guest_add_accel_pci_devices(guest, pci_arq_list)"},{"line_number":105,"context_line":"        ..."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fdf87fef_79ec2fd1","line":102,"updated":"2025-12-02 14:34:47.000000000","message":"... but here we could return some exception if the operator misconfigured nova.conf and wanted to have both the nova mdevs and the cyborg ones","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":99,"context_line":"                      instance.uuid, unsupported_types)"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"        if mdev_arq_list:"},{"line_number":102,"context_line":"            self. _guest_add_mdevs(guest, mdev_arq_list)"},{"line_number":103,"context_line":"        if pci_arq_list:"},{"line_number":104,"context_line":"            self._guest_add_accel_pci_devices(guest, pci_arq_list)"},{"line_number":105,"context_line":"        ..."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e211304b_1617a402","line":102,"in_reply_to":"0696aeb2_0e42b625","updated":"2025-12-04 17:18:50.000000000","message":"im going to put this out of scope of the spec but ill se if we can add this validation during the implementation.\n\ni think it shoudl be possible by comparing the PCI address from the attach_handle_info with the set of device nova believes it should managed but ill need to prototype that.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":99,"context_line":"                      instance.uuid, unsupported_types)"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"        if mdev_arq_list:"},{"line_number":102,"context_line":"            self. _guest_add_mdevs(guest, mdev_arq_list)"},{"line_number":103,"context_line":"        if pci_arq_list:"},{"line_number":104,"context_line":"            self._guest_add_accel_pci_devices(guest, pci_arq_list)"},{"line_number":105,"context_line":"        ..."}],"source_content_type":"text/x-rst","patch_set":3,"id":"0696aeb2_0e42b625","line":102,"in_reply_to":"fdf87fef_79ec2fd1","updated":"2025-12-02 15:39:02.000000000","message":"we coudl try and do validation yes to see if nova thinks it shoudl be managing that mdev here or perhaps earlier\n\nwe dont currently do that validation for cyborg manage pci device which is why i didnt include tat in the minium requirements for the spec.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bda9976997ed8ebe7c9e9ffa8f52ee461198b972","unresolved":true,"context_lines":[{"line_number":114,"context_line":"  but never documented this change."},{"line_number":115,"context_line":"  Nova could use this information to create a persistent mdev."},{"line_number":116,"context_line":"  This is initially out of scope for this spec but may be added"},{"line_number":117,"context_line":"  as a strech goal upon completion of this spec."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"},{"line_number":120,"context_line":"  host mdev across reboots with a stable UUID. This is required to ensure that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"aa683a0b_205cbe9a","line":117,"updated":"2025-12-02 14:16:42.000000000","message":"note i dont want to depend on this as there is no documeation of those filed in the nova or cybrog spec that they were propotably added for or in the api ref.\n\nso before nova depend on this info for mdevs i want to adress that on the cybrog side.\n\nin the future we can either have nova use the persistent mdev feature with this info to Alway persist the mdev or i will propose adding a flag to the arq_info to request nova to persist the mdevs.\n\nthey cyborg side to do this persitence was never complete\n\nhttps://review.opendev.org/c/openstack/cyborg/+/815935/5\n\nso we have to assume this si currently done out of tree by the installer.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":114,"context_line":"  but never documented this change."},{"line_number":115,"context_line":"  Nova could use this information to create a persistent mdev."},{"line_number":116,"context_line":"  This is initially out of scope for this spec but may be added"},{"line_number":117,"context_line":"  as a strech goal upon completion of this spec."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"},{"line_number":120,"context_line":"  host mdev across reboots with a stable UUID. This is required to ensure that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"711361d3_f5eadddb","line":117,"in_reply_to":"675c231c_a72e5695","updated":"2025-12-02 15:39:02.000000000","message":"yes and until we actully can supprot live migration with cybrog we will have several other gaps. i woudl expect to adress those in future release assuming we proceed with this.\n\nim trying to define the MVP to enable use to supprot cybrog management of mdevs.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  but never documented this change."},{"line_number":115,"context_line":"  Nova could use this information to create a persistent mdev."},{"line_number":116,"context_line":"  This is initially out of scope for this spec but may be added"},{"line_number":117,"context_line":"  as a strech goal upon completion of this spec."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"},{"line_number":120,"context_line":"  host mdev across reboots with a stable UUID. This is required to ensure that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2e0f37ca_f987ab8b","line":117,"in_reply_to":"711361d3_f5eadddb","updated":"2025-12-04 17:18:50.000000000","message":"i have pulled this into scope based on bogdando\u0027s input\n\nwe will still have a partiy gap in live migration but that could be adressed in a future release.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":114,"context_line":"  but never documented this change."},{"line_number":115,"context_line":"  Nova could use this information to create a persistent mdev."},{"line_number":116,"context_line":"  This is initially out of scope for this spec but may be added"},{"line_number":117,"context_line":"  as a strech goal upon completion of this spec."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  Cyborg and the installer are responsible for ensuring the persistence of the"},{"line_number":120,"context_line":"  host mdev across reboots with a stable UUID. This is required to ensure that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"675c231c_a72e5695","line":117,"in_reply_to":"aa683a0b_205cbe9a","updated":"2025-12-02 14:34:47.000000000","message":"this just means that we\u0027ll continue to have a feature gap between nova and cyborg vGPU support but I\u0027m OK, we can just provide a documentation about it.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"To prevent collisions between nova and cyborg managed mdevs, we will complete"},{"line_number":130,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":131,"context_line":"[3]_. This entails:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Tagging every ResourceProvider that Nova creates with a ``OWNER_NOVA`` trait."},{"line_number":134,"context_line":"* Adding a new compute service version for this functionality."}],"source_content_type":"text/x-rst","patch_set":3,"id":"91456fe1_5977a6ca","line":131,"updated":"2025-12-02 14:34:47.000000000","message":"so this spec needs to be depended on https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html\n\ndo you have another spec for it ?","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"To prevent collisions between nova and cyborg managed mdevs, we will complete"},{"line_number":130,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":131,"context_line":"[3]_. This entails:"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"* Tagging every ResourceProvider that Nova creates with a ``OWNER_NOVA`` trait."},{"line_number":134,"context_line":"* Adding a new compute service version for this functionality."}],"source_content_type":"text/x-rst","patch_set":3,"id":"f04cf873_8b535c6c","line":131,"in_reply_to":"91456fe1_5977a6ca","updated":"2025-12-02 15:39:02.000000000","message":"no its not dependent we impletned most of that spec already.\n\nwe previously created the standard owner traits and cyborg implemented there part fo the spec in wallaby or yoga ensurign there resouce provider have the owner trait.\n\ni do not belive we shoud repopsoe taht spec seprealty which is why i inlined the remaining work here.  this spec is covering completing the remaider of owner-nova-trait-usage in its scope. Thats why i stated ` we will complete\nthe remaining work of the ``owner-nova-trait-usage`` spec`\n\ngibi asked the saem question in a previous revisions","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fd3c9d21514217f6b3408dc5035473b28e47cba5","unresolved":true,"context_lines":[{"line_number":206,"context_line":"To upgrade from a nova-owned vGPU to a cyborg-owned vGPU,"},{"line_number":207,"context_line":"resize your instance directly from a flavor with a nova-managed GPU"},{"line_number":208,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg-managed MDEVs"},{"line_number":209,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Implementation"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"70dd3c02_e112474e","line":209,"updated":"2025-12-02 14:34:47.000000000","message":"but you would need to have different hosts (or rather specific GPUs) using either nova mdevs or cyborg ones, right?","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c09e0e912677c9df5d170e4f117c31543ec294e3","unresolved":false,"context_lines":[{"line_number":206,"context_line":"To upgrade from a nova-owned vGPU to a cyborg-owned vGPU,"},{"line_number":207,"context_line":"resize your instance directly from a flavor with a nova-managed GPU"},{"line_number":208,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg-managed MDEVs"},{"line_number":209,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Implementation"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2e39e721_308638b9","line":209,"in_reply_to":"4dc05f5d_2ad42aea","updated":"2025-12-04 17:18:50.000000000","message":"i have expanded on this to make it clear that there is no upgrade impact.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c9a5f1712e812c916deaca82ff0e0772bf52d79e","unresolved":true,"context_lines":[{"line_number":206,"context_line":"To upgrade from a nova-owned vGPU to a cyborg-owned vGPU,"},{"line_number":207,"context_line":"resize your instance directly from a flavor with a nova-managed GPU"},{"line_number":208,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg-managed MDEVs"},{"line_number":209,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Implementation"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a5b1c0fa_9b0606aa","line":209,"in_reply_to":"70dd3c02_e112474e","updated":"2025-12-02 14:45:23.000000000","message":"this also seems missing a note about removing the migrated device from nova config","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e6042674caebaeb02d88b51c6a821bff9e0c7db","unresolved":true,"context_lines":[{"line_number":206,"context_line":"To upgrade from a nova-owned vGPU to a cyborg-owned vGPU,"},{"line_number":207,"context_line":"resize your instance directly from a flavor with a nova-managed GPU"},{"line_number":208,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg-managed MDEVs"},{"line_number":209,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Implementation"},{"line_number":212,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4dc05f5d_2ad42aea","line":209,"in_reply_to":"a5b1c0fa_9b0606aa","updated":"2025-12-02 15:39:02.000000000","message":"resize is a move operation so yes you need either a free cyborg managed gpu on the same or a diffent host.\n\nits the same as changign form mdev managed gpus to the vfio-variant drivers\n\nthe only way to change is to do so via a resize.\n\n\ni did nto add a note about remvoe the device form novs config because you cant od that until you remove all worklaods so that woudl be incorrect.","commit_id":"21c9322bc4e09c41190a931707109cd3e340f6c9"}],"specs/2026.2/approved/cyborg-vgpu-support.rst":[{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"ca8bb953faff61d0d20af41a05801ad64ba69e56","unresolved":true,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"This spec proposes to complete the support for Cyborg managed MDEVs in Nova."},{"line_number":43,"context_line":"In the Wallaby release, we have completed the support for Cyborg managed vGPUs"},{"line_number":44,"context_line":"in cyborg however the nova libvirt driver still does not support composing"},{"line_number":45,"context_line":"cyborg owned MDEV into domain XML."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Cyborg defines a data model in ARQ to track a cyborg owned MDEV."}],"source_content_type":"text/x-rst","patch_set":6,"id":"2c783ff8_b8786ed7","line":44,"updated":"2026-03-27 13:41:24.000000000","message":"we should build this spec based on the future nova state where this missing functionality will be addressed","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9e7862b68a6be65874b6eb500893f26f1de25406","unresolved":true,"context_lines":[{"line_number":100,"context_line":"                    unsupported_types.add(other_type)"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"        if unsupported_types:"},{"line_number":103,"context_line":"            LOG.info(\u0027Ignoring accelerator requests for instance %s. \u0027"},{"line_number":104,"context_line":"                      \u0027Supported Attach handle types: PCI, MDEV. \u0027"},{"line_number":105,"context_line":"                      \u0027But got these unsupported types: %s.\u0027,"},{"line_number":106,"context_line":"                      instance.uuid, unsupported_types)"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ad20e935_44a8eca1","line":103,"updated":"2026-04-20 09:51:09.000000000","message":"Is LOG.info the right level when unsupported attach-handle types are ignored, or would warning make operator misconfiguration easier to spot?","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9e7862b68a6be65874b6eb500893f26f1de25406","unresolved":true,"context_lines":[{"line_number":106,"context_line":"                      instance.uuid, unsupported_types)"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"        if mdev_arq_list:"},{"line_number":109,"context_line":"            self. _guest_add_mdevs(guest, mdev_arq_list)"},{"line_number":110,"context_line":"        if pci_arq_list:"},{"line_number":111,"context_line":"            self._guest_add_accel_pci_devices(guest, pci_arq_list)"},{"line_number":112,"context_line":"        ..."}],"source_content_type":"text/x-rst","patch_set":6,"id":"10dc4274_a768aa8a","line":109,"updated":"2026-04-20 09:51:09.000000000","message":"Typo: stray space in `self. _guest_add_mdevs` — should be `self._guest_add_mdevs`.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"2867899633a3667e3d5a479851ef3705e94f26ff","unresolved":true,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  https://github.com/openstack/cyborg/commit/79e1928554b6a03dd481ebefd3f550adeb457aed"},{"line_number":120,"context_line":"  added the parent device and mdev type information to the ARQ bindings."},{"line_number":121,"context_line":"  Nova will use this information to create a persistent mdev."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"To prevent collisions between nova and cyborg managed mdevs, we will complete"}],"source_content_type":"text/x-rst","patch_set":6,"id":"359105ea_a07127c1","line":121,"updated":"2026-03-27 13:49:29.000000000","message":"This breaks the Cyborg\u0027s spec [0] assumed operational model. In case both operational models for Cyborg are valid, please specify how exactly Nova would signal to Cyborg that the device is now in use and shouldn\u0027t be touched by it, or how it coordinates the state transition, other than by consuming the allocation in Placement\n    \n[0] https://review.opendev.org/c/openstack/cyborg-specs/+/982276","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"512a9444b019f8c039b004799a64ffb7d358dfea","unresolved":true,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  https://github.com/openstack/cyborg/commit/79e1928554b6a03dd481ebefd3f550adeb457aed"},{"line_number":120,"context_line":"  added the parent device and mdev type information to the ARQ bindings."},{"line_number":121,"context_line":"  Nova will use this information to create a persistent mdev."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"To prevent collisions between nova and cyborg managed mdevs, we will complete"}],"source_content_type":"text/x-rst","patch_set":6,"id":"edb18898_83b9e72a","line":121,"in_reply_to":"359105ea_a07127c1","updated":"2026-03-27 16:35:44.000000000","message":"that is singele by the exsigt fo the bound ARQ.\ncybrog shoudl not ever direcly create mdevs but i have nothad time to look at the cybrog spec.\n\nthe mdev creation will entirly be driven by nova via libvirt persitent mdev feature\nthe enumariotn of how many can be creted ectra weill be do done on the cyborg side.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d6cba5bdbcc4fe2c13bd99471ff726015fa95bf4","unresolved":false,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"  https://github.com/openstack/cyborg/commit/79e1928554b6a03dd481ebefd3f550adeb457aed"},{"line_number":120,"context_line":"  added the parent device and mdev type information to the ARQ bindings."},{"line_number":121,"context_line":"  Nova will use this information to create a persistent mdev."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"To prevent collisions between nova and cyborg managed mdevs, we will complete"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5ba6ed16_ddcf70b4","line":121,"in_reply_to":"edb18898_83b9e72a","updated":"2026-03-30 09:30:09.000000000","message":"Done","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9e7862b68a6be65874b6eb500893f26f1de25406","unresolved":true,"context_lines":[{"line_number":204,"context_line":"Upgrade impact"},{"line_number":205,"context_line":"--------------"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"None"},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"A new compute service version will be introduced to advertise"},{"line_number":210,"context_line":"support for reporting the nova owner trait. A scheduler pre-filter"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9b2385c6_103d986a","line":207,"updated":"2026-04-20 09:51:09.000000000","message":"This says \"None\" but the following paragraphs describe real upgrade-visible behavior (compute service version, scheduler pre-filter, migration path). Consider replacing \"None\" with a substantive summary or restructuring the section.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"9e7862b68a6be65874b6eb500893f26f1de25406","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Dependencies"},{"line_number":251,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"None"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Testing"},{"line_number":256,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"32eb7c66_015dd24a","line":253,"updated":"2026-04-20 09:51:09.000000000","message":"Testing calls out new Cyborg generic mdev driver work and mtty/mdpy — consider an explicit cross-project dependency (Cyborg spec/release) here so Nova is not merged without a defined pairing.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"ca8bb953faff61d0d20af41a05801ad64ba69e56","unresolved":true,"context_lines":[{"line_number":256,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"Unit and functional tests will be added to test the XML generation."},{"line_number":259,"context_line":"The Cyborg job will be extended to create mdevs and bind ARQs using"},{"line_number":260,"context_line":"the mtty/mdpy kernel modules."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"As part of this work a new generic mdev driver will be created for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"73a2829a_5a217251","line":259,"updated":"2026-03-27 13:41:24.000000000","message":"this seems inconsistent with the above\nCyborg is expected to be asked to create the mdev. Nova plans to create the mdev itself using information provided by Cyborg.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"512a9444b019f8c039b004799a64ffb7d358dfea","unresolved":true,"context_lines":[{"line_number":256,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"Unit and functional tests will be added to test the XML generation."},{"line_number":259,"context_line":"The Cyborg job will be extended to create mdevs and bind ARQs using"},{"line_number":260,"context_line":"the mtty/mdpy kernel modules."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"As part of this work a new generic mdev driver will be created for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"e5279e35_f76da153","line":259,"in_reply_to":"73a2829a_5a217251","updated":"2026-03-27 16:35:44.000000000","message":"no the cyborg job will create the mdev capable device by compiling and loading the kernel moduels and configuring cyborg to enmerate and reprot them to placemnt\n\nnova will do the actual mdev creation in responce to cyborg populatin the attachment handel with the required infor such as the uuid to use, the partent device and the mdev type.\n\nnova takes that info and passes it ot libvirt to create the perseited mdev via libvirt and mdevctl\n\ncyborg is not allowed to talks to libvirt directly.\n\nthis statement does not state taht cyborg will do that\nit state the job will be extended to do this it not saying hwo it will be done jsut that it will be doen","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"4c995e0f05bd12f4bfb763b2afddb9a12a0e3d2e","unresolved":false,"context_lines":[{"line_number":256,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"Unit and functional tests will be added to test the XML generation."},{"line_number":259,"context_line":"The Cyborg job will be extended to create mdevs and bind ARQs using"},{"line_number":260,"context_line":"the mtty/mdpy kernel modules."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"As part of this work a new generic mdev driver will be created for"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3193c2d6_67cde0a1","line":259,"in_reply_to":"e5279e35_f76da153","updated":"2026-03-30 09:29:39.000000000","message":"Done","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"}]}