)]}'
{"/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":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":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":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"}]}