)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"ba0b22b1acde880ad540af4975c6533de019c6c8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1b3cc28c_566a861a","updated":"2024-04-16 09:10:50.000000000","message":"I resubmitted this one from 2023.02 (https://review.opendev.org/c/openstack/cinder-specs/+/868761) as per comment from Rajat (https://review.opendev.org/c/openstack/cinder-specs/+/868761/comments/1de2164e_bcd2673a).\n\nThere are two edits:\n\n1. I added the use caes of SHELVED_OFFLOADED instances blocking volume backups currently.\n\n2. I looked at all the open nits from the former submission and fixed them (typos, `` instead of `, ...)","commit_id":"fbd1167d699d7f17af11eae0b48ef77b685f7c60"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"11cb1d8bbd9a3669bc19ed96dbe448a2370f52f2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fb203698_1959babb","updated":"2024-05-17 22:20:49.000000000","message":"A few questions inline.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@purestorage.com","username":"sdodsley"},"change_message_id":"a7e3ea3186958976c35ed1daa4f9772ecc05710b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"155892d9_a5761c0d","updated":"2026-06-25 13:50:40.000000000","message":"If you still want to continue this spec, please move it to 2026.2.\nI took a look at the current master branch and added comments as well.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"84053b34b9611298044862b6383e7c1b6749078a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ae20aa41_e1f424e6","updated":"2024-06-08 16:14:21.000000000","message":"Leaving a -1 to get some attention to my questions.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9675860600a1dd44b215b01f7a3d1fd8c8dbe53d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"25fe3652_fec7fc32","updated":"2024-06-20 12:24:42.000000000","message":"Replies inline.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"0c4ad662ee5b9e741892057fade638a6beada89e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2c5f2475_923ca8e6","updated":"2024-06-10 13:19:43.000000000","message":"Thanks Brian for your time to work through this spec!","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":38081,"name":"Anthony Galica","display_name":"agalica","email":"anthony.galica@hitachivantara.com","username":"agalica","status":"Hitachi Vantara"},"change_message_id":"9b6c41ab2eaba68b03b4b2c01fbf917b3760b0cb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b39be373_12c55629","updated":"2025-12-05 15:00:08.000000000","message":"This seems like it would be a welcome change.  Like Brian, I suspect there\u0027s probably a \"start backup\" that would still need to be in the volume status that blocks some operations that would normally be allowed during a backup.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"}],"specs/2024.2/dedicated-volume-backup-status-field.rst":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"11cb1d8bbd9a3669bc19ed96dbe448a2370f52f2","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"16513f57_ad32890c","line":84,"updated":"2024-05-17 22:20:49.000000000","message":"I wonder whether we need to keep \"backing-up\" as a regular volume status (in addition to a value for backup_status) to account for the interval after a backup has been requested and when we want the volume to be available for other purposes.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"0c4ad662ee5b9e741892057fade638a6beada89e","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"74ae16c8_14a83ddb","line":84,"in_reply_to":"16513f57_ad32890c","updated":"2024-06-10 13:19:43.000000000","message":"Having the backup status on the volume status field defies the purpose of externalizing the backup status. The idea is to actually ALLOW more things to happen to a volume (e.g. re-attachment, ....) even WHILE a backup (or restore) is in progress.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":38081,"name":"Anthony Galica","display_name":"agalica","email":"anthony.galica@hitachivantara.com","username":"agalica","status":"Hitachi Vantara"},"change_message_id":"9b6c41ab2eaba68b03b4b2c01fbf917b3760b0cb","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"20b9b34b_ce877f70","line":84,"in_reply_to":"1d1ad75c_045531d5","updated":"2025-12-05 15:00:08.000000000","message":"I think Brian\u0027s comment definitely has merit.  Creating the snapshot or clone would probably fall into this \"preparing backup\" category?","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"11b1ee0e833722a40523f379ba08c14fca0244f0","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"828658d3_a3420a6f","line":84,"in_reply_to":"20b9b34b_ce877f70","updated":"2025-12-08 12:22:59.000000000","message":"\u003e I think Brian\u0027s comment definitely has merit.  Creating the snapshot or clone would probably fall into this \"preparing backup\" category?\n\nWhy? \n\nCreating a snapshot is in all modern storage systems completely decoupled from the other volume use (read/write/attach/detach/...). The one aspect some people usually want to avoid is to snapshot a mounted filesystem. But this is one layer above the \"block device\" that is a what we call a volume. That\u0027s why snapshots are usually \"forced\", so they ignore that the volume is currently attached. But since most filesystems are of the journaling kind nowadays, a clean consistent point in time snapshot does NOT corrupt as filesystem anymore.\n\n\nThe sole idea of this proposal is to fully decouple the lifecycle of backups from those of the volumes (apart from deletion maybe, as that would (depending on storage implementation used) also kill the snapshot used as backup source.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"b2e306ac66aaf4c0a47a68cc29da0717257d9619","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1d1ad75c_045531d5","line":84,"in_reply_to":"42514666_c5fc2dc6","updated":"2025-03-03 13:34:16.000000000","message":"I\u0027ve been looking an issue related to this as well after multiple end-users complaining that issuing a resize of an instance while a volume is backing-up has caused their instance resize to fail, instance powered off and cannot be recovered other than by a cloud admin.\n\nI initially thought this was something that could be fixed in Nova [1] but was then made aware this should probably be handled in Cinder [2] and was then linked to this spec.\n\nBack on-topic...\n\nWhat is complicated about the interaction between services here is that a race condition between any kind of check on the status and a request to performs a operation (for example from Nova to Cinder in this case) can cause this issue even if we move to backup_status. And having the backup_status is something we need but we also need to ensure we allow Nova to perform actions and preserving backing-up volume status would give the same issue so we\u0027d need to add some kind of retry logic client-side.\n\nBad: If INSTANCE1 has VOLUME1 with volume status `backing-up` a resize on INSTANCE1 should still allow attachments to be created/updated [2] OR we should return something like 503 Service Unavailable and let cinderclient or Nova directly to retry the action with a backoff mechanism, but it feels like a bad way to update volume status to backing-up and Cinder should instead internally know what is allowed based on backup_status field.\n\nGood: Instead the best way is when we have INSTANCE1 has VOLUME1 with volume status `in-use` and backup_status `backing-up` a resize on INSTANCE1 should allow attachments to be handled because it\u0027s allowed when in-use, if Cinder need to ensure some operations need to wait or is not allowed when backup_status is something like `preparing-backup` (or whatever could be used during setup phase) that should be handled separately from volume status to know have Nova handle edge cases (in-use is therefore always the volume status during lifetime and does not change for third party services like Nova unless it\u0027s actually detached back to available)\n\n[1] https://bugs.launchpad.net/nova/+bug/2077512\n[2] https://review.opendev.org/c/openstack/cinder/+/943176","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9675860600a1dd44b215b01f7a3d1fd8c8dbe53d","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"42514666_c5fc2dc6","line":84,"in_reply_to":"74ae16c8_14a83ddb","updated":"2024-06-20 12:24:42.000000000","message":"I wasn\u0027t clear.  What I mean is, is there a short period of time when some stuff has to happen to *prepare* the backup?  So what would happen would be:\n\n1. user requests backup\n2. cinder puts the volume in \"backing-up\" status and backup_status to \"backing-up\"; volume can\u0027t be used for other stuff while cinder does whatever it needs to do get the backup ready to start\n3. cinder puts the volume back to previous status, backup_status remains \"backing-up\" as the backup continues\n\nSo the question is do we need a brief \"lock\" on the volume before we allow other things to happen to it?","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@purestorage.com","username":"sdodsley"},"change_message_id":"a7e3ea3186958976c35ed1daa4f9772ecc05710b","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6f2a870e_ffcf8ea1","line":84,"in_reply_to":"7cdd1ed2_ba649b2b","updated":"2026-06-25 13:50:40.000000000","message":"I dug into master to ground this. Today the volume is flipped to backing-up synchronously in backup/api.py (create(), the volume_update to backing-up) and stays there through temp-snapshot/clone creation in get_backup_device and the whole data transfer, only reverting in finish_backup. So the prep work Brian/Anthony are asking about currently lives inside the backing-up window.\n\nThe good news for Christian\u0027s position: the temp snapshot/clone is created by the driver directly in get_backup_device, so it doesn\u0027t actually rely on the volume status field as a lock. So I don\u0027t think we need to retain backing-up in status — but the spec shouldn\u0027t hand-wave this with \"most usually depend on status values that remain.\" Please add an explicit per-operation matrix (attach/detach, extend, retype, migrate, delete, transfer) stating what each one\u0027s guard becomes once backing-up no longer lives in status, and confirm the temp-snapshot path is safe to run while the volume is concurrently attached/resized. That answers Tobias\u0027s race-condition concern directly: the gating moves from the single status field to explicit backup_status checks inside Cinder.\n\nTwo things I verified that would sharpen the spec: (1) snapshot-based backups already decouple — when snapshot_id is given the API sets the snapshot to backing-up and never touches the volume status, so the lockout only affects the default volume-backup path; worth noting to scope this. (2) The SHELVED_OFFLOADED use case (L59-60) isn\u0027t actually solved here — those volumes are reserved, and create() only accepts available/in-use; reserved is a real volume status, not a backup status, so splitting out backup_status doesn\u0027t make them backup-able. Please drop it or explain the separate fix.\n\nAlso: restore (restoring-backup) is destructive to volume contents, so please state explicitly that backup_status \u003d restoring-backup keeps gating the same operations it gates today — decoupling restore the same way as backup would be unsafe.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"fc56d8ea861036bd5b65461a3176ed1c7d5a4f67","unresolved":true,"context_lines":[{"line_number":81,"context_line":"is no backup related status for this volume.)"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Those shall then be removed from the list of (valid) values of ``status``"},{"line_number":84,"context_line":"and be values for ``backup_status``."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"There will be some changes to the conditional checks for certain tasks to be"},{"line_number":87,"context_line":"started, but most usually depend on those volume status values that would remain"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7cdd1ed2_ba649b2b","line":84,"in_reply_to":"828658d3_a3420a6f","updated":"2025-12-08 12:25:28.000000000","message":"Sorry to clarify what I said about the \"forcing\" ... this again is a mechanism (not allowing backups of an attached volume) is already in place (thus the mention of the force parameter (see https://docs.openstack.org/cinder/latest/admin/volume-backups.html) which requires the volume to be available when creating a backup (thus a snapshot).","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"11cb1d8bbd9a3669bc19ed96dbe448a2370f52f2","unresolved":true,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"* Reject volume deletion while volume is currently being backed up"},{"line_number":288,"context_line":"* Reject concurrent backups of a volume if one is already in progress"},{"line_number":289,"context_line":"* Reject volume or \"block storage\" migration if a backup is currently running"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Assignee(s)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ad727d03_67758148","line":289,"updated":"2024-05-17 22:20:49.000000000","message":"What\u0027s the plan to handle a volume transfer request?","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"0c4ad662ee5b9e741892057fade638a6beada89e","unresolved":true,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"* Reject volume deletion while volume is currently being backed up"},{"line_number":288,"context_line":"* Reject concurrent backups of a volume if one is already in progress"},{"line_number":289,"context_line":"* Reject volume or \"block storage\" migration if a backup is currently running"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Assignee(s)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f003af6d_6c43ce96","line":289,"in_reply_to":"ad727d03_67758148","updated":"2024-06-10 13:19:43.000000000","message":"While I agree this functionality is not covered in the spec, can you elaborate on your thoughts about it? Intuitively I\u0027d also add this to the list of actions to \"reject\" while a backup is running. This I believe would maintain the current restrictions and workflow.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@purestorage.com","username":"sdodsley"},"change_message_id":"a7e3ea3186958976c35ed1daa4f9772ecc05710b","unresolved":true,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"* Reject volume deletion while volume is currently being backed up"},{"line_number":288,"context_line":"* Reject concurrent backups of a volume if one is already in progress"},{"line_number":289,"context_line":"* Reject volume or \"block storage\" migration if a backup is currently running"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Assignee(s)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"6a566a2c_5558e5bf","line":289,"in_reply_to":"ba7b070f_538a089b","updated":"2026-06-25 13:50:40.000000000","message":"Confirmed against master: transfer/api.py create() rejects anything where volume_ref[\u0027status\u0027] !\u003d \"available\". So today a backing-up volume can\u0027t be transferred purely as a side effect of it not being available. Once backup state moves out of status, the volume stays available during a backup and transfer would silently become allowed. Since we agree the behavior should stay \"reject\", the Implementation section currently lists only delete / concurrent-backup / migration — please add volume transfer to that list of restrictions to preserve, with an explicit backup_status check (the transfer code only looks at volume status today).","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9675860600a1dd44b215b01f7a3d1fd8c8dbe53d","unresolved":true,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"* Reject volume deletion while volume is currently being backed up"},{"line_number":288,"context_line":"* Reject concurrent backups of a volume if one is already in progress"},{"line_number":289,"context_line":"* Reject volume or \"block storage\" migration if a backup is currently running"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Assignee(s)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba7b070f_538a089b","line":289,"in_reply_to":"f003af6d_6c43ce96","updated":"2024-06-20 12:24:42.000000000","message":"I don\u0027t think we need any special handling; I agree with \"reject\".  Just want to make sure this is mentioned because I imagine the current transfer code only looks at the volume status.","commit_id":"51c6683fa1ea639d6c1cf58ba86d73284344976b"}]}