)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8b22026795456818fc8f287ebf498d5ef9a51697","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Co-Authored-By: Andrea Rosa \u003candrea.rosa@hpe.com\u003e"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"blueprint detach-boot-volume"},{"line_number":20,"context_line":"Previously-approved: Ocata"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Change-Id: Ide993b5ee0dba08b0ed9d641f6b96b344bb14f27"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3f79a3b5_65e27003","line":19,"range":{"start_line":19,"start_character":10,"end_line":19,"end_character":28},"updated":"2018-09-07 20:33:47.000000000","message":"The spec filename needs to match this.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Co-Authored-By: Andrea Rosa \u003candrea.rosa@hpe.com\u003e"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"blueprint detach-boot-volume"},{"line_number":20,"context_line":"Previously-approved: Ocata"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Change-Id: Ide993b5ee0dba08b0ed9d641f6b96b344bb14f27"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"3f79a3b5_be1dd6bf","line":20,"range":{"start_line":20,"start_character":21,"end_line":20,"end_character":26},"updated":"2018-09-10 16:07:47.000000000","message":"This should actually be: Mitaka, Newton, Ocata","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"08aa53bd85a9169c5751cd2967a164794959fe66","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Co-Authored-By: Andrea Rosa \u003candrea.rosa@hpe.com\u003e"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"blueprint detach-boot-volume"},{"line_number":20,"context_line":"Previously-approved: Ocata"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Change-Id: Ide993b5ee0dba08b0ed9d641f6b96b344bb14f27"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"3f79a3b5_5542546a","line":20,"range":{"start_line":20,"start_character":21,"end_line":20,"end_character":26},"in_reply_to":"3f79a3b5_be1dd6bf","updated":"2018-09-11 01:41:00.000000000","message":"Done","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"05d74db7e387d3056f8b580e2f3b54890b7ac7f5","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Co-Authored-By: Andrea Rosa \u003candrea.rosa@hpe.com\u003e"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"blueprint detach-boot-volume"},{"line_number":20,"context_line":"Previously-approved: Mitaka,Newton,Ocata"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Change-Id: Ide993b5ee0dba08b0ed9d641f6b96b344bb14f27"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3f79a3b5_50992d1b","line":20,"updated":"2018-10-03 20:46:15.000000000","message":"This is a bit of a lie at this point if we\u0027re including the wrinkle to detach/attach root volumes on a stopped server. That should at least be noted in the commit message if we are going to try to work that into this spec.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Co-Authored-By: Andrea Rosa \u003candrea.rosa@hpe.com\u003e"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"blueprint detach-boot-volume"},{"line_number":20,"context_line":"Previously-approved: Mitaka,Newton,Ocata"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Change-Id: Ide993b5ee0dba08b0ed9d641f6b96b344bb14f27"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3f79a3b5_6663f746","line":20,"in_reply_to":"3f79a3b5_50992d1b","updated":"2018-10-09 02:01:37.000000000","message":"Yeah, that\u0027s true, what do you think? should we go with the original spec or we should also care about stopped servers as it could also be useful.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"}],"specs/stein/approved/detach-boot-volume-stein.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. A new"},{"line_number":105,"context_line":"boolean field called device_present will be added for this purpose;"},{"line_number":106,"context_line":"device_present \u003d False means the device is missing and cannot be used."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7ff3ca73","line":106,"range":{"start_line":103,"start_character":0,"end_line":106,"end_character":70},"updated":"2018-09-09 19:13:56.000000000","message":"Is this necessary? Could we not just leave it as type\u003dvolume but without an attachment or something like that?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8bd42eda5462339b2f250fc12f82b105a2292701","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. A new"},{"line_number":105,"context_line":"boolean field called device_present will be added for this purpose;"},{"line_number":106,"context_line":"device_present \u003d False means the device is missing and cannot be used."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_09661957","line":106,"range":{"start_line":103,"start_character":0,"end_line":106,"end_character":70},"in_reply_to":"3f79a3b5_37eb3279","updated":"2018-09-10 14:49:54.000000000","message":"I\u0027m not sure what you\u0027re getting at here.\n\nBefore you were suggesting that we delete the BDM record and then create an empty one with device_present\u003dFalse, right?\n\nSo, why couldn\u0027t we, in the case of detach root during shelve, just remove the attachment_id from the BDM record, but leave the other bits in place? Then on attach in shelve, we look for that record and re-attach.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"2e40cb6c179d08cb01eb39760fc4e94fa8528bf6","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. A new"},{"line_number":105,"context_line":"boolean field called device_present will be added for this purpose;"},{"line_number":106,"context_line":"device_present \u003d False means the device is missing and cannot be used."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_bd25eac0","line":106,"range":{"start_line":103,"start_character":0,"end_line":106,"end_character":70},"in_reply_to":"3f79a3b5_7ff3ca73","updated":"2018-09-10 02:44:20.000000000","message":"yes, that could work","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"a73052a6424fca7bb76015090ad0c92058180e3f","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. A new"},{"line_number":105,"context_line":"boolean field called device_present will be added for this purpose;"},{"line_number":106,"context_line":"device_present \u003d False means the device is missing and cannot be used."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_37eb3279","line":106,"range":{"start_line":103,"start_character":0,"end_line":106,"end_character":70},"in_reply_to":"3f79a3b5_bd25eac0","updated":"2018-09-10 08:55:40.000000000","message":"After some checking and thinking, I think this part is not correct, in the detach then attach case, the bdm record will be gone and we should have a way to create a new bdm record indicating it is the root volume. And we forbid unshelve an instance without root volume. The design here is more like a swap case, which we just update the attachment id.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":106,"context_line":"device_present \u003d False means the device is missing and cannot be used."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":110,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":111,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":112,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_fffefa35","line":109,"range":{"start_line":109,"start_character":45,"end_line":109,"end_character":75},"updated":"2018-09-09 19:13:56.000000000","message":"Unfortunately.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":110,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":111,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":112,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":113,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_bff40256","line":110,"range":{"start_line":110,"start_character":0,"end_line":110,"end_character":44},"updated":"2018-09-09 19:13:56.000000000","message":"Is it? How are you expecting the user to find this externally? By listing the volume attachments? I don\u0027t see that we distinguish that one attachment or another is a root volume. Is there some other way? I didn\u0027t think you could list the BDMs generically with information about that kind of thing, but I could (definitely) be wrong.\n\nJust thinking about this from the outside...I come to a new instance I don\u0027t know anything about and want to shelve it and detach its root volume. I can list attachments, of which there may be several. I could *guess* at which one is root, but I can\u0027t do that reliably. Say I guess right and detach it, then later, how do I come back and ensure that I can attach a volume back in the spot where the root volume was?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8bd42eda5462339b2f250fc12f82b105a2292701","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":110,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":111,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":112,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":113,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_89630942","line":110,"range":{"start_line":110,"start_character":0,"end_line":110,"end_character":44},"in_reply_to":"3f79a3b5_9aecadf5","updated":"2018-09-10 14:49:54.000000000","message":"I\u0027m not sure what you mean by \"swap\" in this case. Are you talking about \"swap volume\" or the special \"swap\" BDM?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"2e40cb6c179d08cb01eb39760fc4e94fa8528bf6","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":110,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":111,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":112,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":113,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7802000b","line":110,"range":{"start_line":110,"start_character":0,"end_line":110,"end_character":44},"in_reply_to":"3f79a3b5_bff40256","updated":"2018-09-10 02:44:20.000000000","message":"I guess we should let user pass in a parameter that indicates he want to attach this volume as root, and then Nova will do the rest then?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"e09235d871673790aca4f13e51935f0b82739e76","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":109,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":110,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":111,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":112,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":113,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_9aecadf5","line":110,"range":{"start_line":110,"start_character":0,"end_line":110,"end_character":44},"in_reply_to":"3f79a3b5_bff40256","updated":"2018-09-10 09:06:13.000000000","message":"In that case, I guess swap is more suitable? as it will be in an atomic API.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":116,"context_line":"block device mapping. An instance will not be allowed to unshelve when"},{"line_number":117,"context_line":"its boot volume has been detached unless another has been attached in its"},{"line_number":118,"context_line":"place."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Alternatives"},{"line_number":121,"context_line":"------------"},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_df88dec6","line":119,"updated":"2018-09-09 19:13:56.000000000","message":"Is there any API impact here for older microversions that might be confused about why it can\u0027t unshelve an instance? Or are you thinking this can all be done without any API changes?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"2e40cb6c179d08cb01eb39760fc4e94fa8528bf6","unresolved":false,"context_lines":[{"line_number":116,"context_line":"block device mapping. An instance will not be allowed to unshelve when"},{"line_number":117,"context_line":"its boot volume has been detached unless another has been attached in its"},{"line_number":118,"context_line":"place."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Alternatives"},{"line_number":121,"context_line":"------------"},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d8123458","line":119,"in_reply_to":"3f79a3b5_df88dec6","updated":"2018-09-10 02:44:20.000000000","message":"Yes, with microversion","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":130,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":131,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"},{"line_number":132,"context_line":"unnecessary to disable it. However, this throws open many more corner cases"},{"line_number":133,"context_line":"in the code and is not needed for the above use cases."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Another alternative is to be more general by allowing any type of boot"},{"line_number":136,"context_line":"device to be removed and any type added. This would include images on local"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_ff835aa7","line":133,"updated":"2018-09-09 19:13:56.000000000","message":"FWIW, I like using shelve as the state where this can happen. I think it removes a lot of issues around the actual host attachment stuff.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"A boolean field called device_present will be added to the BlockDeviceMapping"},{"line_number":154,"context_line":"object and to the block_device_mapping database table. The default value"},{"line_number":155,"context_line":"for this field will be True."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Setting the device_present field to False will indicate that the block"},{"line_number":158,"context_line":"device mapping is a place holder for a missing device and cannot be used."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_bf8962c7","line":155,"updated":"2018-09-09 19:13:56.000000000","message":"Per above, I hope we can do this without the need for a migration and a new flag.","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"2e40cb6c179d08cb01eb39760fc4e94fa8528bf6","unresolved":false,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"A boolean field called device_present will be added to the BlockDeviceMapping"},{"line_number":154,"context_line":"object and to the block_device_mapping database table. The default value"},{"line_number":155,"context_line":"for this field will be True."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Setting the device_present field to False will indicate that the block"},{"line_number":158,"context_line":"device mapping is a place holder for a missing device and cannot be used."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_782be080","line":155,"in_reply_to":"3f79a3b5_bf8962c7","updated":"2018-09-10 02:44:20.000000000","message":"I will look into this","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0e4031e962f725e1ac4b07612e72a5690ff411a8","unresolved":false,"context_lines":[{"line_number":160,"context_line":"REST API impact"},{"line_number":161,"context_line":"---------------"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"There will be no change to the operations or parameters of the REST API."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"An attempt to detach a boot volume currently always returns the error:"},{"line_number":166,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_dfb1be90","line":163,"updated":"2018-09-09 19:13:56.000000000","message":"No change, meaning no new attributes, but the microversion is to signify that detaching from shelve is now possible yeah?","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"a73052a6424fca7bb76015090ad0c92058180e3f","unresolved":false,"context_lines":[{"line_number":160,"context_line":"REST API impact"},{"line_number":161,"context_line":"---------------"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"There will be no change to the operations or parameters of the REST API."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"An attempt to detach a boot volume currently always returns the error:"},{"line_number":166,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_ba8ac961","line":163,"in_reply_to":"3f79a3b5_dfb1be90","updated":"2018-09-10 08:55:40.000000000","message":"yes","commit_id":"b3ca1cd49b98a60e7413f88dcf0a9002c89d9b01"}],"specs/stein/approved/detach-boot-volume.rst":[{"author":{"_account_id":9373,"name":"Vlad Gusev","email":"vlad.esten@gmail.com","username":"s10"},"change_message_id":"af092cb68ac8af25c0c167bff1053967c1952af3","unresolved":false,"context_lines":[{"line_number":14,"context_line":"the boot volume of an instance when the instance is not running. Currently"},{"line_number":15,"context_line":"nova does not allow this at all and some operations assume it does not happen."},{"line_number":16,"context_line":"This spec proposes allowing the detach and attach of boot volumes when an"},{"line_number":17,"context_line":"instance is shelved and adding safeguards to ensure it is safe."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_54426111","line":17,"updated":"2018-09-10 17:17:38.000000000","message":"Do we really need such condition (shelved) as a safeguard? What could be broken if we do anything with powered off volume-backed instances without root boot volume? Power on is safe — instance will just spawn and show \"No bootable device\". Resize/migrate? It also should be safe, if we don\u0027t increase root_gb from 0 to the positive value.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"08aa53bd85a9169c5751cd2967a164794959fe66","unresolved":false,"context_lines":[{"line_number":14,"context_line":"the boot volume of an instance when the instance is not running. Currently"},{"line_number":15,"context_line":"nova does not allow this at all and some operations assume it does not happen."},{"line_number":16,"context_line":"This spec proposes allowing the detach and attach of boot volumes when an"},{"line_number":17,"context_line":"instance is shelved and adding safeguards to ensure it is safe."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_3559d85a","line":17,"in_reply_to":"3f79a3b5_54426111","updated":"2018-09-11 01:41:00.000000000","message":"Yes, I was thinking about that to, maybe we could also do ``SHUTOFF`` instances, shleved instance is easier to do as it doesn\u0027t have to deal with the connection part.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"There is an implicit assumption in the nova code that an instance always has"},{"line_number":23,"context_line":"a cinder boot volume attached or an ephemeral boot disk. Nova allows cinder"},{"line_number":24,"context_line":"volumes to be detached and attached at any time, but the detach operation is"},{"line_number":25,"context_line":"limited to exclude boot volumes to preserve the above assumption."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"This limitation means it is not possible to change the boot volume"},{"line_number":28,"context_line":"attached to an instance except by deleting the instance and creating a new"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_dedf7264","line":25,"range":{"start_line":24,"start_character":49,"end_line":25,"end_character":65},"updated":"2018-09-10 16:07:47.000000000","message":"OK that\u0027s this check:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/api/openstack/compute/volumes.py#L434\n\nMight be good to link to that as a footnote reference since I always have to hunt for it since it\u0027s in the handler code rather than nova.compute.api.API.detach_volume.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"08aa53bd85a9169c5751cd2967a164794959fe66","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"There is an implicit assumption in the nova code that an instance always has"},{"line_number":23,"context_line":"a cinder boot volume attached or an ephemeral boot disk. Nova allows cinder"},{"line_number":24,"context_line":"volumes to be detached and attached at any time, but the detach operation is"},{"line_number":25,"context_line":"limited to exclude boot volumes to preserve the above assumption."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"This limitation means it is not possible to change the boot volume"},{"line_number":28,"context_line":"attached to an instance except by deleting the instance and creating a new"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_952d4cb0","line":25,"range":{"start_line":24,"start_character":49,"end_line":25,"end_character":65},"in_reply_to":"3f79a3b5_dedf7264","updated":"2018-09-11 01:41:00.000000000","message":"Done","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":44,"context_line":"being replicated to volumes at remote site B. The persistent volumes"},{"line_number":45,"context_line":"include boot volumes."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"The use case is the following:"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"  As a cloud user I want to be able to failover my application to a remote"},{"line_number":50,"context_line":"  site with minimal down time and the assurance that the remote site is"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fe46ee22","line":47,"updated":"2018-09-10 16:07:47.000000000","message":"Thinking out loud, is this possible with a multiattach volume? Or not because you need a volume in separate sites / storage backends for DR?","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"54ff6aa56e1addc4d6c29e2f28b7be022c47f25d","unresolved":false,"context_lines":[{"line_number":44,"context_line":"being replicated to volumes at remote site B. The persistent volumes"},{"line_number":45,"context_line":"include boot volumes."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"The use case is the following:"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"  As a cloud user I want to be able to failover my application to a remote"},{"line_number":50,"context_line":"  site with minimal down time and the assurance that the remote site is"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_e0a72050","line":47,"in_reply_to":"3f79a3b5_fe46ee22","updated":"2018-09-11 03:32:46.000000000","message":"This is not the same thing with a multi-attach volume, multi-attach can be used for application HA (the data is shared between multiple vms, so if one fall down we switch the workloads to the backup one; But for VM DR (infrastructure level from application point of view), yes we will need a volume in separate site for DR.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  switchover will be successful."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  Secondly, by removing the virtual infrastructure build from the critical"},{"line_number":77,"context_line":"  path of the failover (steps 3-7), the down time caused by the failover"},{"line_number":78,"context_line":"  is minimised."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"A bug registered against nova describes further use cases (see [1]). An"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_5e104201","line":77,"range":{"start_line":77,"start_character":24,"end_line":77,"end_character":33},"updated":"2018-09-10 16:07:47.000000000","message":"This must be referring to something that\u0027s not in the spec?","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":91,"context_line":"This change assumes that only cinder volumes can be dynamically changed"},{"line_number":92,"context_line":"in this way. We will not support detaching ephemeral disks."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Volume backed instances are always offloaded when shelved, so the instance"},{"line_number":95,"context_line":"will not be on a host. As a result the implementation will be to change"},{"line_number":96,"context_line":"the recorded block device mapping and register the attachment/detachment"},{"line_number":97,"context_line":"with cinder."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fe1d8e10","line":94,"range":{"start_line":94,"start_character":28,"end_line":94,"end_character":34},"updated":"2018-09-10 16:07:47.000000000","message":"Well, after some configurable timeout, sure:\n\nhttps://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.shelved_poll_interval","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":92,"context_line":"in this way. We will not support detaching ephemeral disks."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Volume backed instances are always offloaded when shelved, so the instance"},{"line_number":95,"context_line":"will not be on a host. As a result the implementation will be to change"},{"line_number":96,"context_line":"the recorded block device mapping and register the attachment/detachment"},{"line_number":97,"context_line":"with cinder."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"The usual detach volume API call will be used to detach the boot volume."},{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_3eb22608","line":97,"range":{"start_line":95,"start_character":23,"end_line":97,"end_character":12},"updated":"2018-09-10 16:07:47.000000000","message":"This spec predates the volume attachments API in cinder and nova\u0027s use of it with shelve, so I think we already do this:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/compute/manager.py#L4984\n\nWhat that does is create an \"empty\" volume attachment record in cinder so the volume remains in-use while the instance is not on a host, and deletes the old volume attachment which has the previous host connector information.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8bd42eda5462339b2f250fc12f82b105a2292701","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. We can do"},{"line_number":105,"context_line":"this with a bdm record with ``type\u003dvolume`` and ``attachment_id\u003dNone``."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_49ebb177","line":105,"updated":"2018-09-10 14:49:54.000000000","message":"Ah, yeah, this is what I was suggesting. Cool.\n\nPresumably this BDM record will also have things inherited from the original BDM, like boot_index yeah? Maybe it would make more sense to just change the code to remove attachment_id and not delete/recreate the record?","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. We can do"},{"line_number":105,"context_line":"this with a bdm record with ``type\u003dvolume`` and ``attachment_id\u003dNone``."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_7e9dfe6a","line":105,"range":{"start_line":105,"start_character":30,"end_line":105,"end_character":34},"updated":"2018-09-10 16:07:47.000000000","message":"destination_type?\n\nAlso, the attachment_id\u003dNone thing is going to be confused with what I just described above that happens here:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/compute/manager.py#L4465\n\nCreating a new bdm seems confusing here...I don\u0027t really understand why this is needed. We know the root bdm for the instance based on the boot_index already.\n\nWhen the user detaches the root volume from the shelved offloaded server, they\u0027d go through this:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/compute/api.py#L2044\n\nMaybe that\u0027s where you mean to just set attachment_id\u003dNone rather than destroy the bdm, or create some kind of placeholder bdm.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ada0e9a1bceeff6b7e5241679086f19784d14d76","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. We can do"},{"line_number":105,"context_line":"this with a bdm record with ``type\u003dvolume`` and ``attachment_id\u003dNone``."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_9ef1fa6d","line":105,"range":{"start_line":105,"start_character":30,"end_line":105,"end_character":34},"in_reply_to":"3f79a3b5_7e9dfe6a","updated":"2018-09-10 16:11:35.000000000","message":"I guess the idea is the bdm represents the boot_index\u003d0 root volume, but we want to indicate that there is no actual volume for the bdm, which I\u0027d think would mean we should null out the bdm.volume_id field, but that might break a unique constraint? I guess it\u0027s just an index:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/db/sqlalchemy/models.py#L584\n\nI think we\u0027ve talked about adding a unique constraint on the bdms table to avoid races where we have duplicate bdms for the same volume and instance combination - lyarwood (or I) was supposed to fix something for that after the Dublin PTG:\n\nL578: https://etherpad.openstack.org/p/nova-ptg-rocky\n\nhttps://bugs.launchpad.net/nova/+bug/1427060\n\nMaybe that also needs to be a dependency to fix before we move forward with this?","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"08aa53bd85a9169c5751cd2967a164794959fe66","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached its block device mapping will be replaced"},{"line_number":104,"context_line":"with a block device mapping that indicates there is no volume. We can do"},{"line_number":105,"context_line":"this with a bdm record with ``type\u003dvolume`` and ``attachment_id\u003dNone``."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_8023cca7","line":105,"range":{"start_line":105,"start_character":30,"end_line":105,"end_character":34},"in_reply_to":"3f79a3b5_9ef1fa6d","updated":"2018-09-11 01:41:00.000000000","message":"Yes, that was kind of placeholder, and if we do as Dan said(only switch attachment_id, without the delete/recreate process) it seems like ``swap``(yes, the swap volume API) to me, maybe I wasn\u0027t clear in my comment for last patchset, I was start to think do we really want this attach/detach ability? Because it makes things complex, we might just do rebuild or swap, in that case, the users don\u0027t really have to know which one is the root volume, and we don\u0027t have to have a placeholder, as we will do everything in an atomic workflow.\n\nOr do we really want the attach/detach workflow, as you know, we want it because it can bring more flexible actions for other uses.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8bd42eda5462339b2f250fc12f82b105a2292701","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":109,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":110,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":111,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":112,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_c9f6e15e","line":109,"range":{"start_line":109,"start_character":4,"end_line":109,"end_character":44},"updated":"2018-09-10 14:49:54.000000000","message":"Again, I\u0027m not clear on how the user knows this reliably.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"165e349a2bdf71880e4c881adf4486dbe26522e5","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":109,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":110,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":111,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":112,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_b1550721","line":109,"range":{"start_line":109,"start_character":4,"end_line":109,"end_character":44},"in_reply_to":"3f79a3b5_1ea88ad7","updated":"2018-09-10 16:53:52.000000000","message":"Also, root_device_name is only returned for admins by default (Dan pointed me to that).","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"The usual attach volume API call will be used to attach the boot volume."},{"line_number":108,"context_line":"The volume attach operation allows a user to specify the name of the device."},{"line_number":109,"context_line":"The boot device name of an instance is known so that is used to determine"},{"line_number":110,"context_line":"that the user is attempting to attach the volume as the root device. The"},{"line_number":111,"context_line":"attachment will only be allowed if the instance is shelved_offloaded and"},{"line_number":112,"context_line":"it has a \"no volume\" block device mapping for the root device."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_1ea88ad7","line":109,"range":{"start_line":109,"start_character":4,"end_line":109,"end_character":44},"in_reply_to":"3f79a3b5_c9f6e15e","updated":"2018-09-10 16:07:47.000000000","message":"I believe it\u0027s the root_device_name field on the server that we give back in the API:\n\nhttps://github.com/openstack/nova/blob/aa9f9448c9cf77bb1e55aa0cde5e7f9c4e0157c4/nova/api/openstack/compute/views/servers.py#L211\n\nHaving said that, we\u0027ve wanted to move away from device names in the API:\n\nhttps://review.openstack.org/#/c/452546/\n\nAnd we could replace that with including things in the os-volume_attachments API like (1) virtual BDM device tags and (2) the boot_index (or a boolean indicating which attachment is the root volume where is_root \u003d bdm.is_root (boot_index \u003d\u003d 0).","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":9373,"name":"Vlad Gusev","email":"vlad.esten@gmail.com","username":"s10"},"change_message_id":"af092cb68ac8af25c0c167bff1053967c1952af3","unresolved":false,"context_lines":[{"line_number":129,"context_line":"an instance. Currently many devices on an instance can be added and removed"},{"line_number":130,"context_line":"dynamically."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"We could generalize further and allow a boot volume to be detached and"},{"line_number":133,"context_line":"attached when an instance is shutdown as well. This would involve affecting"},{"line_number":134,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":135,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_b4ec15f5","line":132,"updated":"2018-09-10 17:17:38.000000000","message":"Rebuild, rescue and evacuate are currently not allowed for volume-backed instances anyway, so what will be these corner cases, which could lead to issues? I believe this alternative is better.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":9373,"name":"Vlad Gusev","email":"vlad.esten@gmail.com","username":"s10"},"change_message_id":"14a1103549b28f186fe8565aa21fd7a5d26709d7","unresolved":false,"context_lines":[{"line_number":129,"context_line":"an instance. Currently many devices on an instance can be added and removed"},{"line_number":130,"context_line":"dynamically."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"We could generalize further and allow a boot volume to be detached and"},{"line_number":133,"context_line":"attached when an instance is shutdown as well. This would involve affecting"},{"line_number":134,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":135,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_eba64eac","line":132,"in_reply_to":"3f79a3b5_b0f1a16c","updated":"2018-10-03 21:30:04.000000000","message":"I\u0027m sorry, I just mixed lack of the support for some operations (rescue, rebuild) and bugs related to disk and vifs detachment/attachment which happened during the evacuation of the volume-backed instances and made evacuation end up with errored vms or requiring manual fixes for instances. Lots of them are fixed now, for example, 1522496.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7a1998ad562c7a5d27b9904872f1dabaeb049887","unresolved":false,"context_lines":[{"line_number":129,"context_line":"an instance. Currently many devices on an instance can be added and removed"},{"line_number":130,"context_line":"dynamically."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"We could generalize further and allow a boot volume to be detached and"},{"line_number":133,"context_line":"attached when an instance is shutdown as well. This would involve affecting"},{"line_number":134,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":135,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_b0f1a16c","line":132,"in_reply_to":"3f79a3b5_b4ec15f5","updated":"2018-10-03 20:44:42.000000000","message":"Evacuate is supported for volume-backed instances. Maybe you are confusing evacuate with rebuild of a volume-backed instance where the image changes? The latter is not supported yet. Otherwise evacuate is really just like shelve/unshelve except you lose the root disk if it\u0027s not on shared storage (or in a volume).","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":159,"context_line":"REST API impact"},{"line_number":160,"context_line":"---------------"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"There will be no change to the operations or parameters of the REST API."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"An attempt to detach a boot volume currently always returns the error:"},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_bec15632","line":162,"updated":"2018-09-10 16:07:47.000000000","message":"As noted below, I think we should avoid keying off device_name and instead have a dependent spec to improve the existing os-volume_attachments API to return two new response parameters:\n\n1. the bdm device tag (if one is set)\n2. a boolean flag indicating if the bdm is a root bdm\n\nThat would help us decouple from the device_name quagmire in the volume attach/detach API we have today where the user-supplied device name is ignored.\n\nIf we need to make https://review.openstack.org/#/c/452546/ a dependency for this blueprint, I can cleanup the spec, we\u0027ve said a few times we\u0027d do that, I just haven\u0027t had the proper motivation to spend time on it.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"54ff6aa56e1addc4d6c29e2f28b7be022c47f25d","unresolved":false,"context_lines":[{"line_number":159,"context_line":"REST API impact"},{"line_number":160,"context_line":"---------------"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"There will be no change to the operations or parameters of the REST API."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"An attempt to detach a boot volume currently always returns the error:"},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_205c384b","line":162,"in_reply_to":"3f79a3b5_bec15632","updated":"2018-09-11 03:32:46.000000000","message":"Yes we can do this.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":208,"context_line":"Upgrade impact"},{"line_number":209,"context_line":"--------------"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"None."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_7e273e20","line":211,"updated":"2018-09-10 16:07:47.000000000","message":"Are there any changes to nova-compute for this? Because if so, we\u0027ll need to make the API aware of the minimum required service version of compute to perform these types of actions on servers. I\u0027m guessing it\u0027s maybe not an issue because the majority of the interaction is restricted to the API once the server is shelved offloaded which means there is no host / compute to deal with.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"54ff6aa56e1addc4d6c29e2f28b7be022c47f25d","unresolved":false,"context_lines":[{"line_number":208,"context_line":"Upgrade impact"},{"line_number":209,"context_line":"--------------"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"None."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_00533c3b","line":211,"in_reply_to":"3f79a3b5_7e273e20","updated":"2018-09-11 03:32:46.000000000","message":"Yes, if we are only deal with shelved instance now, we don\u0027t effect these.","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":234,"context_line":"  mapping setting the ``attachment_id`` field to ``None`` and inspect the"},{"line_number":235,"context_line":"  mapping for a volume that is not present."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"- Extend methods to attach/detach volumes for shevled_offloaded instances"},{"line_number":238,"context_line":"  to deal with boot volume and \"no volume\" block device mapping."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"- Add guard in API for \"no volume\" mapping before unshelving an instance."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_9e2c9a02","line":237,"range":{"start_line":237,"start_character":46,"end_line":237,"end_character":53},"updated":"2018-09-10 16:07:47.000000000","message":"shelved","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac6b91b53eefe0bdd7c67b93c576c7fa45147cc","unresolved":false,"context_lines":[{"line_number":278,"context_line":""},{"line_number":279,"context_line":"[3] https://blueprints.launchpad.net/nova/+spec/avoid-parallel-conflicting-api-operations"},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"[4] https://blueprints.launchpad.net/nova/+spec/volume-ops-when-shelved"},{"line_number":282,"context_line":""},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"History"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fe3a6e33","line":281,"updated":"2018-09-10 16:07:47.000000000","message":"Let\u0027s add this suffix to indicate this is done:\n\n(Completed in Mitaka)","commit_id":"08e4f8da5422339ca8cd54fc09fd61f5a1276135"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"There is an implicit assumption in the nova code that an instance always has"},{"line_number":23,"context_line":"a cinder boot volume attached or an ephemeral boot disk. Nova allows cinder"},{"line_number":24,"context_line":"volumes to be detached and attached at any time, but the detach operation is"},{"line_number":25,"context_line":"limited to exclude boot volumes to preserve the above assumption[1]."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"This limitation means it is not possible to change the boot volume"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6eecc527","line":24,"range":{"start_line":24,"start_character":36,"end_line":24,"end_character":47},"updated":"2018-10-03 20:21:08.000000000","message":"Well, not really true:\n\nhttps://github.com/openstack/nova/blob/99bf62e42701397690fe2b4987ce4fd7879355b8/nova/compute/api.py#L4185\n\nhttps://github.com/openstack/nova/blob/99bf62e42701397690fe2b4987ce4fd7879355b8/nova/compute/api.py#L4071\n\nBut OK.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"There are use cases that require a boot volume to be detached when an"},{"line_number":33,"context_line":"instance is not running, so we propose relaxing the inherent assumption to"},{"line_number":34,"context_line":"say that a boot volume attachment can be changed when an instance is powered"},{"line_number":35,"context_line":"off or shelved. To ensure safety we can prevent it being started or unshelved"},{"line_number":36,"context_line":"without a boot volume."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8deed288","line":35,"range":{"start_line":34,"start_character":49,"end_line":35,"end_character":3},"updated":"2018-10-03 20:21:08.000000000","message":"Hmm, but the spec is only proposing to allow detaching the root volume while the instance is shelved offloaded, correct? Or is this new from when the spec was originally accepted?\n\nIs detaching and attaching a new root volume while stopped safe for all compute drivers? Or is this just assuming libvirt and how it works where the guest domain is reconstructed when started (the libvirt driver does a hard reboot under the covers). I\u0027m not sure that is going to be the same for ironic/vmware/powervm/hyperv/xen.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"There are use cases that require a boot volume to be detached when an"},{"line_number":33,"context_line":"instance is not running, so we propose relaxing the inherent assumption to"},{"line_number":34,"context_line":"say that a boot volume attachment can be changed when an instance is powered"},{"line_number":35,"context_line":"off or shelved. To ensure safety we can prevent it being started or unshelved"},{"line_number":36,"context_line":"without a boot volume."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_c6c20b03","line":35,"range":{"start_line":34,"start_character":49,"end_line":35,"end_character":3},"in_reply_to":"3f79a3b5_6960fc35","updated":"2018-10-09 02:01:37.000000000","message":"Thanks alot for the review and info, yeah, stopped could be more useful, as shelve is more expensive.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7e7d903cf5fbbde85e73b00350e1de8c38e5cca8","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"There are use cases that require a boot volume to be detached when an"},{"line_number":33,"context_line":"instance is not running, so we propose relaxing the inherent assumption to"},{"line_number":34,"context_line":"say that a boot volume attachment can be changed when an instance is powered"},{"line_number":35,"context_line":"off or shelved. To ensure safety we can prevent it being started or unshelved"},{"line_number":36,"context_line":"without a boot volume."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_502fedf3","line":35,"range":{"start_line":34,"start_character":49,"end_line":35,"end_character":3},"in_reply_to":"3f79a3b5_8deed288","updated":"2018-10-03 20:37:22.000000000","message":"I guess if we allowed, in the API, to attempt to detach a root volume for a stopped instance, the virt driver could always raise an exception on the detach_volume operation in that case if it doesn\u0027t support it. That would record a fault with the instance and the detach volume operation would fail, but it wouldn\u0027t be destructive in any way, and you could get away with supporting it on libvirt-only for the time being. Could also potentially add a policy rule for whether or not you support detaching the root volume for stopped instances, but maybe that\u0027s overkill.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":9373,"name":"Vlad Gusev","email":"vlad.esten@gmail.com","username":"s10"},"change_message_id":"b0843c179a16f06502aa3e34c9e6fdc5c8e3d356","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"There are use cases that require a boot volume to be detached when an"},{"line_number":33,"context_line":"instance is not running, so we propose relaxing the inherent assumption to"},{"line_number":34,"context_line":"say that a boot volume attachment can be changed when an instance is powered"},{"line_number":35,"context_line":"off or shelved. To ensure safety we can prevent it being started or unshelved"},{"line_number":36,"context_line":"without a boot volume."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6960fc35","line":35,"range":{"start_line":34,"start_character":49,"end_line":35,"end_character":3},"in_reply_to":"3f79a3b5_8deed288","updated":"2018-10-04 10:44:57.000000000","message":"This certainly works for libvirt, vmware, xen. All of them can safely detach all volumes from VM and attach them back.\nThis might be useful, for example, for running diskless instance with pxe boot.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":31,"context_line":""},{"line_number":32,"context_line":"There are use cases that require a boot volume to be detached when an"},{"line_number":33,"context_line":"instance is not running, so we propose relaxing the inherent assumption to"},{"line_number":34,"context_line":"say that a boot volume attachment can be changed when an instance is powered"},{"line_number":35,"context_line":"off or shelved. To ensure safety we can prevent it being started or unshelved"},{"line_number":36,"context_line":"without a boot volume."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_28c9a54f","line":35,"range":{"start_line":34,"start_character":49,"end_line":35,"end_character":3},"in_reply_to":"3f79a3b5_c6c20b03","updated":"2018-10-16 16:35:42.000000000","message":"\u003e Thanks alot for the review and info, yeah, stopped could be more\n \u003e useful, as shelve is more expensive.\n\nNote that some people, including our own product team for public cloud at Huawei, would like stop to actually shelve offload under the covers.\n\nhttp://lists.openstack.org/pipermail/openstack-operators/2018-September/thread.html#15877\n\nSo it\u0027s probably natural to think of them as similar operations.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_30bfd1fc","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"updated":"2018-10-03 20:21:08.000000000","message":"You should probably give some more details here. While shelved, the instance still has the volumes logically attached (the volume status would be \"reserved\" rather than \"in-use\"). This is because we create a new \"empty\" volume attachment before offloading the instance and detaching the current volume connections on the compute host:\n\nhttps://github.com/openstack/nova/blob/85b36cd2f82ccd740057c1bee08fc722209604ab/nova/compute/manager.py#L5003\n\nOnce we unshelve, we\u0027ll re-attach volumes on the new host:\n\nhttps://github.com/openstack/nova/blob/85b36cd2f82ccd740057c1bee08fc722209604ab/nova/compute/manager.py#L5087\n\nSo a BlockDeviceMapping record with volume_id\u003dNone but an attachment_id !\u003d None means the BDM represents a volume attachment but that volume is not currently set.\n\nNow one thing that might break down here is when we attach a new root volume and then go to update the old attachment record (using our stashed attachment_id), I\u0027m wondering if that will fail because the attachment_id is for the old volume. We update the attachment with the new host connector during unshelve here:\n\nhttps://github.com/openstack/nova/blob/85b36cd2f82ccd740057c1bee08fc722209604ab/nova/virt/block_device.py#L528\n\nWill Cinder allow updating an attachment for a different volume? Even if it does, should we allow that? Because I\u0027m pretty sure it will get our accounting all screwed up.\n\nSo we likely need to think through what happens to the BDM.attachment_id when you detach the root volume while the instance is shelved, and then attach a new root volume - maybe on attach of the new root volume we would delete the existing attachment record in cinder (referenced via the bdm.attachment_id) and then create a new attachment record for the new root volume and update the bdm.attachment_id field. Note that we could fail to attach the new root volume if it\u0027s not available (and not multiattach\u003dTrue).","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"16029cc2706f517cd0e4e1b80ea1274ab3c2417c","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f06cf96b","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"in_reply_to":"3f79a3b5_30bfd1fc","updated":"2018-10-03 20:29:50.000000000","message":"I think this might be what happens in the API when detaching/attaching a root volume from a shelved instance:\n\nDetach:\n\n* Delete the volume attachment referenced via the BDM.attachment_id field and null out the BDM.attachment_id and BDM.volume_id fields (save those changes to the DB). At that point the old root volume is made \u0027available\u0027 again.\n\nAttach:\n\n* Find the root BDM via BlockDeviceMappingList.root_bdm(); at this point the root BDM has a null attachment_id and volume_id.\n* Create a volume attachment record for the new root volume [1] and then update the BDM\u0027s attachment_id and volume_id fields and save those to the DB.\n\n--\n\nThe normal error conditions around volume attach will be in play, i.e. you can\u0027t attach a volume that is already in-use unless it\u0027s a multiattach volume.\n\n[1] https://github.com/openstack/nova/blob/85b36cd2f82ccd740057c1bee08fc722209604ab/nova/volume/cinder.py#L710","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a6cfcf26","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"in_reply_to":"3f79a3b5_f06cf96b","updated":"2018-10-09 02:01:37.000000000","message":"Thanks I will try to add these","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cda5aa49","line":107,"range":{"start_line":107,"start_character":57,"end_line":107,"end_character":60},"updated":"2018-10-03 20:21:08.000000000","message":". A","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_46d6fbc6","line":107,"range":{"start_line":107,"start_character":57,"end_line":107,"end_character":60},"in_reply_to":"3f79a3b5_cda5aa49","updated":"2018-10-09 02:01:37.000000000","message":"Done","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"},{"line_number":111,"context_line":"shelved_offloaded and it has a \"no volume\" block device mapping for the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4d675a25","line":108,"range":{"start_line":108,"start_character":44,"end_line":108,"end_character":64},"updated":"2018-10-03 20:21:08.000000000","message":"the new microversion or greater","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"},{"line_number":111,"context_line":"shelved_offloaded and it has a \"no volume\" block device mapping for the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_06e00397","line":108,"range":{"start_line":108,"start_character":44,"end_line":108,"end_character":64},"in_reply_to":"3f79a3b5_4d675a25","updated":"2018-10-09 02:01:37.000000000","message":"Done","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"},{"line_number":111,"context_line":"shelved_offloaded and it has a \"no volume\" block device mapping for the"},{"line_number":112,"context_line":"root device."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_0db0828a","line":109,"range":{"start_line":109,"start_character":47,"end_line":109,"end_character":49},"updated":"2018-10-03 20:21:08.000000000","message":"space","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API, a new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with greater microversion, indicating"},{"line_number":109,"context_line":"that the user is trying to attach a root volume.The attachment with this"},{"line_number":110,"context_line":"parameter will only be allowed if the instance is powered off or"},{"line_number":111,"context_line":"shelved_offloaded and it has a \"no volume\" block device mapping for the"},{"line_number":112,"context_line":"root device."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_26dbbfea","line":109,"range":{"start_line":109,"start_character":47,"end_line":109,"end_character":49},"in_reply_to":"3f79a3b5_0db0828a","updated":"2018-10-09 02:01:37.000000000","message":"Done","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":129,"context_line":"an instance. Currently many devices on an instance can be added and removed"},{"line_number":130,"context_line":"dynamically."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"We could generalize further and allow a boot volume to be detached and"},{"line_number":133,"context_line":"attached when an instance is shutdown as well. This would involve affecting"},{"line_number":134,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":135,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"},{"line_number":136,"context_line":"unnecessary to disable it. However, this throws open many more corner cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f02ab975","line":133,"range":{"start_line":132,"start_character":0,"end_line":133,"end_character":46},"updated":"2018-10-03 20:21:08.000000000","message":"Umm, isn\u0027t the spec now saying it\u0027s going to support exactly this?","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":129,"context_line":"an instance. Currently many devices on an instance can be added and removed"},{"line_number":130,"context_line":"dynamically."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"We could generalize further and allow a boot volume to be detached and"},{"line_number":133,"context_line":"attached when an instance is shutdown as well. This would involve affecting"},{"line_number":134,"context_line":"the connection to the hypervisor on the compute node. The ability to do this"},{"line_number":135,"context_line":"for boot volumes is inherent in the existing volume device code, so it seems"},{"line_number":136,"context_line":"unnecessary to disable it. However, this throws open many more corner cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e6ee2789","line":133,"range":{"start_line":132,"start_character":0,"end_line":133,"end_character":46},"in_reply_to":"3f79a3b5_f02ab975","updated":"2018-10-09 02:01:37.000000000","message":"Done","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":166,"context_line":""},{"line_number":167,"context_line":"  \"Can\u0027t detach root device volume (HTTP: 403)\""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"This will change in the case of an instance being in stopped or"},{"line_number":170,"context_line":"shelved_offloaded state to allow the detach."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"An attempt to start or unshelve an instance that has a missing boot volume"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f03f19af","line":169,"updated":"2018-10-03 20:21:08.000000000","message":"This would only be if requesting to detach the root volume with the new microversion or greater, correct? The mention of the new microversion seems to be restricted to just the attach_volume action, but it really applies to both attach and detach.\n\n(later)\n\nOh I guess L177 covers that concern...","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4536ece44ed298d6efa27840112f89f079f401f7","unresolved":false,"context_lines":[{"line_number":189,"context_line":"Other end user impact"},{"line_number":190,"context_line":"---------------------"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"None."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Performance Impact"},{"line_number":195,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_506a8db4","line":192,"updated":"2018-10-03 20:21:08.000000000","message":"This is where you mention that python-novaclient and python-openstackclient will be updated to support the new capability.","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"805ac8cf42d9bdcd2948d1878d68fd4e083afc2b","unresolved":false,"context_lines":[{"line_number":189,"context_line":"Other end user impact"},{"line_number":190,"context_line":"---------------------"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"None."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Performance Impact"},{"line_number":195,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_06f9e34c","line":192,"in_reply_to":"3f79a3b5_506a8db4","updated":"2018-10-09 02:01:37.000000000","message":"Done","commit_id":"55948bb20dee669cfd9816afaf0fbc38d93df931"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  As a cloud user I want to be able to failover my application to a remote"},{"line_number":51,"context_line":"  site with minimal down time and the assurance that the remote site is"},{"line_number":52,"context_line":"  able to take over."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The ability to detach and attach boot volumes is required for this use case"},{"line_number":55,"context_line":"as implemented by the following failover from site A to site B:"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_32e003fa","line":53,"updated":"2018-10-18 08:52:33.000000000","message":"Isn\u0027t it an application architecture problem that the root volume contains information that is needed to recover the application? I always thought that root disk is for the operating system of the VM and the application data is on a separate persistent volume.\n\nI know I know this is most probably yet another telco app that would be expensive to re-architecture.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  As a cloud user I want to be able to failover my application to a remote"},{"line_number":51,"context_line":"  site with minimal down time and the assurance that the remote site is"},{"line_number":52,"context_line":"  able to take over."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The ability to detach and attach boot volumes is required for this use case"},{"line_number":55,"context_line":"as implemented by the following failover from site A to site B:"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a741300b","line":53,"in_reply_to":"3f79a3b5_32e003fa","updated":"2018-10-18 12:52:24.000000000","message":"Never question the greatness of legacy enterprise applications young gibster.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e57bc2033ea672f2fe966637891d0b3947220f58","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  As a cloud user I want to be able to failover my application to a remote"},{"line_number":51,"context_line":"  site with minimal down time and the assurance that the remote site is"},{"line_number":52,"context_line":"  able to take over."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The ability to detach and attach boot volumes is required for this use case"},{"line_number":55,"context_line":"as implemented by the following failover from site A to site B:"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_22c0927d","line":53,"in_reply_to":"3f79a3b5_a741300b","updated":"2018-10-19 15:08:38.000000000","message":"I offer my life to the support of legacy telco apps :)","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":80,"context_line":"A bug registered against nova describes further use cases (see [2]). An"},{"line_number":81,"context_line":"example is the following:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"  As a user I want to run a VM with a windows instance. I will take snapshots"},{"line_number":84,"context_line":"  of the boot volume from time to time. I may want to revert to a snapshot."},{"line_number":85,"context_line":"  If I delete my instance and recreate it from the snapshot I will incur"},{"line_number":86,"context_line":"  additional costs from licensing and may invalidate my license."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Proposed change"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_3277a33f","line":86,"range":{"start_line":83,"start_character":0,"end_line":86,"end_character":64},"updated":"2018-10-18 08:52:33.000000000","message":"Isn\u0027t it a use case for rebuild a boot for volume instance instead?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":80,"context_line":"A bug registered against nova describes further use cases (see [2]). An"},{"line_number":81,"context_line":"example is the following:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"  As a user I want to run a VM with a windows instance. I will take snapshots"},{"line_number":84,"context_line":"  of the boot volume from time to time. I may want to revert to a snapshot."},{"line_number":85,"context_line":"  If I delete my instance and recreate it from the snapshot I will incur"},{"line_number":86,"context_line":"  additional costs from licensing and may invalidate my license."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Proposed change"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a76a907f","line":86,"range":{"start_line":83,"start_character":0,"end_line":86,"end_character":64},"in_reply_to":"3f79a3b5_3277a33f","updated":"2018-10-18 12:52:24.000000000","message":"If it\u0027s volume-backed you can\u0027t currently change the image on rebuild, that would be: https://review.openstack.org/#/c/532407/\n\nThe concepts are pretty similar though.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e57bc2033ea672f2fe966637891d0b3947220f58","unresolved":false,"context_lines":[{"line_number":80,"context_line":"A bug registered against nova describes further use cases (see [2]). An"},{"line_number":81,"context_line":"example is the following:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"  As a user I want to run a VM with a windows instance. I will take snapshots"},{"line_number":84,"context_line":"  of the boot volume from time to time. I may want to revert to a snapshot."},{"line_number":85,"context_line":"  If I delete my instance and recreate it from the snapshot I will incur"},{"line_number":86,"context_line":"  additional costs from licensing and may invalidate my license."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Proposed change"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a23102be","line":86,"range":{"start_line":83,"start_character":0,"end_line":86,"end_character":64},"in_reply_to":"3f79a3b5_a76a907f","updated":"2018-10-19 15:08:38.000000000","message":"ack.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":91,"context_line":"This change assumes that only cinder volumes can be dynamically changed"},{"line_number":92,"context_line":"in this way. We will not support detaching ephemeral disks."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Volume backed instances are always offloaded after a period of time[3]"},{"line_number":95,"context_line":"when shelved, so the instance will not be on a host. As a result the"},{"line_number":96,"context_line":"implementation will be to change the recorded block device mapping and"},{"line_number":97,"context_line":"register the attachment/detachment with cinder."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_527fbfbb","line":95,"range":{"start_line":94,"start_character":0,"end_line":95,"end_character":12},"updated":"2018-10-18 08:52:33.000000000","message":"Does it mean that we will change the meaning of shelved_offload_time config option and if it is set to \u003c 0 then it will only mean that the local disk will not be offloaded but volumes will be offloaded. If yes, then after how much time a volume will be offloaded when shelved_offload_time is set to -1?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e57bc2033ea672f2fe966637891d0b3947220f58","unresolved":false,"context_lines":[{"line_number":91,"context_line":"This change assumes that only cinder volumes can be dynamically changed"},{"line_number":92,"context_line":"in this way. We will not support detaching ephemeral disks."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Volume backed instances are always offloaded after a period of time[3]"},{"line_number":95,"context_line":"when shelved, so the instance will not be on a host. As a result the"},{"line_number":96,"context_line":"implementation will be to change the recorded block device mapping and"},{"line_number":97,"context_line":"register the attachment/detachment with cinder."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_226e5297","line":95,"range":{"start_line":94,"start_character":0,"end_line":95,"end_character":12},"in_reply_to":"3f79a3b5_07282434","updated":"2018-10-19 15:08:38.000000000","message":"Ahh so the author means that volume backed instance will be offloaded by the owner (or the timer) to allow the detach of the device.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":91,"context_line":"This change assumes that only cinder volumes can be dynamically changed"},{"line_number":92,"context_line":"in this way. We will not support detaching ephemeral disks."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Volume backed instances are always offloaded after a period of time[3]"},{"line_number":95,"context_line":"when shelved, so the instance will not be on a host. As a result the"},{"line_number":96,"context_line":"implementation will be to change the recorded block device mapping and"},{"line_number":97,"context_line":"register the attachment/detachment with cinder."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_07282434","line":95,"range":{"start_line":94,"start_character":0,"end_line":95,"end_character":12},"in_reply_to":"3f79a3b5_527fbfbb","updated":"2018-10-18 12:52:24.000000000","message":"I don\u0027t believe so, I think this is just explaining how shelve works. The API already allows you to detach/attach non-root volumes on a shelved offloaded instance, but the user has to either wait for the shelved instance to be offloaded or initiate the offload action after they have shelved the instance. The sentence saying \"Volume-backed instances\" could just say \"Instances\" because it doesn\u0027t really have anything to do with whether or not the root disk is on a volume.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API. A new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with the new microversion or greater,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_d2618f12","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"updated":"2018-10-18 08:52:33.000000000","message":"How will nova remember that this instance was boot from volume?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e57bc2033ea672f2fe966637891d0b3947220f58","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API. A new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with the new microversion or greater,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_c202feb9","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"in_reply_to":"3f79a3b5_a7ddb040","updated":"2018-10-19 15:08:38.000000000","message":"OK, so volume_id\u003dNone is not used in that check. Coolio.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"},{"line_number":101,"context_line":"is powered off or shelved_offloaded."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"When a boot volume is detached, we will set the root block device"},{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API. A new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with the new microversion or greater,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a7ddb040","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":23},"in_reply_to":"3f79a3b5_d2618f12","updated":"2018-10-18 12:52:24.000000000","message":"If you need to find out from the BDM, destination_type\u003d\u0027volume\u0027 and boot_index\u003d\u00270\u0027:\n\nhttps://github.com/openstack/nova/blob/ce520ee789bf6a46f56de86769d74c095ce432cf/nova/objects/block_device.py#L341\n\nhttps://github.com/openstack/nova/blob/ce520ee789bf6a46f56de86769d74c095ce432cf/nova/objects/block_device.py#L337\n\nOtherwise the request spec also tells us now:\n\nhttps://github.com/openstack/nova/blob/ce520ee789bf6a46f56de86769d74c095ce432cf/nova/objects/request_spec.py#L86","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":112,"context_line":"root device."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There are some specific considerations for detaching/attaching a root volume"},{"line_number":115,"context_line":"from a shelved instance, here is what will happen:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"- Detach:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_08f7098e","line":115,"range":{"start_line":115,"start_character":5,"end_line":115,"end_character":23},"updated":"2018-10-16 16:35:42.000000000","message":"Would this be the same for a stopped instance? For a shelved offloaded instance, the API has to orchestrate this. For a stopped instance, nova-compute would be doing something...but what? Does it detach the volume and delete the bdm record? Or just null out the BDM\u0027s volume_id and attachment_id fields?\n\nhttps://github.com/openstack/nova/blob/a53e46a75936b55c93face840764a67f2186cb11/nova/compute/manager.py#L5614\n\nBecause if we destroy the root bdm when detaching from a stopped instance, how are we going to find it again on attach?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":112,"context_line":"root device."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There are some specific considerations for detaching/attaching a root volume"},{"line_number":115,"context_line":"from a shelved instance, here is what will happen:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"- Detach:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_d793c1fe","line":115,"range":{"start_line":115,"start_character":5,"end_line":115,"end_character":23},"in_reply_to":"3f79a3b5_08f7098e","updated":"2018-10-18 08:00:04.000000000","message":"Hmm, yes, I guess we have to check whether it is a root volume and null out the BDM\u0027s volume_id in that case.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The start and unshelve operation will be guarded with a check for the"},{"line_number":138,"context_line":"\"no volume\" block device mapping. An instance will not be allowed to"},{"line_number":139,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":140,"context_line":"has been attached in its place."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_780c1d3a","line":139,"range":{"start_line":139,"start_character":17,"end_line":139,"end_character":38},"updated":"2018-10-18 08:52:33.000000000","message":"how nova will know that this instance is supposed to be boot from volume?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The start and unshelve operation will be guarded with a check for the"},{"line_number":138,"context_line":"\"no volume\" block device mapping. An instance will not be allowed to"},{"line_number":139,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":140,"context_line":"has been attached in its place."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_c7af8c9b","line":139,"range":{"start_line":139,"start_character":17,"end_line":139,"end_character":38},"in_reply_to":"3f79a3b5_780c1d3a","updated":"2018-10-18 12:52:24.000000000","message":"See above.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":139,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":140,"context_line":"has been attached in its place."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"},{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_086aa919","line":142,"range":{"start_line":142,"start_character":0,"end_line":142,"end_character":52},"updated":"2018-10-16 16:35:42.000000000","message":"This isn\u0027t really a sentence...maybe:\n\nFor detach/attach volume for powered off instances, this would involve affecting the....","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":139,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":140,"context_line":"has been attached in its place."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"},{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_2820c5f7","line":142,"range":{"start_line":142,"start_character":4,"end_line":142,"end_character":11},"updated":"2018-10-16 16:35:42.000000000","message":"detach","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":139,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":140,"context_line":"has been attached in its place."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"},{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_f78b5dbe","line":142,"range":{"start_line":142,"start_character":0,"end_line":142,"end_character":52},"in_reply_to":"3f79a3b5_086aa919","updated":"2018-10-18 08:00:04.000000000","message":"Done","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"},{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."},{"line_number":146,"context_line":"In this spec, only ``libvirt`` driver will be implemented."},{"line_number":147,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_28652549","line":144,"range":{"start_line":144,"start_character":45,"end_line":144,"end_character":49},"updated":"2018-10-16 16:35:42.000000000","message":". We","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"For dettach/attach volume for powered_off instances. This would involve"},{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."},{"line_number":146,"context_line":"In this spec, only ``libvirt`` driver will be implemented."},{"line_number":147,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_b7b72589","line":144,"range":{"start_line":144,"start_character":45,"end_line":144,"end_character":49},"in_reply_to":"3f79a3b5_28652549","updated":"2018-10-18 08:00:04.000000000","message":"Done","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0aecaa8c13748fbaf9104f3eb2bd85942e347cb2","unresolved":false,"context_lines":[{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."},{"line_number":146,"context_line":"In this spec, only ``libvirt`` driver will be implemented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"There is a race condition identified in this bug [5] between volume"},{"line_number":149,"context_line":"operations and instance state changes. The same race condition will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a8c7f510","line":146,"range":{"start_line":146,"start_character":0,"end_line":146,"end_character":58},"updated":"2018-10-16 16:35:42.000000000","message":"Well, there are no virt driver specific changes as far as I know, correct? The orchestration happens in the API for a shelved instance, and in the compute service for a stopped instance. I don\u0027t think there are any proposed interface changes to the virt driver API, which means you don\u0027t need to say this is libvirt-only. We\u0027ll know in CI if it works for other virt drivers and will be documented in the feature support matrix appropriately.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":143,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":144,"context_line":"will depend on the ability of compute drivers, we are now aware of that"},{"line_number":145,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."},{"line_number":146,"context_line":"In this spec, only ``libvirt`` driver will be implemented."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"There is a race condition identified in this bug [5] between volume"},{"line_number":149,"context_line":"operations and instance state changes. The same race condition will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_97b6a989","line":146,"range":{"start_line":146,"start_character":0,"end_line":146,"end_character":58},"in_reply_to":"3f79a3b5_a8c7f510","updated":"2018-10-18 08:00:04.000000000","message":"Done","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1f35ab3afad2713357b43402dc15beb2580a529d","unresolved":false,"context_lines":[{"line_number":222,"context_line":"Other deployer impact"},{"line_number":223,"context_line":"---------------------"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"None."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Developer impact"},{"line_number":228,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_983259f3","line":225,"range":{"start_line":225,"start_character":0,"end_line":225,"end_character":4},"updated":"2018-10-18 08:52:33.000000000","message":"Does this change affect the meaning of the shelved_offload_time config option?","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"97e6e9c395e9be5b1ea489665350fdfda67bc66e","unresolved":false,"context_lines":[{"line_number":222,"context_line":"Other deployer impact"},{"line_number":223,"context_line":"---------------------"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"None."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Developer impact"},{"line_number":228,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_a7c61069","line":225,"range":{"start_line":225,"start_character":0,"end_line":225,"end_character":4},"in_reply_to":"3f79a3b5_983259f3","updated":"2018-10-18 12:52:24.000000000","message":"I don\u0027t think it should, see above.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cf995fcedb4b8e3876054ff8b0f6b3f06dba2032","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Upgrade impact"},{"line_number":233,"context_line":"--------------"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"None."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_286f65fa","line":235,"updated":"2018-10-16 16:37:07.000000000","message":"There will clearly be an upgrade impact if we need to make changes to the detach_volume flow in the compute service for a stopped server, because as noted above it will destroy the root bdm record. If we have to change that logic, we need to have a compute service version bump so the API can determine if the operation can be performed on the instance, otherwise we\u0027ll be deleting the root volume bdm on older computes.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Upgrade impact"},{"line_number":233,"context_line":"--------------"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"None."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_57a81120","line":235,"in_reply_to":"3f79a3b5_286f65fa","updated":"2018-10-18 08:00:04.000000000","message":"Yes correct","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c95a91aece9c56fb09ee1950de0b91053df99270","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Document when a root device volume can be detached and attached."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"Error return when trying to start an instance with no root device."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"References"},{"line_number":299,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_e8fbad12","line":296,"range":{"start_line":296,"start_character":0,"end_line":296,"end_character":66},"updated":"2018-10-16 16:38:43.000000000","message":"This isn\u0027t really something for the docs though is it? The API reference already mentions 409 is a possible error code for unshelve and start APIs.\n\n--\n\nI would mention the feature support matrix will be updated if any compute drivers cannot support detaching the root volume from a stopped instance.","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"fb0f8ef988b45e5a9a513b2ba9cf112df4f43024","unresolved":false,"context_lines":[{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Document when a root device volume can be detached and attached."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"Error return when trying to start an instance with no root device."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"References"},{"line_number":299,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_d7618112","line":296,"range":{"start_line":296,"start_character":0,"end_line":296,"end_character":66},"in_reply_to":"3f79a3b5_e8fbad12","updated":"2018-10-18 08:00:04.000000000","message":"Done","commit_id":"22a043e4ff30dd727034f962cd88a88f7423db99"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"664648465c5ed2de9d23c104954e73fcd40382ac","unresolved":false,"context_lines":[{"line_number":94,"context_line":"Volume backed instances are always offloaded after a period of time[3]"},{"line_number":95,"context_line":"when shelved, so the instance will not be on a host. As a result the"},{"line_number":96,"context_line":"implementation will be to change the recorded block device mapping and"},{"line_number":97,"context_line":"register the attachment/detachment with cinder."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"The usual detach volume API call will be used to detach the boot volume."},{"line_number":100,"context_line":"The guard on this call will be changed to allow the detach if the instance"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_cdb751f8","line":97,"updated":"2018-10-23 17:49:09.000000000","message":"I\u0027m not sure I understand this paragraph well. Is it just saying that in the case of shelved_offloaded, we don\u0027t need to attach/detach from the compute host and instead only need to update the block device mapping and call cinder?","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"664648465c5ed2de9d23c104954e73fcd40382ac","unresolved":false,"context_lines":[{"line_number":104,"context_line":"mapping(boot_index\u003d0) with ``volume_id\u003dNone``, meaning that it\u0027s not"},{"line_number":105,"context_line":"attached to any volume."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"A new microversion will be added to the attach volume API. A new ``is_root``"},{"line_number":108,"context_line":"parameter will be allowed for requests with the new microversion or greater,"},{"line_number":109,"context_line":"indicating that the user is trying to attach a root volume. The attachment"},{"line_number":110,"context_line":"with this parameter will only be allowed if the instance is powered off or"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_6df15dde","line":107,"range":{"start_line":107,"start_character":65,"end_line":107,"end_character":76},"updated":"2018-10-23 17:49:09.000000000","message":"Note to self: we need this because there\u0027s no boot_index in the attach API.","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"664648465c5ed2de9d23c104954e73fcd40382ac","unresolved":false,"context_lines":[{"line_number":108,"context_line":"parameter will be allowed for requests with the new microversion or greater,"},{"line_number":109,"context_line":"indicating that the user is trying to attach a root volume. The attachment"},{"line_number":110,"context_line":"with this parameter will only be allowed if the instance is powered off or"},{"line_number":111,"context_line":"shelved_offloaded and it has a \"no volume\" block device mapping for the"},{"line_number":112,"context_line":"root device."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There are some specific considerations for detaching/attaching a root volume"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_2d93655b","line":111,"range":{"start_line":111,"start_character":31,"end_line":111,"end_character":42},"updated":"2018-10-23 17:49:09.000000000","message":"This means volume_id\u003dNone in the block device mapping right?","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"84e95b30fbe2addd01463c5cd75bb58e1a7f0f78","unresolved":false,"context_lines":[{"line_number":112,"context_line":"root device."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There are some specific considerations for detaching/attaching a root volume"},{"line_number":115,"context_line":"instances, here is what will happen:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"- Detach:"},{"line_number":118,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_bc283e36","line":115,"range":{"start_line":115,"start_character":0,"end_line":115,"end_character":9},"updated":"2018-10-19 23:00:54.000000000","message":"nit: from an instance?","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"84e95b30fbe2addd01463c5cd75bb58e1a7f0f78","unresolved":false,"context_lines":[{"line_number":124,"context_line":"   compute service version will be bumped in order to represent that detach"},{"line_number":125,"context_line":"   root volume for deleted instance is supported."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"- Attach:"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"   Find the root BDM via BlockDeviceMappingList.root_bdm(); at this point"},{"line_number":130,"context_line":"   the root BDM has a null attachment_id and volume_id."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_7cd70624","line":127,"updated":"2018-10-19 23:00:54.000000000","message":"Hmm, so here is something I thought about - if you can attach a new root volume to a stopped instance, what if that root volume has a different image in it? That\u0027s kind of like a rebuild...I\u0027m not sure how much we need to care about this besides just knowing it could happen and if someone swaps the root volume on a stopped instance with a root volume with a new image that doesn\u0027t work with the guest, that\u0027s their fault. Are there any other things that could fail with that though? Otherwise as far as attaching a root volume on a stopped instance, clearly it would need to happen on the compute since we have to connect it on the host.","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7b54144b19fde76d48cfe8e5a0b0a0fa9fcbcb8d","unresolved":false,"context_lines":[{"line_number":124,"context_line":"   compute service version will be bumped in order to represent that detach"},{"line_number":125,"context_line":"   root volume for deleted instance is supported."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"- Attach:"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"   Find the root BDM via BlockDeviceMappingList.root_bdm(); at this point"},{"line_number":130,"context_line":"   the root BDM has a null attachment_id and volume_id."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_dc8c1a2f","line":127,"in_reply_to":"3f79a3b5_7cd70624","updated":"2018-10-19 23:04:12.000000000","message":"I guess the root volume image changing concern is also a thing that could happen with a shelved instance, so it\u0027s probably not really different in any way.\n\nYou know...I think I\u0027m finally realizing how rebuilding a volume-backed instance with a new image could have been solved with *this* change because it\u0027s essentially doing the same thing if the image within the root volume changes, especially for shelve/unshelve destroying/spawning the guest - the only difference there is the server might move to another host. And for a stopped instance, the difference with rebuild would obviously be that we don\u0027t destroy/spawn the guest, which could mean we don\u0027t have a chance to inject a new key into the guest.","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8fc207e6037ccd220c5e305463db73865e2d75de","unresolved":false,"context_lines":[{"line_number":124,"context_line":"   compute service version will be bumped in order to represent that detach"},{"line_number":125,"context_line":"   root volume for deleted instance is supported."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"- Attach:"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"   Find the root BDM via BlockDeviceMappingList.root_bdm(); at this point"},{"line_number":130,"context_line":"   the root BDM has a null attachment_id and volume_id."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_7ce146cf","line":127,"in_reply_to":"3f79a3b5_dc8c1a2f","updated":"2018-10-19 23:07:18.000000000","message":"The other thing with rebuild is if you rebuild with a new image, we run it through the scheduler to make sure the image still works on the current host for the instance...I\u0027ll need to remember that for the volume-backed rebuild with new image spec as well...","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a19b97471f16e7a206962138be24bad0ccc8fe4a","unresolved":false,"context_lines":[{"line_number":142,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":143,"context_line":"has been attached in its place."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"For dettach/attach volume for powered off instances, This would involve"},{"line_number":146,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":147,"context_line":"will depend on the ability of compute drivers. We are now aware of that"},{"line_number":148,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_cd01916f","line":145,"range":{"start_line":145,"start_character":4,"end_line":145,"end_character":11},"updated":"2018-10-23 17:20:31.000000000","message":"detach","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"84e95b30fbe2addd01463c5cd75bb58e1a7f0f78","unresolved":false,"context_lines":[{"line_number":142,"context_line":"start or unshelve when its boot volume has been detached unless another"},{"line_number":143,"context_line":"has been attached in its place."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"For dettach/attach volume for powered off instances, This would involve"},{"line_number":146,"context_line":"affecting the connection to the hypervisor on the compute node, thus"},{"line_number":147,"context_line":"will depend on the ability of compute drivers. We are now aware of that"},{"line_number":148,"context_line":"``libvirt``, ``vmaware`` and ``xen`` driver will be capable of doing this."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_1ce61215","line":145,"range":{"start_line":145,"start_character":53,"end_line":145,"end_character":57},"updated":"2018-10-19 23:00:54.000000000","message":"this (lower case)","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"84e95b30fbe2addd01463c5cd75bb58e1a7f0f78","unresolved":false,"context_lines":[{"line_number":236,"context_line":"--------------"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"Compute service version will be bumped to represent that the"},{"line_number":239,"context_line":"feature for detach_volume flow for deleted instance is supported."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_3ccaee6e","line":239,"range":{"start_line":239,"start_character":12,"end_line":239,"end_character":25},"updated":"2018-10-19 23:00:54.000000000","message":"Technically attach_volume too, right? But those would happen in the same compute RPC API version change.","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"a19b97471f16e7a206962138be24bad0ccc8fe4a","unresolved":false,"context_lines":[{"line_number":277,"context_line":""},{"line_number":278,"context_line":"This spec extends the volume operations enabled by [7]."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"There is a parallel (but not dependant) spec [6] that addresses bug [5]."},{"line_number":281,"context_line":"That spec is not required for this one, but it is worth noting that this"},{"line_number":282,"context_line":"feature will benefit from the general bug fix dealt with there."},{"line_number":283,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_ed148da1","line":280,"range":{"start_line":280,"start_character":29,"end_line":280,"end_character":38},"updated":"2018-10-23 17:20:31.000000000","message":"dependent","commit_id":"0a49fa011e8e9487f823c04f3f031ccf1f1c13a1"}]}