)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"83f7c35e38ec912cc7adb17667a5db8731b15897","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6a078309_a0e6b8f3","updated":"2025-11-20 13:16:53.000000000","message":"content now in sync with the agreement from the PTG to move the logic to the conductor.","commit_id":"39c2cc50d8ae9588b267a455b64f3e4d3f460054"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"2b3bc68432d024c92816a9d8a2321cc205b8c27f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8bd46964_4c0392c1","updated":"2025-11-27 10:40:31.000000000","message":"I had to correct 2 parts where the spec still said that the whole attach-volume was synchronous, not only the reserve-block-device mapping call. Other than that, I\u0027d be good to go.","commit_id":"8e149251075f83c3f5f5b71845e1efb9c0777164"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"5ebe92e532e966552f5c3c74b119c6cf7ecbaef5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"8b994143_8658b4c4","updated":"2025-11-27 11:16:30.000000000","message":"Just line-length fixes to make Zuul happy.","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"bad6c7c258e19185af80415a31234c9994f2b4f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f8475e9e_dfd24cc0","updated":"2025-12-01 16:40:43.000000000","message":"Looks good to me","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ffb50bc2f7f99ba72d0668167d75e93cc40c1949","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"60a554e5_9e2064a9","updated":"2025-12-03 17:50:10.000000000","message":"Simple to read and nice to have spec. Thanks for the work !","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"}],"specs/2026.1/approved/async-volume-attachments.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7839fb7543ac2ee801f18ed8f85b81dfbd651a95","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dbc5fa22_68f7f7e7","line":29,"updated":"2025-09-01 07:53:12.000000000","message":"I think the actual attachment to the guest via attach_volume RPC is a cast[1] only the reserve_block_device_name is a call [2].\n\nIn the other hand attach_interface RPC is a call [3] causing very similar problem (interface attach can be slow due to waiting for external notification from neutron) to what is described here. \n\nWhile I\u0027m not a fan of extending scope, if the end goal is not to block REST API handling native threads to help transition folks away from eventlet then we need to at least handle attach_interface as well and potentially need to review our RPC APIs to see where are the other potentially long running calls.\n\n\n[1]https://github.com/openstack/nova/blob/29eaf28acc4be72b0d3ddf53d43304ff8e948f9f/nova/compute/rpcapi.py#L588 \n[2]https://github.com/openstack/nova/blob/29eaf28acc4be72b0d3ddf53d43304ff8e948f9f/nova/compute/rpcapi.py#L1329\n[3]https://github.com/openstack/nova/blob/29eaf28acc4be72b0d3ddf53d43304ff8e948f9f/nova/compute/rpcapi.py#L582","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"51c18162136521f44826c46ba2514fe3f6e1db9b","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"8c8f82e9_a68cd59b","line":29,"in_reply_to":"3ca9b44d_86f33eee","updated":"2025-10-20 16:16:13.000000000","message":"I\u0027m OK to have two separate specs one for the volume and one for the interface attach.\n\nI still think that if we want to avoid the problem described above as\n```\nIn eventlet (or any greenthreading scheme), blocking requests are not as expensive\nbecause the request handler is able to service other connections while waiting.\nHowever, in an environment like WSGI where each request is handled in a real\nthread or process, blocking requests are much more expensive.\n```\nthen we need to solve both cases.\n\n@johannes.kulik@sap.com The hypervisor/details issue is solved in the meantime via https://review.opendev.org/q/topic:%22bug/2122036%22","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"ffd01227dafb464794b9856c5071bff705810f48","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bc4c1548_0b208c9c","line":29,"in_reply_to":"811540d7_81bcf1e9","updated":"2025-09-03 09:25:34.000000000","message":"My bad, yes, I was focusing on the _attach_volume() method from nova/compute/api.py, which seems blocked by the reserve call instead of the attach.\nAnyway, that does not change the value of this spec IMO.\n\nattach_interface is also most likely to block, but as an operator, this is less problematic for now.\nHowever, I agree with the fact that would be nice to solve as well.\nDo you think that should be part of the same spec?","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d398d2281e37417c783bf210b14a4a4f71956daa","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e83a93c2_ddecac0a","line":29,"in_reply_to":"955a437d_2c504bce","updated":"2025-09-02 08:32:27.000000000","message":"\u003e While attach_interface() is actually synchronous, it\u0027s only blocked by slow backends, because the lock is taken on {instance.uuid}-{port.id}.\n\nThat lock is might even be a bug. I don\u0027t think nova can handle the instance being stopped in parallel with a new interface being attached. (or similar race conditions)\n\n\u003e Is there a way to monitor when attach_interface() is finished? For volumes, one can poll the volume\u0027s state. If we extend it to attach_interface(), I think we need to provide guidance to users.\n\nYou can monitor the port binding in neutron as well as the output of `GET /servers/{server_id}/os-interface` from nova API. But I\u0027m not sure how precise these are we need to test.\n\n\u003e The problem with reserve_block_device_name() is, that it takes a lock on {instance.uuid} and is thus blocked by a lot of other operations, including resizes, reboots and the actual volume-attachment. This makes it hang much more often and easier.\n\nYeah. I agree that reserve is not needed any more as we cannot promise what we reserve. On the other hand I\u0027m not sure we can easily relax the lock on actually attaching a volume. E.g. adding a volume (or interface) to the live domain and restarting the VM at the same time will be pretty racy and might lead to inconsistencies.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2a01ba805d1d23fba074c23d880fd77527be9daa","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3ca9b44d_86f33eee","line":29,"in_reply_to":"a6ea4212_69f1184b","updated":"2025-09-04 13:44:41.000000000","message":"Sounds like it already is, but.. yes :)\n\nI also think we might want to keep this spec small and volume focused only as it sounds like any interface attach change would be a different approach.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"41305cf3c051d0589d72603ef2744753471e3245","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a6ea4212_69f1184b","line":29,"in_reply_to":"bc4c1548_0b208c9c","updated":"2025-09-04 09:18:59.000000000","message":"Another API that just came up with synchronous calls is os-hypervisors/detail calling `get_host_uptime()` in the driver for every compute host. Not sure how one would fix this other than disabling the uptime call like e.g. https://github.com/sapcc/nova/commit/686f44c4c65eba6c851c852804e82a3e00309945\n\nShould we track this in some bug instead?","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"6e94023697a8f7b9adf1c040d336826647f83ffa","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"955a437d_2c504bce","line":29,"in_reply_to":"dbc5fa22_68f7f7e7","updated":"2025-09-01 11:54:04.000000000","message":"While `attach_interface()` is actually synchronous, it\u0027s _only_ blocked by slow backends, because the lock is taken on `{instance.uuid}-{port.id}`.\n\nIs there a way to monitor when `attach_interface()` is finished? For volumes, one can poll the volume\u0027s state. If we extend it to `attach_interface()`, I think we need to provide guidance to users.\n\nThe problem with `reserve_block_device_name()` is, that it takes a lock on `{instance.uuid}` and is thus blocked by a lot of other operations, including resizes, reboots and the actual volume-attachment. This makes it hang much more often and easier.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d7bcb9bf2c1d89e0e342bf89ca005bda69c09a35","unresolved":true,"context_lines":[{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The attach volume API is one of those blocking APIs that currently involves"},{"line_number":28,"context_line":"the API waiting both for the reserve-block-device RPC call to complete, as well"},{"line_number":29,"context_line":"as the actual attachment to the guest. Both of these round-trips to the compute"},{"line_number":30,"context_line":"service can be slow if the compute service is busy, and the attach call can be"},{"line_number":31,"context_line":"further delayed by the volume service (Cinder) or the backend (Ceph, NFS, etc)."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"811540d7_81bcf1e9","line":29,"in_reply_to":"e83a93c2_ddecac0a","updated":"2025-09-02 13:55:03.000000000","message":"Ack, based on my convo with amorin on IRC I thought it was asserted that attach was synchronous, so I didn\u0027t check. I suppose it\u0027s just the reserve call that is holding up the actual HTTP response that was being noticed.\n\nAs noted below, we do return a sensible value per virt driver now, it\u0027s just not guaranteed to be the same one as in the guest. But it is both (a) consistent for the disk_bus in use and (b) usually (IME) going to be correct unless you have more complicated stuff going on in the guest. That\u0027s not an argument not to do something here, but I think it is an argument not to just always return something stupid like \"/dev/sdb\" when the old microversion is used.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"6e94023697a8f7b9adf1c040d336826647f83ffa","unresolved":true,"context_lines":[{"line_number":60,"context_line":"immediately. The user can poll for completion of the work by looking for the"},{"line_number":61,"context_line":"volume attachment to be visible in the instance details."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":".. note:: This probably not as good as before becuse we\u0027ll create the attachment"},{"line_number":64,"context_line":"  before we have actually started the attach to the guest in the virt driver,"},{"line_number":65,"context_line":"  and before the return of that call means that we\u0027ve done that."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e55afefd_c863033f","line":63,"updated":"2025-09-01 11:54:04.000000000","message":"type: becuse","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"6e94023697a8f7b9adf1c040d336826647f83ffa","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d4338bf4_7500dc37","line":118,"updated":"2025-09-01 11:54:04.000000000","message":"Needs to be updated for gibi\u0027s note: end-users currently already have to poll, because the attach itself is ansynchronous. They get info back, though: volume-id, server-id, the _device_, a tag and the delete_on_termination flag.\n\nIf we can\u0027t ensure _device_ anyways, then we should rather drop that in a new API version and thus could also drop the only synchronous part of the volume-attachment call.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"ec0d12a6a7f4e84ae2624a47fe12c32db4dc6416","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"592377c9_4ccebbd6","line":118,"updated":"2025-09-05 08:37:11.000000000","message":"One problem with this approach is, that the BlockDeviceMapping currently gets created synchronously and nova-api can return an error when there is already an entry for this (Instance, Volume) in the DB:\nhttps://github.com/openstack/nova/blob/9f156aa954fb57eeaf407cc13a0f782b8af1a5d3/nova/compute/manager.py#L8054-L8058\n\nWith pushing everything down into nova-conductor, how would users recognize that their attachment failed and it\u0027s just sitting there waiting for a long-running lock? The BDM would never get created and thus no entry will be visible in the volume-attachments.\n\nIf we pre-create the BDM in nova-api, it might become an orphan entry, and we have to make sure to take care of those.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"ec0d12a6a7f4e84ae2624a47fe12c32db4dc6416","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"73c89bc9_826eb1e6","line":118,"in_reply_to":"0aad1fea_820dcc78","updated":"2025-09-05 08:37:11.000000000","message":"You made a great argument for not needing a volume id, but the main question \"Do we expect there to be a workflow that relies on the first two letters?\" is still open.\n\nIf yes, we need to provide at least that - which arguably might not need a lock on the instance and maybe can even be done in nova-api.\n\nCan we have drivers expose a capability that we check, so we know if we need to reserve something? I guess this solves the problem for all in-tree drivers but leaves out-of-tree drivers open for the same problem then - without a solution. So best not do that either. Oh and I just saw that you mentioned this already under \"alternatives\".\n\nBut in the end it boils down to \"Do we want to support drivers that can predict the device name in the Instance?\". Your answer, as I understood it, is: yes. Then, indeed, we don\u0027t have to change this paragraph. We might want to document this as a driving factor for the decision, though :)","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2a01ba805d1d23fba074c23d880fd77527be9daa","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0aad1fea_820dcc78","line":118,"in_reply_to":"45c0a0e5_ca4d0a13","updated":"2025-09-04 13:44:41.000000000","message":"\u003e Does Nova support out-of-tree drivers? I thought we don\u0027t :) - then that argument doesn\u0027t matter.\n\nNo we don\u0027t, and I understand that it\u0027s easy for us to say that _currently_ it\u0027s not required to be called -- that\u0027s why I suggested it as an optimization. I\u0027m just saying that I don\u0027t love the inconsistency and could foresee a future where someone adds something there which actually reserves something that we don\u0027t realize is only being called some of the time.\n\n\u003e I see the point with \"at least the first to letters are correct\", but is that helping any user? Wouldn\u0027t they consume volumes through /dev/disks/by-id anyways to match against volume UUIDs?\n\nMaybe you do, and that makes the most sense in certain circumstances. In one of my own workflows, I can reliably go for /dev/sdb as the volume attached to a guest without needing to pass the volume ID to that guest in order to do the work. I don\u0027t look at the result of the attach to find that (because I know it could be wrong) but I also know that it will reliably always be /dev/sdb, at least with my current image. In fact, in most cases where the workload runs mostly independently I prefer not to have to tell it the volume ID, especially since it can change.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":26250,"name":"Johannes Kulik","email":"johannes.kulik@sap.com","username":"jkulik"},"change_message_id":"41305cf3c051d0589d72603ef2744753471e3245","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"45c0a0e5_ca4d0a13","line":118,"in_reply_to":"62997701_1ceea680","updated":"2025-09-04 09:18:59.000000000","message":"Does Nova support out-of-tree drivers? I thought we don\u0027t :) - then that argument doesn\u0027t matter.\n\nI see the point with \"at least the first to letters are correct\", but is that helping any user? Wouldn\u0027t they consume volumes through /dev/disks/by-id anyways to match against volume UUIDs?","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d7bcb9bf2c1d89e0e342bf89ca005bda69c09a35","unresolved":true,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":"End users who currently rely on the attach-volume API to wait for the volume"},{"line_number":117,"context_line":"to be attached to the guest will need to poll for completion of the work by"},{"line_number":118,"context_line":"looking for the volume attachment to be visible in the instance details."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Performance Impact"},{"line_number":121,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"62997701_1ceea680","line":118,"in_reply_to":"d4338bf4_7500dc37","updated":"2025-09-02 13:55:03.000000000","message":"The result is not guaranteed for existing drivers, but there\u0027s still a response that at least matches the hypervisor. In the libvirt case it *does* at least match the `disk_bus` that is in use. If we literally stop making that call then we have to have the API make up something to return in the older microversions which seems unideal to me.\n\nI suppose one could argue that we could just not call reserve if the new microversion is in use and not delegate to conductor, but that means that compute will see a difference in behavior depending on which microversion is in use. That may not be a problem for our in-tree drivers but it seems less ideal than consistency.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"98bb2f95d0a7ea4df8bc39ec564e2e134c94e10c","unresolved":true,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"This work is related to the eventlet deprecation effort, and thus should be"},{"line_number":161,"context_line":"considered a parallel effort to address issues that are being created by]"},{"line_number":162,"context_line":"changing the only available deployment model we allow."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Work Items"},{"line_number":165,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2398f784_027539be","line":162,"updated":"2025-08-30 10:02:02.000000000","message":"Are we even sure that this is eventlet related?\nI mean, this issue was existing even before the eventlet removal thing started?","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d7bcb9bf2c1d89e0e342bf89ca005bda69c09a35","unresolved":true,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"This work is related to the eventlet deprecation effort, and thus should be"},{"line_number":161,"context_line":"considered a parallel effort to address issues that are being created by]"},{"line_number":162,"context_line":"changing the only available deployment model we allow."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Work Items"},{"line_number":165,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2b1897f7_74f81aa5","line":162,"in_reply_to":"2398f784_027539be","updated":"2025-09-02 13:55:03.000000000","message":"The starvation of other API threads should not be a problem under eventlet, whereas in real WSGI mode it is. Aren\u0027t you the one that confirmed that when I asked? Also, IIRC Johannes said they are still running standalone eventlet mode for exactly this reason.\n\nSo no, this is not eventlet-related, but this will be a problem for more people as we start to remove eventlet as a deployment option.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"ffd01227dafb464794b9856c5071bff705810f48","unresolved":true,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"This work is related to the eventlet deprecation effort, and thus should be"},{"line_number":161,"context_line":"considered a parallel effort to address issues that are being created by]"},{"line_number":162,"context_line":"changing the only available deployment model we allow."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Work Items"},{"line_number":165,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d1aad351_a70ca501","line":162,"in_reply_to":"2b1897f7_74f81aa5","updated":"2025-09-03 09:25:34.000000000","message":"My apologize, totally agree with your statement. I was just wondering why this sentence was there, because for me, most of the deployments were already using WSGI mode.","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"00042ddf395214edff1e83724f43045f5bd5fa94","unresolved":true,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"This work is related to the eventlet deprecation effort, and thus should be"},{"line_number":161,"context_line":"considered a parallel effort to address issues that are being created by]"},{"line_number":162,"context_line":"changing the only available deployment model we allow."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Work Items"},{"line_number":165,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6c55369a_251380d9","line":162,"in_reply_to":"d1aad351_a70ca501","updated":"2025-09-03 13:30:52.000000000","message":"I\u0027m not sure we know that. IIRC kolla only recently switched their config over. Either way, we know of at least one deployer still using eventlet mode as a result of this, so I assume there are more. We can certainly soften this language, but I put it here to try to tie this to a priority effort so it would get attention :)","commit_id":"9135a8adbe874f32ccf5488efb274682d4c30df3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e307eecb0825077a42f2955f31271930a821de6d","unresolved":true,"context_lines":[{"line_number":146,"context_line":"-----------"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Primary assignee:"},{"line_number":149,"context_line":"  \u003claunchpad-id or None\u003e"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"Other contributors:"},{"line_number":152,"context_line":"  \u003claunchpad-id or None\u003e"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6c2cf65a_90506a08","line":149,"updated":"2025-11-14 14:51:37.000000000","message":"@johannes.kulik@sap.com if you\u0027re going to work on this, please update this spec with your username here and remove the WIP. You can add me (danms) under \"other contributors\" for review.","commit_id":"64cb9716b4d0b10f12c3cfb0f15b0cb8bd4e73a0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ffb50bc2f7f99ba72d0668167d75e93cc40c1949","unresolved":false,"context_lines":[{"line_number":60,"context_line":"current attach-volume workflow to the conductor task api and cast or call based"},{"line_number":61,"context_line":"on the microversion used. In the async case, the user can retrieve the expected"},{"line_number":62,"context_line":"block device name the synchronous API call would have returned by retrieving it"},{"line_number":63,"context_line":"from the instance\u0027s volume-attachments."},{"line_number":64,"context_line":"Like before, the user needs to poll for completion of the attachment by waiting"},{"line_number":65,"context_line":"for the volume\u0027s state in Cinder to change to `in-use`."},{"line_number":66,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"f98f80a0_f3216542","line":63,"updated":"2025-12-03 17:50:10.000000000","message":"++","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ffb50bc2f7f99ba72d0668167d75e93cc40c1949","unresolved":false,"context_lines":[{"line_number":62,"context_line":"block device name the synchronous API call would have returned by retrieving it"},{"line_number":63,"context_line":"from the instance\u0027s volume-attachments."},{"line_number":64,"context_line":"Like before, the user needs to poll for completion of the attachment by waiting"},{"line_number":65,"context_line":"for the volume\u0027s state in Cinder to change to `in-use`."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"The `_attach_volume()` method in the current `compute/api.py` will be moved to"},{"line_number":68,"context_line":"the conductor task API, reachable over RPC. The API will make this delegating"}],"source_content_type":"text/x-rst","patch_set":5,"id":"45a56b47_77e2eeda","line":65,"updated":"2025-12-03 17:50:10.000000000","message":"indeed","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ffb50bc2f7f99ba72d0668167d75e93cc40c1949","unresolved":false,"context_lines":[{"line_number":67,"context_line":"The `_attach_volume()` method in the current `compute/api.py` will be moved to"},{"line_number":68,"context_line":"the conductor task API, reachable over RPC. The API will make this delegating"},{"line_number":69,"context_line":"call to conductor for the older microversion and cast for the new one,"},{"line_number":70,"context_line":"returning the appropriate content and response code in each case."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. note:: There is also an attach workflow for shelved_offloaded state which"},{"line_number":73,"context_line":"  must be considered. It talks to cinder, so it may be a candidate for moving"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a1fdf7b_75960875","line":70,"updated":"2025-12-03 17:50:10.000000000","message":"that\u0027s an implementation detail, but sure.","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ffb50bc2f7f99ba72d0668167d75e93cc40c1949","unresolved":false,"context_lines":[{"line_number":114,"context_line":"device name in the guest will have to retrieve that information separately from"},{"line_number":115,"context_line":"the os-volume_attachments API. This might require polling or waiting for the"},{"line_number":116,"context_line":"volume-attachment to complete, because the information will not be immediately"},{"line_number":117,"context_line":"available after the attach-volume API call finishes."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Performance Impact"},{"line_number":120,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"202f209c_bddde672","line":117,"updated":"2025-12-03 17:50:10.000000000","message":"++","commit_id":"435fc7159733a103e6b62009355ebbb3a70acf3b"}]}