)]}'
{"/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"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f465e89fb2b240cc2bc459ec68a3a6c02bf580c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"e7ef3a33_182830f9","updated":"2026-05-18 17:11:54.000000000","message":"i think this is mostly good to go as is i will loop back to it again after i review the cyborg spec but the cybrog side is not blockign since the cybrog fuctionaltiy technially already extis.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"ce37d0f160b34bf2ad02c23c516bf0d73f539cb3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"31f4e5bf_50c405e7","in_reply_to":"11c18836_2773a880","updated":"2026-05-19 10:34:05.000000000","message":"(1) Done, I\u0027ve addes some more context to the `None`\n(2) I think this is already covered in the Upgrade impact section. Computes that have not been upgraded will not be able to use mdevs discovered by cyborg and once upgraded the traits will ensure there is no double booking\n(3) when an instance is deleted, the mdev will be removed by libvirt. This spec should not introduce any change to the ARQ cycle other that the domain xml already covered in the spec\n(4) looks like I can\u0027t edit the existing blueprint, I\u0027ll either create a new one or ask to be set as the assignee to be able to reuse it","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b7941de15f7503ba4f678549c48b9da4e4c673e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"0b5093ca_1a676432","updated":"2026-05-19 11:15:04.000000000","message":"+2 because im not aware of any spefcif openquestions or objection to the proposal\nif there is specific feedback or clarity needed ill revert while the dicussion happens.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"ebf104021a356e75ae83c9cf205d12d75302b916","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"d5f4d08b_36a0ddc6","updated":"2026-05-21 15:12:55.000000000","message":"Thanks for the spec. The overall approach makes sense but I have a few concerns, mostly around clarity and comprehension, that I think should be addressed before this can move forward. See inline comments for details.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"292825d82fdf1a19cf6776b6475f93a1e4f52468","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"32c2f31e_4f59228a","updated":"2026-05-21 14:35:53.000000000","message":"pretty close to +2 but I have a concern","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"cf0b635cfbef329c2f1bc536c9f9a8f4598b7ca0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"fe16c9be_f76caae3","updated":"2026-05-27 16:38:45.000000000","message":"-1 for signaling my answers.","commit_id":"50bc06f6d582be13b16e750de68a63c4c4e1246e"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"36bd30fd_f8f83506","updated":"2026-05-28 14:09:16.000000000","message":"-1 for the upgrade impact only, I guess we definitely need to have Cyborg supporting resizes before we accept this spec\nDo we have a dependent effort for this ?","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"2a4776fad34a98a2e05fc3901ac7a3567005fbe7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"96b38714_860bb8b9","updated":"2026-05-28 13:14:07.000000000","message":"Thanks Joan for addressing the comments. I am happy with this spec overall.\n\nRegarding the misconfiguration detection (device managed by both Nova\nand Cyborg), I still think a check would be valuable but I will leave\nit to the cores to decide. I am in favor of adding it but it should\nnot block this spec.\n\n+1 from me.","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4bfa9b0d9aa5726d0a17de59c34fd7c6d711877a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":9,"id":"6775208e_e33a522b","in_reply_to":"36bd30fd_f8f83506","updated":"2026-05-29 15:42:39.000000000","message":"we agreed in the ptg to not require that.\nso not it shoudl not be a prerequisite and we agreed to explore it this cycle and proposes resize supprort 2027.1 not 2026.2","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4bfa9b0d9aa5726d0a17de59c34fd7c6d711877a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"5a313107_3559ef8d","updated":"2026-05-29 15:42:39.000000000","message":"im still ok withthe extra detail added.","commit_id":"1bc519938bcc00cc0f0ac761837a0a781a8b2e5a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1b54c55b9bdaa0b5c51bc91148767850640aaa4f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"393f5262_1eec8c77","updated":"2026-06-01 08:11:31.000000000","message":"thanks for the work 😉","commit_id":"1bc519938bcc00cc0f0ac761837a0a781a8b2e5a"}],"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":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f465e89fb2b240cc2bc459ec68a3a6c02bf580c","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":"f49bbcc1_a6257d52","line":44,"in_reply_to":"2c783ff8_b8786ed7","updated":"2026-05-18 17:11:54.000000000","message":"no the spec espcailly in this section shoudl be written to describ how we will change the code form the current state to enable the new fucntionality.\n\nso this is fine as is its providing the context that this spcific impletaiotn detail (libvirt domain xml generaion) does not supprot composing mdevs form cybrog\n\nand then the next paragrapsh descibe how that wille work and the change requried to nova to wire it up.\n\nthis is how we write specs\n\nthe Problem Statement expalins what we want to do\nthe usecasess expalin why\n\nthe propposed changes section descbie how we are going to evovle the currnt state to do that.","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":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f465e89fb2b240cc2bc459ec68a3a6c02bf580c","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":"ab30815f_229172cc","line":103,"in_reply_to":"ad20e935_44a8eca1","updated":"2026-05-18 17:11:54.000000000","message":"so warnign should only be used if there is somethign actionalable that an operator can do to correct it via chaging config options ectra.\n\nin this case the cant fix it so info is fine\n\nthis is the exsting code by the way so the spec is not really suggeting changing the level jsut add MDEV ot the list of supproted types.\n\nwe couold chage it to LOG.error LOG.debug or leave it at LOG.info but warning woudl nto be correct.","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":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"ce37d0f160b34bf2ad02c23c516bf0d73f539cb3","unresolved":false,"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":"28768d61_04ba37b0","line":109,"in_reply_to":"10dc4274_a768aa8a","updated":"2026-05-19 10:34:05.000000000","message":"Done","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":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f1634549210db7dcef5f2f281f981c5d95b044cc","unresolved":false,"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":"66a1934a_b707f827","line":207,"in_reply_to":"7526fb34_219cfdc9","updated":"2026-05-19 11:14:03.000000000","message":"Acknowledged","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"ce37d0f160b34bf2ad02c23c516bf0d73f539cb3","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":"7526fb34_219cfdc9","line":207,"in_reply_to":"9b2385c6_103d986a","updated":"2026-05-19 10:34:05.000000000","message":"I\u0027ve added further context on the `None`","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f465e89fb2b240cc2bc459ec68a3a6c02bf580c","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":"5733ef7e_646afbea","line":207,"in_reply_to":"9b2385c6_103d986a","updated":"2026-05-18 17:11:54.000000000","message":"None is correct\n\nthere is no impact to an operator that is upgranding until the opt into the new fuctuionatliy.\n\nso for the purpos of this section None is correct.\n\nthe paragras that follow explain the context of why its none.\n\nwe are adding a comptue service version and only requeting the owner trait when all compute serviceices are upgraded.\n\nmigratign form nova manged to cyborg mangaed requried freeing capastity, removing mangedment of device from nova, adding themn to cybrog to manage and creating new flavor to use the cyborg magned devices.\n\nnoen of this is in the scope fo an upraged and ai a purly post upgrade activtiy.","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":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"ce37d0f160b34bf2ad02c23c516bf0d73f539cb3","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":"b30e7e1d_82424a9e","line":253,"in_reply_to":"32eb7c66_015dd24a","updated":"2026-05-19 10:34:05.000000000","message":"good point, done","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3f465e89fb2b240cc2bc459ec68a3a6c02bf580c","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":"60c529fa_cfb15398","line":253,"in_reply_to":"32eb7c66_015dd24a","updated":"2026-05-18 17:11:54.000000000","message":"we could add a link to the cyborg spec here i guess but its really a soft depency\n\nthe organal supprot for nvida vgpus via mdevs merged in cybrog a long time ago\nthe main scope fo the cybrog spec is the intorduction of a vendor neutral generic mdev driver that will also work with the fake sample kernel module to enabel end ot end testing in ci.\n\nif we did not implement that the nova feature would not be blocked hence this si not a hard dependency.\n\nas an aside this reads as an ai comment and you shoudl disclose that if it is.","commit_id":"2180b75b2bf394e1d1bc7a198ce74f5e909f90a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f1634549210db7dcef5f2f281f981c5d95b044cc","unresolved":false,"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":"f111f829_9806d044","line":253,"in_reply_to":"b30e7e1d_82424a9e","updated":"2026-05-19 11:14:03.000000000","message":"Done","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"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"ebf104021a356e75ae83c9cf205d12d75302b916","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"e6ccf78a_e7a4a643","line":41,"updated":"2026-05-21 15:12:55.000000000","message":"The lifecycle responsibilities between Nova and Cyborg for mdev\nmanagement are not clearly laid out in the spec. From reading the\npseudo-code, the Note section, and the various comment threads,\nI can reconstruct the following sequence:\n\n1. Cyborg discovers physical GPUs, inventories capabilities,\nreports to Placement\n\n2. Nova scheduler selects a host via Placement, Cyborg returns a bound ARQ with attach_handle_type\u003dMDEV, a UUID, and attach_handle_info (mdev type, parent PCI address)\n\n3. Nova compute (libvirt) calls _create_mdev using the ARQ info to create a persistent mdev, then composes the domain XML\n\nBut this flow is never described as a coherent sequence in the spec\nitself. You have to piece it together from scattered sections and\nGerrit comments.\nA dedicated paragraph walking through the end-to-end\nlifecycle (from device discovery to running VM) would greatly help\nreviewers and future implementers understand who does what and when.\n\nIn particular, it\u0027s unclear from the spec alone who is responsible for\nassigning the vGPU type. The answer seems to be that Cyborg provides\nit via attach_handle_info.asked_type, and Nova just consumes it when\ncalling _create_mdev. But the spec doesn\u0027t state this explicitly. You\nhave to look at the ARQ example and infer it.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"fdba86816e89ed565605499e9c8b0abc83d0d90d","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a3dd9570_b9bf6474","line":41,"in_reply_to":"1647152e_bdba43cd","updated":"2026-05-27 11:19:58.000000000","message":"thanks, I\u0027ve added a bit more info around the ARQ and the attache handle info which hopefully will clarify the mechanics.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"2a4776fad34a98a2e05fc3901ac7a3567005fbe7","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a2c3f475_8f7f1282","line":41,"in_reply_to":"3efc14ac_5f3cff95","updated":"2026-05-28 13:14:07.000000000","message":"Acknowledged","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"cf0b635cfbef329c2f1bc536c9f9a8f4598b7ca0","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f73528a1_e494fd4f","line":41,"in_reply_to":"a3dd9570_b9bf6474","updated":"2026-05-27 16:38:45.000000000","message":"Thanks for adding details about the attach_handle_info fields. However what I was\nlooking for is a step-by-step workflow describing who does what and when across the\nfull lifecycle. Something like:\n\n1. Operator creates a device profile in Cyborg for the GPU and a Nova flavor\nreferencing it (accel:device_profile\u003d...)\n2. Cyborg discovers the physical GPU, enumerates mdev capabilities, and reports\ninventory to Placement with OWNER_CYBORG trait\n3. User requests an instance with the Cyborg-aware flavor\n4. Nova scheduler queries Placement, which selects a host with matching inventory\nand traits\n5. Cyborg binds the ARQ and returns an attach_handle with type\u003dMDEV, a UUID, and\nattach_handle_info containing the parent PCI address and mdev type (asked_type)\n6. Nova compute (libvirt) calls _create_mdev with the parent device and mdev type\nfrom attach_handle_info and the UUID from attach_handle_uuid, creating a persistent\nmdev with the correct vGPU type in a single operation\n7. Nova composes the domain XML including the mdev reference and boots the VM\n8. On instance delete, Nova/libvirt removes the mdev and Cyborg reconciles its ARQ\nstate\n\nThis would help me review the spec, but if the other reviewers feel this is unnecessary I am fine dropping this ask","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f93df97a543ef551b699774698e8dbf1c31de9c5","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1647152e_bdba43cd","line":41,"in_reply_to":"e6ccf78a_e7a4a643","updated":"2026-05-26 14:27:33.000000000","message":"this is valid to add and may hlep understadnign althou the mechanics of this are unchanged by this spec form the current pci flow.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7afc7facfa13cef6c7f38d59414f97d14b686084","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"},{"line_number":40,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"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"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3efc14ac_5f3cff95","line":41,"in_reply_to":"f73528a1_e494fd4f","updated":"2026-05-28 11:06:38.000000000","message":"thanks for the detailed comment uggla, your description of the workflow seems correct. I\u0027ve added a slightly modified version of what you wrote to the spec, emphasizing that the spec does not propose to modify this process for clarity","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"ebf104021a356e75ae83c9cf205d12d75302b916","unresolved":true,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"e1aebcb0_48cf1a78","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"updated":"2026-05-21 15:12:55.000000000","message":"The spec acknowledges in \"Other deployer impact\" that configuring the\nsame device in both Nova and Cyborg can cause scheduling conflicts,\nbut defers any detection or mitigation as out of scope.\n\nI think we should do better than a documentation warning\nhere. At minimum, Nova should LOG.warning at build time when it\ndetects that a device referenced in a Cyborg ARQ is also listed in\nits own mdev configuration. Silent misconfiguration is an operator nightmare\nto debug.\n\nBeyond logging, the spec should define the expected behavior when this\nconflict is detected: should Nova refuse the build with an explicit\nerror? Ignore its own config in favor of Cyborg?\nThe current spec leaves this entirely undefined, which means the behavior\nwill be whatever the implementation happens to produce.\n\n\nI understand this validation doesn\u0027t exist today for Cyborg-managed PCI\ndevices either, but adding a new device type (MDEV) that explicitly\noverlaps with an existing Nova-managed feature makes this a more\nlikely misconfiguration scenario than PCI.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"7afc7facfa13cef6c7f38d59414f97d14b686084","unresolved":true,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"85b77be1_5a608249","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"in_reply_to":"7307be0b_7eb7475b","updated":"2026-05-28 11:06:38.000000000","message":"I agree that the complexity of the validation is not the problem. I\u0027ve added a brief description of pci address configuration validation with a warning. IMO this is a reasonable ask, but I\u0027ll let the Nova cores decide if it should be part of the service or not.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":false,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"c66013d9_5cbf787d","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"in_reply_to":"85b77be1_5a608249","updated":"2026-05-28 14:09:16.000000000","message":"I think that L166, we now have a check for this, so resolving this comment. Reopen it if you think I\u0027m wrong.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"36fba9b166a695e41ab18cb533e8895073148299","unresolved":true,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dba24461_7587adc4","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"in_reply_to":"c808b695_0c223578","updated":"2026-05-21 20:30:55.000000000","message":"i disagree that nova eshoul have any logic to detect this and loging a warning is perhaps even out of scope for what nova shoudl do.\n\nthe only time it would be valid for nova ot do any validation is if cybrog bind an arq to a device tgh at nova thinks it shoudl be managing.\n\nbut that is striat up operator effor and not somthign that nova shoudl need to be extedned to do.\n\nthat is crossign the domain bondaires betwen the nova and cybrog service.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"cf0b635cfbef329c2f1bc536c9f9a8f4598b7ca0","unresolved":true,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"7307be0b_7eb7475b","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"in_reply_to":"dba24461_7587adc4","updated":"2026-05-27 16:38:45.000000000","message":"Right, that is exactly the scenario I am describing. When Cyborg binds an ARQ to a\ndevice that Nova also thinks it should be managing, Nova is the one that has the\ninformation to detect it at build time.\n\nOf course it is an operator error, but it is Nova\u0027s responsibility to signal it\nrather than letting it fail silently with confusing symptoms. Leaving this\nundetected does not seem like a good idea for our future selves.\n\nAlso, I may be wrong, but adding a check comparing the PCI address from the ARQ\nattach_handle_info against Nova\u0027s configured mdev devices with a LOG.warning does\nnot seem overly complex. But maybe there is something I am not seeing here.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c4f6d9776b719f893d26092c9280b74751e4fc61","unresolved":true,"context_lines":[{"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"},{"line_number":125,"context_line":"the remaining work of the ``owner-nova-trait-usage`` spec"},{"line_number":126,"context_line":"[3]_. This entails:"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"c808b695_0c223578","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":59},"in_reply_to":"e1aebcb0_48cf1a78","updated":"2026-05-21 15:18:49.000000000","message":"I agree that validation is needed, we had discussed that in the 1st revision of this patch set.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"ebf104021a356e75ae83c9cf205d12d75302b916","unresolved":true,"context_lines":[{"line_number":135,"context_line":"options."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"28f8cd3a_085fc808","line":138,"updated":"2026-05-21 15:12:55.000000000","message":"The proposed change section should mention that Cyborg mdev management\nis activated through a flavor with a device profile. A short example\nshowing both the Cyborg device profile creation and the Nova flavor\nconfiguration would help understanding.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":false,"context_lines":[{"line_number":135,"context_line":"options."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6379f535_ed2ddae2","line":138,"in_reply_to":"24451e10_c6e18903","updated":"2026-05-28 14:09:16.000000000","message":"I see in L51 that this spec explains about the device profile, so I guess we can resolve this comment.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d25fad0c2f1c305c92a3e6268525c8e196f92a4b","unresolved":true,"context_lines":[{"line_number":135,"context_line":"options."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"24451e10_c6e18903","line":138,"in_reply_to":"28f8cd3a_085fc808","updated":"2026-05-21 20:27:45.000000000","message":"that how all cybrog interaction happens\nthere is nothing mdev sepcifci about that.\n\nthis would not be a change in the interaction between nova and cybrog.\nand it will continue to work as descirbed in https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/nova-cyborg-interaction.html\n\nwe could include that in the reffences but that is not part of the proposed changes of this spec.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"ebf104021a356e75ae83c9cf205d12d75302b916","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"cffbd7d0_d8b2130b","line":139,"updated":"2026-05-21 15:12:55.000000000","message":"The spec doesn\u0027t address how vGPU counting and inventory limits\nare handled in the Cyborg-managed model. With Nova-managed vGPUs,\noperators use the max_instances parameter to control how many vGPU\ninstances can be created per physical GPU, and there is a known bug\naround this counting logic (LP#2041519).\n\nWhen Cyborg takes over mdev management, who is responsible for\nenforcing these limits? The answer is presumably Cyborg, which\nreports inventory to Placement, and Placement enforces the allocation\nlimits. But this should be stated explicitly in the spec, along with a\nclarification that Nova\u0027s max_instances (vGPU sections) configuration \ndoes not apply to Cyborg-managed mdevs.\n\nIf there is equivalent functionality on the Cyborg side, a reference\nto the relevant Cyborg spec or documentation would help operators\nunderstand how to configure capacity limits in the new model.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"292825d82fdf1a19cf6776b6475f93a1e4f52468","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"7a9121de_fd20c1b0","line":139,"updated":"2026-05-21 14:35:53.000000000","message":"one open question : would Cyborg be able to support all the move operations that nova supports for mdev ? ie. live-migration, unshelve etc.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"cf0b635cfbef329c2f1bc536c9f9a8f4598b7ca0","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"e1f8cdc7_ac50452b","line":139,"in_reply_to":"31eb2b71_c12f28bf","updated":"2026-05-27 16:38:45.000000000","message":"Acknowledged","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1b54c55b9bdaa0b5c51bc91148767850640aaa4f","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"f1be42f1_f2a9f662","line":139,"in_reply_to":"3a4f019e_d432bf39","updated":"2026-06-01 08:11:31.000000000","message":"thanks, LGTM.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"176e5a204e9d9a555c2d729cfbd542ce2b3a37ec","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"3a4f019e_d432bf39","line":139,"in_reply_to":"3d269034_c69f215a","updated":"2026-05-29 14:55:49.000000000","message":"I\u0027ve added a short paragraph linking to the support matrix and clarifying that the same operations on instances currently support will be supported for the new driver","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d25fad0c2f1c305c92a3e6268525c8e196f92a4b","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"9c32d20b_a58416dd","line":139,"in_reply_to":"7a9121de_fd20c1b0","updated":"2026-05-21 20:27:45.000000000","message":"not initally supporting that is out os scope of this spec.\n\nhttps://docs.openstack.org/cyborg/latest/reference/support-matrix.html\nis the set of vm operation sthat are supproted with cybrog today\n\nadding supprot for resize and live migrate will its own spec next cycle ot the one after.\n\nshevle and evacuate are the only supprot move operations today.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"3d269034_c69f215a","line":139,"in_reply_to":"9c32d20b_a58416dd","updated":"2026-05-28 14:09:16.000000000","message":"cool if we already have the support matrix, but we could tell this in this spec.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d25fad0c2f1c305c92a3e6268525c8e196f92a4b","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An allocation reshape is not required as we are only updating the resource"},{"line_number":138,"context_line":"provider traits, not the allocations."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Alternatives"},{"line_number":141,"context_line":"------------"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"31eb2b71_c12f28bf","line":139,"in_reply_to":"cffbd7d0_d8b2130b","updated":"2026-05-21 20:27:45.000000000","message":"correct that is not in scope of the nova spec.\n\nthe cyborg supprot for mdev managmenet was previosuly implmented in\n\nhttps://github.com/openstack/cyborg-specs/blob/master/specs/2023.1/implemented/vgpu-driver-proposal.rst\n\nthe answer is cyrbog responisbel for this nova has no role in enfocing the limits.\n\nhttps://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/gpu/nvidia/sysinfo.py#L104-L143 is how this is caudated today \ni suspect we will have to improve it as we start testing it but we shoudl not detail that in the nova spec. \n\nwe are also propsoing a new dreiver that will replace the exsting nviia specific driver with a generic mdev driver\n\nhttps://review.opendev.org/c/openstack/cyborg-specs/+/982276\n\nwe will design and docuemtn this in the cyborg spec or in followup work once we have the nova integration compelete as part of the generic mdev driver design and implemetion on the cybrog side.\n\nnone of this is relevent to the nova spec however as the entirtiy of the enumaration and allcoation is delegated to the cybrog project in this new model.","commit_id":"672c6e739eba8a041518616f63ea94f1149b1b5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":false,"context_lines":[{"line_number":83,"context_line":"        \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":84,"context_line":"        \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":85,"context_line":"        \u0027attach_handle_info\u0027: {"},{"line_number":86,"context_line":"            \u0027asked_type\u0027: \u0027mtty\u0027,"},{"line_number":87,"context_line":"            \"domain\": \"0000\","},{"line_number":88,"context_line":"            \"bus\": \"10\","},{"line_number":89,"context_line":"            \"device\": \"1\","}],"source_content_type":"text/x-rst","patch_set":9,"id":"413919fb_e9e7e1f3","line":86,"updated":"2026-05-28 14:09:16.000000000","message":"yup, that\u0027s the most crucial bit","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":false,"context_lines":[{"line_number":167,"context_line":"being used is not also configured to be used by Nova. In such a case, we will"},{"line_number":168,"context_line":"log a warning to inform the operator that the device is misconfigured and it"},{"line_number":169,"context_line":"should be used exclusively by Nova or Cyborg, but that it can\u0027t be used by both"},{"line_number":170,"context_line":"services."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"Alternatives"},{"line_number":173,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"34803c43_1a6a0be9","line":170,"updated":"2026-05-28 14:09:16.000000000","message":"++","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2e89063393dc5d8efdcb9e55bd0687d6845d7cad","unresolved":true,"context_lines":[{"line_number":246,"context_line":"To migrate from a Nova-owned vGPU to a Cyborg-owned vGPU,"},{"line_number":247,"context_line":"resize your instance directly from a flavor with a Nova-managed GPU"},{"line_number":248,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a Cyborg-managed MDEV"},{"line_number":249,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"This generally requires extra capacity to support the Cyborg-owned vGPUs"},{"line_number":252,"context_line":"as a single host device cannot be shared between Nova and Cyborg."}],"source_content_type":"text/x-rst","patch_set":9,"id":"bdc53c6c_08f82fb9","line":249,"updated":"2026-05-28 14:09:16.000000000","message":"WAIT ! When looking at https://docs.openstack.org/cyborg/latest/reference/support-matrix.html I haven\u0027t found instance resizes supported by Cyborg so how could this run ?\nI verified and there is no Cyborg ARQ handling in the resize path so this wouldn\u0027t work 😢","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"176e5a204e9d9a555c2d729cfbd542ce2b3a37ec","unresolved":true,"context_lines":[{"line_number":246,"context_line":"To migrate from a Nova-owned vGPU to a Cyborg-owned vGPU,"},{"line_number":247,"context_line":"resize your instance directly from a flavor with a Nova-managed GPU"},{"line_number":248,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a Cyborg-managed MDEV"},{"line_number":249,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"This generally requires extra capacity to support the Cyborg-owned vGPUs"},{"line_number":252,"context_line":"as a single host device cannot be shared between Nova and Cyborg."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7ab10688_ac209e7e","line":249,"in_reply_to":"bdc53c6c_08f82fb9","updated":"2026-05-29 14:55:49.000000000","message":"that it true, we discussed this during PTG https://etherpad.opendev.org/p/cyborg-2026.2-ptg#L465, I just forgot to update the spec to note that the migration would requiring deleting and recreating vms. I changed the wording here to make that clear","commit_id":"8ceff186374ad30aad3a62650c1472cb4b25352a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1b54c55b9bdaa0b5c51bc91148767850640aaa4f","unresolved":false,"context_lines":[{"line_number":253,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name). Note that this"},{"line_number":254,"context_line":"is a delete-and-recreate, not a seamless migration: the instance UUID"},{"line_number":255,"context_line":"will change, network ports are detached unless pre-created, ephemeral"},{"line_number":256,"context_line":"storage is lost, and GPU state (VRAM, contexts) is not preserved."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"This generally requires extra capacity to support the Cyborg-owned vGPUs"},{"line_number":259,"context_line":"as a single host device cannot be shared between Nova and Cyborg."}],"source_content_type":"text/x-rst","patch_set":10,"id":"e2f04127_0bc005a3","line":256,"updated":"2026-06-01 08:11:31.000000000","message":"thanks for changing this.","commit_id":"1bc519938bcc00cc0f0ac761837a0a781a8b2e5a"}]}