)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"b69a1672bfdc9277dd4ccf4a14ff3bef7207c1b8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a7b5b5b1_a72f9ffc","updated":"2024-05-08 12:10:03.000000000","message":"Thanks for the update it looks good to me","commit_id":"a26a47f59c5ecd619a6fe70630d6d8b0d25c55ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"3554ba129611b2e120bd0745956f086180869933","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"4417f189_a5cbcdb3","updated":"2024-05-10 12:39:22.000000000","message":"mention that suspend is not supported","commit_id":"a26a47f59c5ecd619a6fe70630d6d8b0d25c55ef"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"45b13831762023c02898206f3922fbf5b0f19478","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"3102d79a_9b911a7e","updated":"2024-05-13 08:56:58.000000000","message":"Looks good to me","commit_id":"b9fc21f22a49e3ec74bdbdb5009b1182eb651919"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"38962f7f595c16b1dade44aa06c05e0172ed16b0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"6929a54d_ba20e95e","updated":"2024-05-14 09:43:08.000000000","message":"Thanks for the new modifications for explaining more.","commit_id":"b9fc21f22a49e3ec74bdbdb5009b1182eb651919"}],"specs/2024.2/approved/libvirt-virtiofs-attach-manila-shares.rst":[{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"584c72dbf8555377e4ff4cc6f3a1466e7ee7ba8a","unresolved":true,"context_lines":[{"line_number":69,"context_line":"for cold attach and detach. Future work will aim to add live attach and detach"},{"line_number":70,"context_line":"once `support lands in libvirt itself`__."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. __: https://listman.redhat.com/archives/libvir-list/2021-October/msg00097.html"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"This initial libvirt support will target the basic NFS and slightly more"},{"line_number":75,"context_line":"complex CephFS backends within Manila. Shares will be mapped through to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"437b88c7_f064eb10","line":72,"updated":"2024-04-06 09:10:53.000000000","message":"Aren\u0027t https://bugzilla.redhat.com/show_bug.cgi?id\u003d1897708 and https://libvirt.org/news.html#v7-9-0-2021-11-01 saying that live attach / detach for virtiofs devices has now been implemented in libvirt 7.8.0 onwards?","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":false,"context_lines":[{"line_number":69,"context_line":"for cold attach and detach. Future work will aim to add live attach and detach"},{"line_number":70,"context_line":"once `support lands in libvirt itself`__."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. __: https://listman.redhat.com/archives/libvir-list/2021-October/msg00097.html"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"This initial libvirt support will target the basic NFS and slightly more"},{"line_number":75,"context_line":"complex CephFS backends within Manila. Shares will be mapped through to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fdd0918d_60af2805","line":72,"in_reply_to":"437b88c7_f064eb10","updated":"2024-04-30 10:06:56.000000000","message":"Hi Michael, you are right. I have changed it.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a236b7f7f714a5158d4f90e235d71bacff4c4931","unresolved":true,"context_lines":[{"line_number":182,"context_line":"Share attachment/detachment can only be done if the VM state is ``STOPPED``"},{"line_number":183,"context_line":"or ``ERROR``."},{"line_number":184,"context_line":"Note: The VM start operation could fail if an underlying share attach fails or"},{"line_number":185,"context_line":"is not in inactive state."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Mount operation will be done when the share is not mounted on the compute host."},{"line_number":188,"context_line":"If a previous share would have been mounted on the compute host for another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"24de3a66_dae1477e","line":185,"updated":"2024-04-04 13:54:19.000000000","message":"How nova will signal the failure?\n\n* Will nova reject the start API request if the sharemapping state is not inactive?\n* Compared to the case when the mount fails on the compute side during start where the start API request already returned (the start_instance RPC is a cast). Will the instance be put into ERROR state or only the start instance action will be marked unsuccessful and the instance is set back to STOPPED?","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":true,"context_lines":[{"line_number":182,"context_line":"Share attachment/detachment can only be done if the VM state is ``STOPPED``"},{"line_number":183,"context_line":"or ``ERROR``."},{"line_number":184,"context_line":"Note: The VM start operation could fail if an underlying share attach fails or"},{"line_number":185,"context_line":"is not in inactive state."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Mount operation will be done when the share is not mounted on the compute host."},{"line_number":188,"context_line":"If a previous share would have been mounted on the compute host for another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"37acacef_b5e23ee3","line":185,"in_reply_to":"24de3a66_dae1477e","updated":"2024-04-30 10:06:56.000000000","message":"As of today, the instance will be put into ERROR. New \"start\" attempts require a hard reboot.\nThe idea was to respect what we are used to doing in such kind of cases.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"73ff444334ecf3171e9fa9b488d35a13256eb034","unresolved":true,"context_lines":[{"line_number":182,"context_line":"Share attachment/detachment can only be done if the VM state is ``STOPPED``"},{"line_number":183,"context_line":"or ``ERROR``."},{"line_number":184,"context_line":"Note: The VM start operation could fail if an underlying share attach fails or"},{"line_number":185,"context_line":"is not in inactive state."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Mount operation will be done when the share is not mounted on the compute host."},{"line_number":188,"context_line":"If a previous share would have been mounted on the compute host for another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"76c72320_8664302c","line":185,"in_reply_to":"37acacef_b5e23ee3","updated":"2024-04-30 11:12:01.000000000","message":"So I still have a question: Will we check the sharemapping state right in the API before sending the RPC to the compute to see if the share is in inactive state? I.e. If the sharemapping is already in error, due to a manila communication issue happened during the attach share, then we can reject the start request early and don\u0027t need to send any RPC.\n\nThe other case I think is clear: If the sharemapping state is inactive then the API sends the cast RPC to the compute and if the mount fails on the compute then we report the error for the instance action and also we put both the sharemapping and the instance in ERROR state.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7c39d8cc9a1d2bfadedf2d4df40c9ae76d95009b","unresolved":true,"context_lines":[{"line_number":182,"context_line":"Share attachment/detachment can only be done if the VM state is ``STOPPED``"},{"line_number":183,"context_line":"or ``ERROR``."},{"line_number":184,"context_line":"Note: The VM start operation could fail if an underlying share attach fails or"},{"line_number":185,"context_line":"is not in inactive state."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Mount operation will be done when the share is not mounted on the compute host."},{"line_number":188,"context_line":"If a previous share would have been mounted on the compute host for another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b86b2905_85876ea4","line":185,"in_reply_to":"76c72320_8664302c","updated":"2024-04-30 12:57:33.000000000","message":"To keep the error handling in a single place let\u0027s not add a separate error handling now in the API side, just let the compute handle all the error cases.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"58b53ff072674ef8bcaf0778c17df18b7ed258a9","unresolved":false,"context_lines":[{"line_number":182,"context_line":"Share attachment/detachment can only be done if the VM state is ``STOPPED``"},{"line_number":183,"context_line":"or ``ERROR``."},{"line_number":184,"context_line":"Note: The VM start operation could fail if an underlying share attach fails or"},{"line_number":185,"context_line":"is not in inactive state."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Mount operation will be done when the share is not mounted on the compute host."},{"line_number":188,"context_line":"If a previous share would have been mounted on the compute host for another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0409087b_242b33f6","line":185,"in_reply_to":"b86b2905_85876ea4","updated":"2024-05-07 16:23:08.000000000","message":"Done","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a236b7f7f714a5158d4f90e235d71bacff4c4931","unresolved":true,"context_lines":[{"line_number":298,"context_line":"- Instance should have the required capabilities to enable"},{"line_number":299,"context_line":"  virtiofs (see above)."},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"This API operates asynchronously. Consequently, the attachment state of"},{"line_number":302,"context_line":"the VM share is defined and marked as \"attaching\" in the database."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"In the background, the compute node will request Manila to grant access to"},{"line_number":305,"context_line":"the share and lock it for nova usage. Once this process is complete, the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"43cd7e33_71790df5","line":302,"range":{"start_line":301,"start_character":52,"end_line":302,"end_character":13},"updated":"2024-04-04 13:54:19.000000000","message":"is it the state of the sharemapping?","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":false,"context_lines":[{"line_number":298,"context_line":"- Instance should have the required capabilities to enable"},{"line_number":299,"context_line":"  virtiofs (see above)."},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"This API operates asynchronously. Consequently, the attachment state of"},{"line_number":302,"context_line":"the VM share is defined and marked as \"attaching\" in the database."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"In the background, the compute node will request Manila to grant access to"},{"line_number":305,"context_line":"the share and lock it for nova usage. Once this process is complete, the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"186d50b0_eea5c62a","line":302,"range":{"start_line":301,"start_character":52,"end_line":302,"end_character":13},"in_reply_to":"43cd7e33_71790df5","updated":"2024-04-30 10:06:56.000000000","message":"Acknowledged","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a236b7f7f714a5158d4f90e235d71bacff4c4931","unresolved":true,"context_lines":[{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Prerequisite(s): Instance much be in the ``SHUTOFF`` or ``ERROR`` state."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"35ce6233_49ab34ec","line":356,"range":{"start_line":355,"start_character":50,"end_line":356,"end_character":10},"updated":"2024-04-04 13:54:19.000000000","message":"is the the state of the sharemapping?","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":false,"context_lines":[{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Prerequisite(s): Instance much be in the ``SHUTOFF`` or ``ERROR`` state."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a1b04d8e_7b76974f","line":356,"range":{"start_line":355,"start_character":50,"end_line":356,"end_character":10},"in_reply_to":"35ce6233_49ab34ec","updated":"2024-04-30 10:06:56.000000000","message":"Acknowledged","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a236b7f7f714a5158d4f90e235d71bacff4c4931","unresolved":true,"context_lines":[{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"},{"line_number":360,"context_line":"it requests Manila to unlock the share and deny access."},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Once this process is finalized, the association of the share is eliminated"},{"line_number":363,"context_line":"from the database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b630af72_2cbb1856","line":360,"range":{"start_line":358,"start_character":0,"end_line":360,"end_character":55},"updated":"2024-04-04 13:54:19.000000000","message":"I think we can and should deny access to the share from the compute right after the share is unmounted during the VM shutdown.\n\nAlso I thought the check that the share is used by another instance on the same compute should be done before umount. Or do we mount the share to independent locations if multiple VMs using it on the same compute?","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7c39d8cc9a1d2bfadedf2d4df40c9ae76d95009b","unresolved":true,"context_lines":[{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"},{"line_number":360,"context_line":"it requests Manila to unlock the share and deny access."},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Once this process is finalized, the association of the share is eliminated"},{"line_number":363,"context_line":"from the database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"a7e8a55b_d5c5e451","line":360,"range":{"start_line":358,"start_character":0,"end_line":360,"end_character":55},"in_reply_to":"46bd027e_fd5d14b9","updated":"2024-04-30 12:57:33.000000000","message":"* to keep the logic similar for both nfs and cephfs we only remove the access policy after the last user of the share is unmounted on all compute. nfs could do per compute IP access policy but currently the cephfs logic uses per nova user access token. Later we might be able to use a per nova per compute name cephfs user / token\n\n* we need two checks for unmount we need to check if other VM is using the share on the same compute. for policy removal we need to check if any compute using the share.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"58b53ff072674ef8bcaf0778c17df18b7ed258a9","unresolved":false,"context_lines":[{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"},{"line_number":360,"context_line":"it requests Manila to unlock the share and deny access."},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Once this process is finalized, the association of the share is eliminated"},{"line_number":363,"context_line":"from the database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"e6cd4dbd_46cf8c69","line":360,"range":{"start_line":358,"start_character":0,"end_line":360,"end_character":55},"in_reply_to":"a7e8a55b_d5c5e451","updated":"2024-05-07 16:23:08.000000000","message":"Done","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"73ff444334ecf3171e9fa9b488d35a13256eb034","unresolved":true,"context_lines":[{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"},{"line_number":360,"context_line":"it requests Manila to unlock the share and deny access."},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Once this process is finalized, the association of the share is eliminated"},{"line_number":363,"context_line":"from the database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"46bd027e_fd5d14b9","line":360,"range":{"start_line":358,"start_character":0,"end_line":360,"end_character":55},"in_reply_to":"ab6782c9_98a8e099","updated":"2024-04-30 11:12:01.000000000","message":"\u003e We need to discuss this; this is currently possible with NFS but not with CEPHFS.\n\u003e The Nova user has access to the share with CEPHFS, so removing access to the share will deny access for all VMs using it, even on another compute.\n\nOhh I did not know that. I thought the access is granted for the IP of the compute.\n\n\n\u003e \n\u003e This is also what was proposed, to set/unset manila policy during attach/detach.\n\u003e \n\u003e The check is done before the umount, but I will clarify all of this after our discussion.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":true,"context_lines":[{"line_number":355,"context_line":"This API functions asynchronously, leading to the state of the VM share"},{"line_number":356,"context_line":"attachment being marked as detaching."},{"line_number":357,"context_line":""},{"line_number":358,"context_line":"Concurrently, the compute system conducts a verification to see if the"},{"line_number":359,"context_line":"share is no longer being utilized by another instance. If found unused,"},{"line_number":360,"context_line":"it requests Manila to unlock the share and deny access."},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Once this process is finalized, the association of the share is eliminated"},{"line_number":363,"context_line":"from the database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ab6782c9_98a8e099","line":360,"range":{"start_line":358,"start_character":0,"end_line":360,"end_character":55},"in_reply_to":"b630af72_2cbb1856","updated":"2024-04-30 10:06:56.000000000","message":"We need to discuss this; this is currently possible with NFS but not with CEPHFS.\nThe Nova user has access to the share with CEPHFS, so removing access to the share will deny access for all VMs using it, even on another compute.\n\nThis is also what was proposed, to set/unset manila policy during attach/detach.\n\nThe check is done before the umount, but I will clarify all of this after our discussion.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"28ea97c5af50fcfc773dc3dee1ac84940e16ef34","unresolved":true,"context_lines":[{"line_number":504,"context_line":"A new compute service version and capability traits will be introduced to"},{"line_number":505,"context_line":"ensure both the compute service and underlying virt stack are new enough to"},{"line_number":506,"context_line":"support attaching a share via ``virtio-fs`` before the request is accepted."},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"Implementation"},{"line_number":509,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":510,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"d00c8953_7d7bce5c","line":507,"updated":"2024-04-05 14:08:11.000000000","message":"lets mention that we need a DB migration to add a constraint to avoid attaching a share to an instance twice.","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"0d70470c46253b862fd6fe697207bf676314f316","unresolved":false,"context_lines":[{"line_number":504,"context_line":"A new compute service version and capability traits will be introduced to"},{"line_number":505,"context_line":"ensure both the compute service and underlying virt stack are new enough to"},{"line_number":506,"context_line":"support attaching a share via ``virtio-fs`` before the request is accepted."},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"Implementation"},{"line_number":509,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":510,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"999354b5_fb7e5873","line":507,"in_reply_to":"d00c8953_7d7bce5c","updated":"2024-04-30 10:06:56.000000000","message":"Done","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a236b7f7f714a5158d4f90e235d71bacff4c4931","unresolved":true,"context_lines":[{"line_number":568,"context_line":"   * - Caracal"},{"line_number":569,"context_line":"     - Reproposed"},{"line_number":570,"context_line":"   * - Dalmatian"},{"line_number":571,"context_line":"     - Updated and reproposed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dcafc470_cba274e1","line":571,"updated":"2024-04-04 13:54:19.000000000","message":"This is the diff between 2024.1 and 2024.2: https://paste.opendev.org/show/bkhDRGFhlBtXx5HPgG87/","commit_id":"8d5d8f050480e0f97fba27a7d9662f3fdb799a4d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1599a353c6a79be08e8206876cbee16efdaa1e62","unresolved":true,"context_lines":[{"line_number":220,"context_line":"Extend DeviceMetadata with ShareMetadata object containing `shareId` and"},{"line_number":221,"context_line":"`tag` used to mount the virtiofs on an instance by the user."},{"line_number":222,"context_line":"See :ref:`dalmatian-other-end-user-impact`."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"},{"line_number":226,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1c1ed35a_1fd9f28c","line":223,"updated":"2024-05-02 09:53:27.000000000","message":"We need to document what happens when the VM is deleted with shares.\n\nNormal delete:\n* both unmount and manila policy removal happens during the delete on the compute side.\n* if both succeeds then the sharemapping is deleted as well.\n* if the unmount or the policy removal fails then the instance is set to ERROR state and the deletion can be retried by the user. @uggla please double check that this case is aligned with the case when a VM is deleted with volumes but the cinder calls during delete are failing.\n\nLocal delete (i.e. the VM status is set to DELETED in the DB form the API as the compute is unavailable during the delete request https://github.com/openstack/nova/blob/ca5be998372e0cd64c039dc9befdf90ae87e5e4e/nova/compute/api.py#L2683-L2691)\n* no unmount or manila policy removal happens form the API\n* when the compute is up again it will detect that there is an instance that is marked as DELETED but did not cleaned up from the compute yet.  During init_instance the compute will try to do the delete that will need to unmount the share and the remove the access policy from manila. https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1088-L1094\n* if this succeeds then the sharemapping will be deleted too\n* if either the unmount or the access policy removal fails then the deletion is not complete but the compute startup procedure is not stopped, the error is only logged. We don\u0027t want to keep the mount for security reasons so we need a mechanism that retries the cleanup.\n  * There is a periodic task that cleans up running but deleted instances \nhttps://github.com/openstack/nova/blob/ca5be998372e0cd64c039dc9befdf90ae87e5e4e/nova/compute/manager.py#L10732C9-L10732C43 This is not good for us as is because it only handles instances that are running on the hypervisor but the partial delete might already destroyed the instance on the hypervisor during init_instance and just the unmount failed.\n  * There is another periodic task that retries incomplete deletes of the instance files https://github.com/openstack/nova/blob/ca5be998372e0cd64c039dc9befdf90ae87e5e4e/nova/compute/manager.py#L11224 This today only calls `self.driver.delete_instance_files` so it won\u0027t automatically retry the unmount.\n  \nI\u0027m not sure which one is better:\n* re-defining what _run_pending_deletes periodic does to retry the unmount and access policy cleanup. This requires changing the documented meaning of the related config options.\n* or to add yet another periodic that retries the unmount and access removal.","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a8cacbc226124cf07f97e8dc38003cdf642d18e2","unresolved":true,"context_lines":[{"line_number":220,"context_line":"Extend DeviceMetadata with ShareMetadata object containing `shareId` and"},{"line_number":221,"context_line":"`tag` used to mount the virtiofs on an instance by the user."},{"line_number":222,"context_line":"See :ref:`dalmatian-other-end-user-impact`."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"},{"line_number":226,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3593bebf_4687371c","line":223,"in_reply_to":"1c1ed35a_1fd9f28c","updated":"2024-05-02 10:03:13.000000000","message":"For completeness we can mention that if the instance is deleted but soft delete is enabled (i.e. the instance can still be restored for a time period) then the soft delete action will call power_off and the periodic reclaim after the restore time window is over will call instance_delete again. If the unmount / policy removal fails during the periodic reclaim then probably we are in the same situation as in case of local delete + failure, that we need to retry the unmount somehow.\n\nAlso another case that consider for local delete when the local delete happens due to the compute is unavailable but the compute service is not restarted only the network connectivity to the running service is restored so there won\u0027t be init_instance call and the local deleted instance is not cleaned up at all. This might be an independent bug that if reproducible today might worth a fix independently from the manila series, but the solution for the bug might be the same periodic job that retries the deletion.","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"58b53ff072674ef8bcaf0778c17df18b7ed258a9","unresolved":false,"context_lines":[{"line_number":220,"context_line":"Extend DeviceMetadata with ShareMetadata object containing `shareId` and"},{"line_number":221,"context_line":"`tag` used to mount the virtiofs on an instance by the user."},{"line_number":222,"context_line":"See :ref:`dalmatian-other-end-user-impact`."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Alternatives"},{"line_number":225,"context_line":"------------"},{"line_number":226,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dde22d8e_14b103bf","line":223,"in_reply_to":"3593bebf_4687371c","updated":"2024-05-07 16:23:08.000000000","message":"Done","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"73ff444334ecf3171e9fa9b488d35a13256eb034","unresolved":true,"context_lines":[{"line_number":350,"context_line":""},{"line_number":351,"context_line":"Detach a share from an instance."},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Prerequisite(s): Instance much be in the ``SHUTOFF`` or ``ERROR`` state."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"This API functions asynchronously, leading to the share_mapping status being"},{"line_number":356,"context_line":"marked as detaching."}],"source_content_type":"text/x-rst","patch_set":2,"id":"a0ab66ad_d85fcc1f","line":353,"range":{"start_line":353,"start_character":26,"end_line":353,"end_character":30},"updated":"2024-04-30 11:12:01.000000000","message":"nit: must","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"58b53ff072674ef8bcaf0778c17df18b7ed258a9","unresolved":false,"context_lines":[{"line_number":350,"context_line":""},{"line_number":351,"context_line":"Detach a share from an instance."},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Prerequisite(s): Instance much be in the ``SHUTOFF`` or ``ERROR`` state."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"This API functions asynchronously, leading to the share_mapping status being"},{"line_number":356,"context_line":"marked as detaching."}],"source_content_type":"text/x-rst","patch_set":2,"id":"a10b9c66_c36c5c0a","line":353,"range":{"start_line":353,"start_character":26,"end_line":353,"end_character":30},"in_reply_to":"a0ab66ad_d85fcc1f","updated":"2024-05-07 16:23:08.000000000","message":"Done","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7187f08aee2470b6c87d4263a72ec8b7235239fe","unresolved":true,"context_lines":[{"line_number":506,"context_line":"support attaching a share via ``virtio-fs`` before the request is accepted."},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"A new DB migration constraint to prevent a share to be attached more"},{"line_number":509,"context_line":"than once will be introduced."},{"line_number":510,"context_line":""},{"line_number":511,"context_line":"Implementation"},{"line_number":512,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8b60bda4_8e1bd608","line":509,"updated":"2024-05-02 08:50:36.000000000","message":"Worth to mention that it will be a drop / recreate table as the table is empyt https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2024-04-30.log.html#t2024-04-30T16:45:13","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"58b53ff072674ef8bcaf0778c17df18b7ed258a9","unresolved":false,"context_lines":[{"line_number":506,"context_line":"support attaching a share via ``virtio-fs`` before the request is accepted."},{"line_number":507,"context_line":""},{"line_number":508,"context_line":"A new DB migration constraint to prevent a share to be attached more"},{"line_number":509,"context_line":"than once will be introduced."},{"line_number":510,"context_line":""},{"line_number":511,"context_line":"Implementation"},{"line_number":512,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"82a640da_f9bc0377","line":509,"in_reply_to":"8b60bda4_8e1bd608","updated":"2024-05-07 16:23:08.000000000","message":"Done","commit_id":"d0689f5710eb9e4fcb58334258dbd484e8791055"}]}