)]}'
{"specs/pike/approved/cinder-new-attach-apis.rst":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d58ec19a588ff39365075b5d5a75674abd87608f","unresolved":false,"context_lines":[{"line_number":117,"context_line":"  otherwise we fall back to the old detach flow. The new flow is..."},{"line_number":118,"context_line":"* (api) usual checks to see if request is valid"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"  * We can most likely remove the ``nova.volume.cinder.API.check_detach``"},{"line_number":121,"context_line":"    method since performs state validation on the volume that is also checked"},{"line_number":122,"context_line":"    in Cinder when we call ``begin_detaching``, and we should have Cinder"},{"line_number":123,"context_line":"    perform the atomic state validation checks since it is the source of truth."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f287b81_9d68a187","line":120,"updated":"2017-08-24 16:16:47.000000000","message":"FWIW, this was removed in Pike: https://review.openstack.org/#/c/446671/","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"d21b5b3d8c31041480c8fb17ac6c9fa33f7f3290","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  * We can most likely remove the ``nova.volume.cinder.API.check_detach``"},{"line_number":121,"context_line":"    method since performs state validation on the volume that is also checked"},{"line_number":122,"context_line":"    in Cinder when we call ``begin_detaching``, and we should have Cinder"},{"line_number":123,"context_line":"    perform the atomic state validation checks since it is the source of truth."},{"line_number":124,"context_line":"  * The ``begin_detaching`` API in Cinder is currently scoped only to the"},{"line_number":125,"context_line":"    volume but we will likely need a similar API for volume attachments. To"},{"line_number":126,"context_line":"    help illustrate this, consider that we have a volume with multiple"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_09cad69f","line":123,"updated":"2017-04-27 15:49:40.000000000","message":"Nit: nit to mention this avoids two API callers thinking they are detaching the same volume.","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"01a8f9a8502e7d39f8c992fe874e3ae2a3befda4","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    ``os-detach`` is called on the volume it will put the volume status back"},{"line_number":130,"context_line":"    into `in-use` state because of the remaining attachment. This is a"},{"line_number":131,"context_line":"    confusing state transition for the caller. Therefore we will likely need a"},{"line_number":132,"context_line":"    ``begin_detaching`` method for attachments. That way if we have multiple"},{"line_number":133,"context_line":"    attachments, the state transitions will work like this:"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_ae6be81b","line":132,"range":{"start_line":132,"start_character":4,"end_line":132,"end_character":46},"updated":"2017-04-27 15:37:38.000000000","message":"So in case we don\u0027t want multiple detaching happening at the same time, \u0027begin_detaching\u0027 would likely need to change the attachment status to \u0027detaching\u0027 and whenever it\u0027s called check the status of all attachments to see whether it\u0027s safe to start a new detach process, right?","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"350334bc34ef59e59f2e164aa226cd3d16c0ceb0","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    ``os-detach`` is called on the volume it will put the volume status back"},{"line_number":130,"context_line":"    into `in-use` state because of the remaining attachment. This is a"},{"line_number":131,"context_line":"    confusing state transition for the caller. Therefore we will likely need a"},{"line_number":132,"context_line":"    ``begin_detaching`` method for attachments. That way if we have multiple"},{"line_number":133,"context_line":"    attachments, the state transitions will work like this:"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_d4b342e8","line":132,"range":{"start_line":132,"start_character":4,"end_line":132,"end_character":46},"in_reply_to":"5ff73747_89e4a63d","updated":"2017-04-28 14:51:01.000000000","message":"I think it\u0027s independent from the attachment_id in the sense of having multiple detach requests handled for the same volume in parallel. This all comes into question for multi-attach, before that it\u0027s not really relevant as we have only one attachment/connection. And it also becomes more important for multi-attach when the last two attachments are requested to delete at roughly the same time. So my conclusion is that I would keep this on volume level.","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"d21b5b3d8c31041480c8fb17ac6c9fa33f7f3290","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    ``os-detach`` is called on the volume it will put the volume status back"},{"line_number":130,"context_line":"    into `in-use` state because of the remaining attachment. This is a"},{"line_number":131,"context_line":"    confusing state transition for the caller. Therefore we will likely need a"},{"line_number":132,"context_line":"    ``begin_detaching`` method for attachments. That way if we have multiple"},{"line_number":133,"context_line":"    attachments, the state transitions will work like this:"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_89e4a63d","line":132,"range":{"start_line":132,"start_character":4,"end_line":132,"end_character":46},"in_reply_to":"5ff73747_ae6be81b","updated":"2017-04-27 15:49:40.000000000","message":"So we would need to start passing the attachment_id, instead of just the instance_id to do that. I am not against that, but that API doesn\u0027t exist yet, we deleted it from the spec where it was proposed I think","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"aaa8ea42741a19b5b1daef80bb32e2b3e3bde1fe","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    ``os-detach`` is called on the volume it will put the volume status back"},{"line_number":130,"context_line":"    into `in-use` state because of the remaining attachment. This is a"},{"line_number":131,"context_line":"    confusing state transition for the caller. Therefore we will likely need a"},{"line_number":132,"context_line":"    ``begin_detaching`` method for attachments. That way if we have multiple"},{"line_number":133,"context_line":"    attachments, the state transitions will work like this:"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f013ff3_93fd593c","line":132,"range":{"start_line":132,"start_character":4,"end_line":132,"end_character":46},"in_reply_to":"5ff73747_d4b342e8","updated":"2017-05-16 10:07:34.000000000","message":"But the copy on the Nova side is happening between two specific attachments, it seems wrong to skip that here.\n\nNow if we ignore multi-attach for these operations, we could use the existing API, when there is only a single attachment... but thats leaving some tech debt for later. Which is OK, but this seems very attachment specific to me.","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"d21b5b3d8c31041480c8fb17ac6c9fa33f7f3290","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"},{"line_number":136,"context_line":"       attachment2 is `attached` status; compute deletes attachment1, volume"},{"line_number":137,"context_line":"       status is unchanged (remains `in-use`)."},{"line_number":138,"context_line":"    2. begin_detaching(attachment2): volume status changes to `detaching` since"},{"line_number":139,"context_line":"       the last attachment is now `detaching`; compute deletes attachment2,"},{"line_number":140,"context_line":"       volume status changes to `available`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ff73747_293eb28b","line":137,"updated":"2017-04-27 15:49:40.000000000","message":"So this removes the protection we had for API users calling detach twice and causing strange problems. Given the locking in nova-compute, we are probably fine, its just a bit odd to loose the protection we had previously.","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"be090775f06e7b0a198d4b5ecfa51e2feb9aa4a6","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    1. begin_detaching(attachment1): volume status is still `in-use` because"},{"line_number":136,"context_line":"       attachment2 is `attached` status; compute deletes attachment1, volume"},{"line_number":137,"context_line":"       status is unchanged (remains `in-use`)."},{"line_number":138,"context_line":"    2. begin_detaching(attachment2): volume status changes to `detaching` since"},{"line_number":139,"context_line":"       the last attachment is now `detaching`; compute deletes attachment2,"},{"line_number":140,"context_line":"       volume status changes to `available`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f287b81_7de97518","line":137,"in_reply_to":"5ff73747_293eb28b","updated":"2017-08-24 16:14:14.000000000","message":"I\u0027m not following your concern. The point of this is to not have a window where the volume is in \u0027detaching\u0027 state but actually has another attachment, so it\u0027s fixing a problem of the volume state going from in-use-\u003edetaching-\u003ein-use.","commit_id":"e2250402f4f22e0d76d0359dcdd61493556b6443"}]}