)]}'
{"specs/xena/approved/support-vGPU-nova-cyborg-interaction.rst":[{"author":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"change_message_id":"d775636b8edbf81df5276a1845a2c4eb20d815a5","unresolved":true,"context_lines":[{"line_number":328,"context_line":""},{"line_number":329,"context_line":"   * - Release Name"},{"line_number":330,"context_line":"     - Description"},{"line_number":331,"context_line":"   * - Xena"},{"line_number":332,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d7c02f1a_5e95c476","line":331,"updated":"2021-04-09 00:39:23.000000000","message":"Here we need to clarify this specs have been approved in W release, as below:\n   * - Wallaby\n     - Approved\n   * - Xena\n     - Reproposed","commit_id":"72ca94ea03ba7198aaa8c16c8498b8de2c70b6ee"},{"author":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"change_message_id":"be6b0fee66e1e83f6c1786b6af77b8eeb5a8b7c5","unresolved":true,"context_lines":[{"line_number":328,"context_line":""},{"line_number":329,"context_line":"   * - Release Name"},{"line_number":330,"context_line":"     - Description"},{"line_number":331,"context_line":"   * - Xena"},{"line_number":332,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":2,"id":"76e9c795_97993833","line":331,"in_reply_to":"d7c02f1a_5e95c476","updated":"2021-04-09 01:08:33.000000000","message":"Please instead of below:\n\n   * - Wallaby\n     - Introduced\n   * - Xena\n     - Reproposed","commit_id":"72ca94ea03ba7198aaa8c16c8498b8de2c70b6ee"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"483761c7e9039ac79d8c8c5d5e23d9da78ac95d6","unresolved":true,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"       {"},{"line_number":50,"context_line":"           \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":51,"context_line":"           \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":52,"context_line":"       }"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"2. Nova virt driver merge the mdev info from arq into the XML of an instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5def08e0_ff5d9877","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":72},"updated":"2021-04-12 08:04:10.000000000","message":"where does this uuid come from?","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"90608f1e57d2aa4cfcd723c52bd6431b1c1e6d73","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"       {"},{"line_number":50,"context_line":"           \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":51,"context_line":"           \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":52,"context_line":"       }"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"2. Nova virt driver merge the mdev info from arq into the XML of an instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"bdf7f4dc_3ba3ba0c","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":72},"in_reply_to":"5be0a3dc_92dc3006","updated":"2021-05-25 08:34:42.000000000","message":"Done","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"9065824107181a8163bebc5dbf7cca81dcba0a23","unresolved":true,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"       {"},{"line_number":50,"context_line":"           \u0027attach_handle_type\u0027: \u0027MDEV\u0027,"},{"line_number":51,"context_line":"           \u0027attach_handle_uuid\u0027: \u002791ac1606-427e-44bb-8233-f4ff4bf3d241\u0027,"},{"line_number":52,"context_line":"       }"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"2. Nova virt driver merge the mdev info from arq into the XML of an instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5be0a3dc_92dc3006","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":72},"in_reply_to":"5def08e0_ff5d9877","updated":"2021-04-13 05:52:27.000000000","message":"this is just one random uuid for example.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"483761c7e9039ac79d8c8c5d5e23d9da78ac95d6","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"61f0fbf0_0773f5e8","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"updated":"2021-04-12 08:04:10.000000000","message":"as my understanding, here you mentioned 2 cases, one is creating mdev during binding, another is create mdev by admin user in advance, right? (please correct me)","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"90608f1e57d2aa4cfcd723c52bd6431b1c1e6d73","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"4d8beca5_ee4fdf19","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"in_reply_to":"2ab508c6_e9b4e14c","updated":"2021-05-25 08:34:42.000000000","message":"right, cyborg create the medev.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"32ab44261f851869248196d93fa4d6a26aa0354f","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"2ab508c6_e9b4e14c","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"in_reply_to":"4929d76d_0a3227d9","updated":"2021-05-14 13:56:53.000000000","message":"according to ptg discussion[1], i think thi spec focus on create mdev by cyborg not admin, right? please correct me. \n\n[1]https://etherpad.opendev.org/p/cyborg-xena-ptg","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"9065824107181a8163bebc5dbf7cca81dcba0a23","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"f356868b_a28f8f7e","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"in_reply_to":"61f0fbf0_0773f5e8","updated":"2021-04-13 05:52:27.000000000","message":"No, this mainly means the binding case, cyborg create the mdevs and used by nova to generate xml file.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"ea178aedec104e85cac0473c45fac2e9cd76bd95","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"4929d76d_0a3227d9","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"in_reply_to":"c921381e_e0f10c67","updated":"2021-04-15 01:40:56.000000000","message":"Thanks xinran:\n1.yes, we plan to create mdev by admin in Cyborg and provide it to Nova.\n2.we have attach_handles limit the maximum arqs bound, so donnot worry the mdevs will exceed.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"1df91e7eef00ffb88bc069e2e00ee0de91cb365d","unresolved":true,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"3. Cyborg creates mdev device in the sys path"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In theory, if nova and cyborg both can support vGPU management, nova or"},{"line_number":75,"context_line":"   cyborg should support create mdev on the host on there own. Therefore, in"},{"line_number":76,"context_line":"   the cyborg lifecycle management of vGPU, cyborg should creates mediated"},{"line_number":77,"context_line":"   devices beforehand, allowing the nova virt driver to uses it as an existing"},{"line_number":78,"context_line":"   resousrce."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"   * spawn instance interaction(arq interaction part):"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"c921381e_e0f10c67","line":78,"range":{"start_line":74,"start_character":0,"end_line":78,"end_character":13},"in_reply_to":"f356868b_a28f8f7e","updated":"2021-04-13 06:19:18.000000000","message":"ok, I got the point. you mean cyborg should create mdev before calling driver.spawn().\n2 questions:\n1. do you plan to support creating mdev by admin, and nova just allocation mdev and no need to create them.\n2. do you plan to have some mechanism to check if the binding operation(create mdev) exceed the maximum number of vgpu types configured in cyborg.conf.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"32ab44261f851869248196d93fa4d6a26aa0354f","unresolved":true,"context_lines":[{"line_number":186,"context_line":"         |             |                |                   |"},{"line_number":187,"context_line":"         | create vm with dp            |                   |"},{"line_number":188,"context_line":"         +------------\u003e    get device profile               |"},{"line_number":189,"context_line":"                       +----------------+------------------\u003e+"},{"line_number":190,"context_line":"                       |                |                   |"},{"line_number":191,"context_line":"                       | scheduling     |                   |"},{"line_number":192,"context_line":"                       +\u003c--------------\u003e+                   |"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5b6a4b65_3b7a5737","line":189,"range":{"start_line":189,"start_character":24,"end_line":189,"end_character":26},"updated":"2021-05-14 13:56:53.000000000","message":"double arrow","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"90608f1e57d2aa4cfcd723c52bd6431b1c1e6d73","unresolved":false,"context_lines":[{"line_number":186,"context_line":"         |             |                |                   |"},{"line_number":187,"context_line":"         | create vm with dp            |                   |"},{"line_number":188,"context_line":"         +------------\u003e    get device profile               |"},{"line_number":189,"context_line":"                       +----------------+------------------\u003e+"},{"line_number":190,"context_line":"                       |                |                   |"},{"line_number":191,"context_line":"                       | scheduling     |                   |"},{"line_number":192,"context_line":"                       +\u003c--------------\u003e+                   |"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bc32fd4a_35048c21","line":189,"range":{"start_line":189,"start_character":24,"end_line":189,"end_character":26},"in_reply_to":"5b6a4b65_3b7a5737","updated":"2021-05-25 08:34:42.000000000","message":"Done","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":25738,"name":"Xinran WANG","email":"xin-ran.wang@intel.com","username":"Xinran"},"change_message_id":"32ab44261f851869248196d93fa4d6a26aa0354f","unresolved":true,"context_lines":[{"line_number":256,"context_line":""},{"line_number":257,"context_line":"None"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"f1f4b6c2_0cb2145a","line":259,"range":{"start_line":259,"start_character":0,"end_line":259,"end_character":14},"updated":"2021-05-14 13:56:53.000000000","message":"if a compute node version is old, it can not support vgpu binding in vir driver, as you mention at line 52, there should be an issue. please mention that","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"90608f1e57d2aa4cfcd723c52bd6431b1c1e6d73","unresolved":false,"context_lines":[{"line_number":256,"context_line":""},{"line_number":257,"context_line":"None"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bd043e7a_2d11170d","line":259,"range":{"start_line":259,"start_character":0,"end_line":259,"end_character":14},"in_reply_to":"c8287fd8_f300e1b4","updated":"2021-05-25 08:34:42.000000000","message":"Done","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"change_message_id":"1f981429319d1b21fa44684ed71b0cfc8daf0fc9","unresolved":true,"context_lines":[{"line_number":256,"context_line":""},{"line_number":257,"context_line":"None"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"c8287fd8_f300e1b4","line":259,"range":{"start_line":259,"start_character":0,"end_line":259,"end_character":14},"in_reply_to":"f1f4b6c2_0cb2145a","updated":"2021-05-17 11:47:53.000000000","message":"Agree, here need a compute node version bump, make sure it can support vGPU binding operation.","commit_id":"ac3c806e9676af8cd46eb6031967b6a248198f53"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"fbd26fd2dd7e922ea7f5413619acfa1e942bfe75","unresolved":true,"context_lines":[{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"},{"line_number":263,"context_line":"one can resize directly from a flavor with a nova managed vgpu"},{"line_number":264,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg managed vgpu"},{"line_number":265,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"If a compute node version is old, it can not support vgpu binding in libvirt"},{"line_number":268,"context_line":"driver. We need a compute node version bump here, make sure it can support"}],"source_content_type":"text/x-rst","patch_set":7,"id":"e576ca47_ddf4ae08","line":265,"range":{"start_line":262,"start_character":0,"end_line":265,"end_character":55},"updated":"2021-05-29 03:17:15.000000000","message":"Nova instance with cyborg owned device doesn\u0027t support resize as I remember https://docs.openstack.org/api-guide/compute/accelerator-support.html. Also nova-owned vGPU doesn\u0027t support resize also.","commit_id":"8e3f82deba260ae2a974ab0f4e4d0cfdc8e036d4"},{"author":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"change_message_id":"7b1459788f5e2e06f10b7c6f2cef95e0dcfb88e9","unresolved":false,"context_lines":[{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"},{"line_number":263,"context_line":"one can resize directly from a flavor with a nova managed vgpu"},{"line_number":264,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg managed vgpu"},{"line_number":265,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"If a compute node version is old, it can not support vgpu binding in libvirt"},{"line_number":268,"context_line":"driver. We need a compute node version bump here, make sure it can support"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f2ca5d75_b3cfd38a","line":265,"range":{"start_line":262,"start_character":0,"end_line":265,"end_character":55},"in_reply_to":"e576ca47_ddf4ae08","updated":"2021-05-31 07:06:21.000000000","message":"Done","commit_id":"8e3f82deba260ae2a974ab0f4e4d0cfdc8e036d4"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"868bb6faa3c4ffbe26bb6bc9f53cb261fa3d5f18","unresolved":false,"context_lines":[{"line_number":259,"context_line":"Upgrade impact"},{"line_number":260,"context_line":"--------------"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"For those who want to upgrade from nova-owned vGPU to cyborg-owned vGPU,"},{"line_number":263,"context_line":"one can resize directly from a flavor with a nova managed vgpu"},{"line_number":264,"context_line":"(resources:vgpu\u003d1 in the flavor) to a flavor with a cyborg managed vgpu"},{"line_number":265,"context_line":"(accel:device-profile\u003dcyborg-vgpu-device-profile-name)."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"If a compute node version is old, it can not support vgpu binding in libvirt"},{"line_number":268,"context_line":"driver. We need a compute node version bump here, make sure it can support"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6ddd63dd_edfaf46a","line":265,"range":{"start_line":262,"start_character":0,"end_line":265,"end_character":55},"in_reply_to":"f2ca5d75_b3cfd38a","updated":"2021-05-31 07:13:27.000000000","message":"here is not resize a vgpu instance, this means resize the flavor metadata, from creating a nova-owned vgpu instance to creating a cyborg-owned vgpu instance.","commit_id":"8e3f82deba260ae2a974ab0f4e4d0cfdc8e036d4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"55c9c139ffe6c4336b4d5deaf88bfe26fc0e951c","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"c585ee2f_ec146600","line":132,"updated":"2021-06-07 09:59:19.000000000","message":"Actually, thinking it for a second, we don\u0027t need to mark the existing PCI device inventories with a \u0027nova\u0027 trait.\n\nIf a node with Cyborg-managed GPUs provides VGPU inventories, it will either use a VGPU resource class or a \u0027CUSTOM_\u003cfoo\u003e\u0027 resource class (once we merge generic mediated devices spec this cycle) but on a *specific* Resource Provider, which is the physical PCI device.\n\nHere, I think that we should have for Cyborg a different Resource Provider with another name convention and just another custom resource class that *wouldn\u0027t* be VGPU.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"58a99dcf31592a5b2470abf5122e6379cac1bf86","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"4100e0f3_ed6dde7b","line":132,"in_reply_to":"11c1914f_7b7d9d09","updated":"2021-06-23 14:37:19.000000000","message":"I have to reevaluate my position.\n\nI think the vGPU provided by Cyborg are totally the same from the user of the VM perspective that the vGPU provided by Nova. Having a cloud that has both nova vGPUs and cyborg vGPUs means that from the user perspective both provides the same functionality. Still the nova API requires the different ways to request them. This is bad. You have two ways to get the same thing. But why? What is the point? Why we complicate things? \n\nI assume that a deployer only deploys Cyborg to add some value to the cloud. What is that value if Cyborg and Nova provides exactly the same vGPU to the guest and nova already needed to be deployed to create VMs? \n\nIn case of a programmable accelerators I see the difference between the PCI device nova provides via passthrough and a PCI device cyborg provides. The latter one is customized by Cyborg with unique capabilities. And such capabilities are requested by the user. So we can model those capabilities and schedule based on those capabilities. No need to use ownership as the capabilities makes the difference. \n\nSo the whole ownership concept is only needed if two service provides exactly the same thing. As soon as there is a something that is different between the two resources we can schedule based on that difference and we don\u0027t need the ownership. In this sense ownership is a artificial quality we want to add as there is no other qualitative difference.\n\nSo my recommendation is:\n\n* If there are similar resources only differing in capabilities (e.g. PCI devices with programmability) then use the same resource class but use the different capability represented as traits. So no need to model ownership as traits.\n* In General; Forbid to have two services providing exactly the same resource with the same capabilities (for example vGPU from nova and from cyborg).\n* Optionally and in particular to the current vGPU situation, allow an exception to the general rule. Allow cyborg to invent a fake capability (not ownership!) along its vGPU support. Represent that as a custom trait. And require that trait in the device profile. Also document that nova vGPU support and cyborg vGPU support cannot be mixed to avoid a resource:vgpu request allocated from a cyborg RP without actually having an arq created.\n\n\nIn the future:\n\n* When we model PCI devices in placement we will have VF resources due to nova+neutron supporting vnic_type\u003ddirect ports and also similarly VF resources due to nova+neutron+cyborg supporting programmable smartnics via vnic_type\u003daccelerator_direct. So here the VF resource will either has a (CUSTOM_)VNIC_TYPE_DIRECT or a (CUSTOM_)VNIC_TYPE_DIRECT_ACCELERATOR traits (or similar representing the that one of the VF is accelerated by specific programming while the other isn\u0027t). \n\n* If we ever model cinder storage as DISK_GB in placement along with DISK_GB as local storage in nova then we can use (CUSTOM_)LOCAL_STORAGE and (CUSTOM_)VOLUME_STORAGE to differentiate between DISK_GB resources based the way they are actually connected to the VM (e.g one is attached directly and from locally, the other is attached via the network) \n\nNeither of these really needs an OWNER_ trait as it is not the ownership that matters.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c3c978c5155b4d2a7955d78e95f19fd165a7749d","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f7d79d57_e04079b7","line":132,"in_reply_to":"4100e0f3_ed6dde7b","updated":"2021-06-23 17:17:18.000000000","message":"the CUSTOM_VNIC_TYPE_DIRECT approch will not be as trait for ward as i think you are assuming but it might work.\n\nin terms of the excption for cyborg for vGPUS the new trait need to be something that is encudied in the nova prefilter.\n\nas we will have to use a forbidn triat for the exsiting nova vgpu feature.\n\n\n(CUSTOM_)LOCAL_STORAGE and (CUSTOM_)VOLUME_STORAGE  i think does work well for cinder but again nova will need to know what these trait are and append them automatically with a prefilter\n\ne.g. when not boot form volume it will have to report local storage CUSTOM_LOCAL_STORAGE and request it with the same trait.\n\nbecause of the ceph backend and the fact we support puting the libvirt/nova state dir on an nfs share we sould also avoid local and use EPHEMERAL_STORAGE instaead as it may not be local.\n\n\nso i think the path forward in the VGPU case your  are recommending is \n\n1 nova an neutron use the vGPU resouce class\n2 cyborg will report it with a known trait that is not a ower trait\n3 the device filter will contianed the required trait \n4 a prefilter will be provided to add it as a forbiden trait when we have resouces:vgpu\n  and this prefilt will be configurable so that deployment without cyborg do not need to use it.\n5 nova will not be modified to report any trait for the vgpu resouces it reports today\n\nis ^ correct","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"53698609650354868f355c9cfe45dd019a1fb94d","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"cc5de799_7d3cf56f","line":132,"in_reply_to":"7e262437_2d7e9547","updated":"2021-06-25 12:48:23.000000000","message":"unless we make prefilter plugable which we coudl do nova will need to have some code to make this work wehn both cybrog and nova are installed and support vgpus unless we use different rescoues classes.\n\nwe cant have it both ways.\n\n\nnova must be abel to ensure the resouce:vgpus never gets an allocation form a cybpor rp so either cyborg must not use vgpu resocue class or nova need to apply a required or forbidni trait or a member of queiry.\n\n\nif you dont like the user of a trait or a diffent resouce class then aggreates are our only placment native option left or we have to filter in python after the fact which can be problematic if you limit the placement response.\n\nthere is no differen here betwen the cinder case were you agree that each sevice should just use there own trait and the vgpu case where we are disagreing with nova just using it own trait for its gpus. the problem with that appoch is syvalin object to nova every stating \"only the nova owned resouces\" and that is why i say \"forbid cyborg resouces\" via the prefilter using a forbiden trait.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d8ec1aca4b80b05e9854baae85d11dc78b34e915","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"11c1914f_7b7d9d09","line":132,"in_reply_to":"b01a98bf_71bb4f59","updated":"2021-06-23 12:03:59.000000000","message":"\u003e We had discussion about it on #openstack-nova during and after the weekly meeting. I try to summarize my view here.\n\u003e \n\u003e 1) nova managed and cyborg managed vGPU resource is requested differently. The nova managed one uses \"resources:VGPU\" extra spec in the flavor while cyborg uses a device profile in the flavor. \n\u003e I think this is OK as is. We don\u0027t want to support cyborg vGPUs via the \"resources:VGPU\" syntax. \n\u003e \n\u003e 2) As the two type of vGPUs are always requested explicitly and differently therefore we don\u0027t support the use case: \"Give me a vGPU, I don\u0027t care if it is nova or cyborg managed.\" I.e. the admin creating the flavor already decides which type of vGPU the flavor requests. The nova conductor and scheduler does not have to choose just follow the request.\n\u003e \n\u003e 3) We agreed in this spec that \"upgrading\" a VM from nova managed vGPUs to cyborg managed vGPUs is a resize operation. \n\u003e \n\u003e \u003d\u003e Based on these assumptions keeping the VGPU RC for nova usage and creating a new standard or custom RC for cyborg works for me. Personally I vote for a new standard trait for cyborg vGPUs.\n\u003e \n\nI mean Personally I vote for a new standard RC for cyborg vGPUs.\n\n\u003e The OWNER_ trait opens up a lot of questions when we want to define its meaning:\n\u003e * Does OWNER_CYBORG trait on an RP means that _every_ RC on that RP is managed by Cyborg? \n\u003e * Does \"managing\" here means that only cyborg can report inventories and traits on that RP?\n\u003e * Does creating a child RP by service A is allowed if the parent RP owned by service B? \n\u003e * Does cascade deleting allowed by service B even if there are child RPs owned by service A in the tree?\n\u003e * Who is responsible to enforce these rules? Placement? Nova? Cyborg? \n\u003e \n\u003e I think we don\u0027t want to express ownership (as it is hard) we just want to make sure that what is requested separately in the flavor are also easy to separate in the placement a_c request. If cyborg device profile is mapped to a different RC than nova vgpu request then this separation is easy. Trait based separation also works, but if we want to go there then I would like to avoid discussion full ownership.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":31412,"name":"Wenping Song","email":"songwenping@inspur.com","username":"songwenping"},"change_message_id":"6e2981b3866bf040d5cb088702ca3da3a4fc3ebd","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dc9d669d_76d79195","line":132,"in_reply_to":"c585ee2f_ec146600","updated":"2021-06-09 09:34:35.000000000","message":"This is determined on the W PTG: https://etherpad.opendev.org/p/nova-wallaby-ptg#150.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"86023e6a386421499c2b8b67eb72391b3a24e841","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"0c1ef16b_252c7c94","line":132,"in_reply_to":"cc5de799_7d3cf56f","updated":"2021-06-29 11:40:42.000000000","message":"\u003e unless we make prefilter plugable which we coudl do nova will need to have some code to make this work wehn both cybrog and nova are installed and support vgpus unless we use different rescoues classes.\n\u003e \n\u003e we cant have it both ways.\n\u003e \n\u003e \n\u003e nova must be abel to ensure the resouce:vgpus never gets an allocation form a cybpor rp so either cyborg must not use vgpu resocue class or nova need to apply a required or forbidni trait or a member of queiry.\n\u003e \n\u003e \n\u003e if you dont like the user of a trait or a diffent resouce class then aggreates are our only placment native option left or we have to filter in python after the fact which can be problematic if you limit the placement response.\n\u003e \n\u003e there is no differen here betwen the cinder case were you agree that each sevice should just use there own trait and the vgpu case where we are disagreing with nova just using it own trait for its gpus. the problem with that appoch is syvalin object to nova every stating \"only the nova owned resouces\" and that is why i say \"forbid cyborg resouces\" via the prefilter using a forbiden trait.\n\nI think the difference between the cinder and the cyborg cases the that in the cinder case only cinder needs to know and use the VOLUME_STORAGE trait. Nova only need to know about and use the EPHEMERAL_STORAGE trait. While in the cyborg case, there is no nova only trait that only nova uses, and a cyborg only trait that only cyborg uses. Nova need to hardcode the cyborg trait in the prefilter. In cinder case nova only need to take the cinder resource request as a black box and add it to the a_c query.\n\nBut I rest my case. I spent more time on this than what I should considering that I don\u0027t need this feature. If the rest of us agrees that having a cyborg only trait hardcoded in nova prefilter is acceptable coupling between cyborg and nova then I will not block on it.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"002cb9c7550643cdc4c46da4a7e992585e7c7475","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"b01a98bf_71bb4f59","line":132,"in_reply_to":"dc9d669d_76d79195","updated":"2021-06-23 11:59:33.000000000","message":"We had discussion about it on #openstack-nova during and after the weekly meeting. I try to summarize my view here.\n\n1) nova managed and cyborg managed vGPU resource is requested differently. The nova managed one uses \"resources:VGPU\" extra spec in the flavor while cyborg uses a device profile in the flavor. \nI think this is OK as is. We don\u0027t want to support cyborg vGPUs via the \"resources:VGPU\" syntax. \n\n2) As the two type of vGPUs are always requested explicitly and differently therefore we don\u0027t support the use case: \"Give me a vGPU, I don\u0027t care if it is nova or cyborg managed.\" I.e. the admin creating the flavor already decides which type of vGPU the flavor requests. The nova conductor and scheduler does not have to choose just follow the request.\n\n3) We agreed in this spec that \"upgrading\" a VM from nova managed vGPUs to cyborg managed vGPUs is a resize operation. \n\n\u003d\u003e Based on these assumptions keeping the VGPU RC for nova usage and creating a new standard or custom RC for cyborg works for me. Personally I vote for a new standard trait for cyborg vGPUs.\n\nThe OWNER_ trait opens up a lot of questions when we want to define its meaning:\n* Does OWNER_CYBORG trait on an RP means that _every_ RC on that RP is managed by Cyborg? \n* Does \"managing\" here means that only cyborg can report inventories and traits on that RP?\n* Does creating a child RP by service A is allowed if the parent RP owned by service B? \n* Does cascade deleting allowed by service B even if there are child RPs owned by service A in the tree?\n* Who is responsible to enforce these rules? Placement? Nova? Cyborg? \n\nI think we don\u0027t want to express ownership (as it is hard) we just want to make sure that what is requested separately in the flavor are also easy to separate in the placement a_c request. If cyborg device profile is mapped to a different RC than nova vgpu request then this separation is easy. Trait based separation also works, but if we want to go there then I would like to avoid discussion full ownership.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7ac767bd7ff5cdb780f69e4b6cfb372d02e90724","unresolved":true,"context_lines":[{"line_number":129,"context_line":"           trait2: CUSTOM_\u003cVENDOR_NAME\u003e_\u003cPRODUCT_ID\u003e_\u003cVirtual_GPU_Type\u003e."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"       + In the nova side, it will need to report a new trait **OWNER_NOVA**"},{"line_number":132,"context_line":"         for vGPU resources during inventory report."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7e262437_2d7e9547","line":132,"in_reply_to":"f7d79d57_e04079b7","updated":"2021-06-25 08:47:46.000000000","message":"\u003e the CUSTOM_VNIC_TYPE_DIRECT approch will not be as trait for ward as i think you are assuming but it might work.\n\u003e \n\u003e in terms of the excption for cyborg for vGPUS the new trait need to be something that is encudied in the nova prefilter.\n\u003e \n\u003e as we will have to use a forbidn triat for the exsiting nova vgpu feature.\n\nI don\u0027t want to encode a cyborg specific trait into a nova feature that is independent from the cyborg feature. This is why I suggested simply documenting that the two vgpu feature should not be mixed. \n\nIn the VF and DISK_GB cases we don\u0027t need the forbidden trait at all. In those cases it is enough to require the positive trait only. E.g. the nova feature handling DISK_GB as local disk only needs to know about and include require\u003dLOCAL_STORAGE and does not have to know about the existence of VOLUME_STORAGE trait at all. Similarly cinder only need to know and use the VOLUME_STORAGE trait.\n\n \n\u003e \n\u003e (CUSTOM_)LOCAL_STORAGE and (CUSTOM_)VOLUME_STORAGE  i think does work well for cinder but again nova will need to know what these trait are and append them automatically with a prefilter\n\u003e \n\u003e e.g. when not boot form volume it will have to report local storage CUSTOM_LOCAL_STORAGE and request it with the same trait.\n\nI imagine the cinder interface the same way as what we have with neutron. So cinder will tell us what resource to allocate for a given volume with what traits. \n\n\u003e \n\u003e because of the ceph backend and the fact we support puting the libvirt/nova state dir on an nfs share we sould also avoid local and use EPHEMERAL_STORAGE instaead as it may not be local.\n\u003e \n\nYeah EPHEMERAL_STORAGE probably a better name.\n\n\n\u003e \n\u003e so i think the path forward in the VGPU case your  are recommending is \n\u003e \n\u003e 1 nova an neutron use the vGPU resouce class\n\u003e 2 cyborg will report it with a known trait that is not a ower trait\n\u003e 3 the device filter will contianed the required trait \n\u003e 4 a prefilter will be provided to add it as a forbiden trait when we have resouces:vgpu\n\u003e   and this prefilt will be configurable so that deployment without cyborg do not need to use it.\n\nI know that this helps fully separating the nova and the cyborg feature and it allows using both in the same deployment. But I don\u0027t like the fact that nova needs to know and hardcode a purely cyborg related trait.\n\n\u003e 5 nova will not be modified to report any trait for the vgpu resouces it reports today\n\u003e \n\u003e is ^ correct","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"55c9c139ffe6c4336b4d5deaf88bfe26fc0e951c","unresolved":true,"context_lines":[{"line_number":134,"context_line":"     - When the end user makes a vGPU request, for a nova owned vGPU request,"},{"line_number":135,"context_line":"       one can specify ``resources##:VGPU\u003d1`` in flavor. For a cyborg owned"},{"line_number":136,"context_line":"       vGPU, one need specify in pre-defined device profile, then add it to"},{"line_number":137,"context_line":"       flavor."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"   * In libvirt driver, use a mdev_tag to identify which vGPU is the current"},{"line_number":140,"context_line":"     operation request(eg. spawn, reboot) going to land. If it is cyborg vGPU,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"c11b7a4a_bd6d98d1","line":137,"updated":"2021-06-07 09:59:19.000000000","message":"See, if we do the above, Cyborg flavors could just ask for RCs like CUSTOM_CYBORG_MY_TYPE\u003d1 and as VGPU resources would be only for Nova, it shouldn\u0027t be a problem.","commit_id":"f81a5829bba1d2611f0b597a172a58d2d67539b4"}]}