)]}'
{"specs/ocata/approved/cinder-new-attach-apis.rst":[{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"1ec5066f1282270060b8eebc92d306c8b68d706a","unresolved":false,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"In particular, please note:"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"* Volume attachment is specific to a host name, instance uuid, and volume uuid"},{"line_number":46,"context_line":"* You can have multiple attachments to the same volume, different instances,"},{"line_number":47,"context_line":"  but on the same host."},{"line_number":48,"context_line":"* volume connections on a host can be shared with other volumes that are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a8ec9b2_3335ecda","line":45,"range":{"start_line":45,"start_character":37,"end_line":45,"end_character":46},"updated":"2016-09-20 16:13:21.000000000","message":"s/host/node/? How does this interact with Ironic/VMware?\n\nThis question may be way out of date.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7e7ed5da385f2f315f22a6c59c25ea1c8a0d9788","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"reserve_volume"},{"line_number":75,"context_line":"  We call this in the API to make sure we claim the volume for the specific"},{"line_number":76,"context_line":"  instance_uuid (unless its multi-attach)."},{"line_number":77,"context_line":"  If its already claimed, we fail any attach request in the API."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_b7a50148","line":74,"updated":"2016-09-26 18:05:18.000000000","message":"Lets rethink this as CRUD on attachments of a volume\n\nreserve takes:\n* host\n* instance\n* volume\n\nothers just work on attachement id","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"2f80308fd4729069b71257d793571921e80092ee","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"reserve_volume"},{"line_number":75,"context_line":"  We call this in the API to make sure we claim the volume for the specific"},{"line_number":76,"context_line":"  instance_uuid (unless its multi-attach)."},{"line_number":77,"context_line":"  If its already claimed, we fail any attach request in the API."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"create_attachment"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a8ec9b2_33f32ca1","line":76,"range":{"start_line":76,"start_character":17,"end_line":76,"end_character":41},"updated":"2016-09-20 16:25:58.000000000","message":"Don\u0027t know if that\u0027s what you\u0027re implying, but I think Nova should always call this. Cinder can complain if the volume isn\u0027t multi-attach.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"86dc12921df3796d3b57a1e44eb4dcf59b31f6ff","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"reserve_volume"},{"line_number":75,"context_line":"  We call this in the API to make sure we claim the volume for the specific"},{"line_number":76,"context_line":"  instance_uuid (unless its multi-attach)."},{"line_number":77,"context_line":"  If its already claimed, we fail any attach request in the API."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"create_attachment"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_eb4ec66d","line":76,"range":{"start_line":76,"start_character":17,"end_line":76,"end_character":41},"in_reply_to":"5a8bc5a2_1679a92f","updated":"2016-09-26 17:49:32.000000000","message":"Yeah, I was unclear, we always call this, its just the claim is not specific to the instance-uuid in the case of multi-attach, its a bit more complicated in that case.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"7d8e052b19b42d690e0bbbc45249efdf13c69355","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"reserve_volume"},{"line_number":75,"context_line":"  We call this in the API to make sure we claim the volume for the specific"},{"line_number":76,"context_line":"  instance_uuid (unless its multi-attach)."},{"line_number":77,"context_line":"  If its already claimed, we fail any attach request in the API."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"create_attachment"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_1679a92f","line":76,"range":{"start_line":76,"start_character":17,"end_line":76,"end_character":41},"in_reply_to":"7a8ec9b2_33f32ca1","updated":"2016-09-23 18:05:29.000000000","message":"Agree. For multi-attach Cinder returns “in-use” if it\u0027s already attached. Nova should rely on that rather than figuring out multi-attach and not making a call.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7e7ed5da385f2f315f22a6c59c25ea1c8a0d9788","unresolved":false,"context_lines":[{"line_number":76,"context_line":"  instance_uuid (unless its multi-attach)."},{"line_number":77,"context_line":"  If its already claimed, we fail any attach request in the API."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"create_attachment"},{"line_number":80,"context_line":"  We call this once we are ready to make the attachment on a specific host"},{"line_number":81,"context_line":"  for a specific instance uuid. The instance must already be associated"},{"line_number":82,"context_line":"  with the volume by calling reserve_volume, otherwise create_attachment"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_7cd0bef6","line":79,"updated":"2016-09-26 18:05:18.000000000","message":"talk about how this gives the info for os-brick.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"2f80308fd4729069b71257d793571921e80092ee","unresolved":false,"context_lines":[{"line_number":84,"context_line":"  The API call returns the connection_info we pass to os-brick, and the"},{"line_number":85,"context_line":"  attachment_uuid."},{"line_number":86,"context_line":"  Should os-brick fail to attach, we call remove_attachment to tell cinder"},{"line_number":87,"context_line":"  that we have closed the connection??"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"remove_attachment"},{"line_number":90,"context_line":"  We call this to find out the information to pass to os-brick to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a8ec9b2_33724ce4","line":87,"updated":"2016-09-20 16:25:58.000000000","message":"Can we define remove_attachment to be an idempotent operation? Then this is always safe.\n\nAlso, can we be explicit that cinder gives connection_info to Nova, but the only thing Nova ever passes is attachment_uuid. If cinder requires connection_info for subsequent operations, it should also store it.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"ccf7835172cca7979a8129f1649e30bb3fb4333e","unresolved":false,"context_lines":[{"line_number":84,"context_line":"  The API call returns the connection_info we pass to os-brick, and the"},{"line_number":85,"context_line":"  attachment_uuid."},{"line_number":86,"context_line":"  Should os-brick fail to attach, we call remove_attachment to tell cinder"},{"line_number":87,"context_line":"  that we have closed the connection??"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"remove_attachment"},{"line_number":90,"context_line":"  We call this to find out the information to pass to os-brick to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_cff64d5c","line":87,"in_reply_to":"5a8bc5a2_2b56eecd","updated":"2016-09-27 10:04:32.000000000","message":"Can cinder handle the statefulness internally? It\u0027s only the api which needs to be idempotent.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"a886cb2bec051f2150d5c1bb04c07d510dffcd86","unresolved":false,"context_lines":[{"line_number":84,"context_line":"  The API call returns the connection_info we pass to os-brick, and the"},{"line_number":85,"context_line":"  attachment_uuid."},{"line_number":86,"context_line":"  Should os-brick fail to attach, we call remove_attachment to tell cinder"},{"line_number":87,"context_line":"  that we have closed the connection??"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"remove_attachment"},{"line_number":90,"context_line":"  We call this to find out the information to pass to os-brick to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_1ed6a54e","line":87,"in_reply_to":"5a8bc5a2_cff64d5c","updated":"2016-09-27 11:11:21.000000000","message":"Basically no. We need os-brick to do the disconnect on our end, only then we can really call remove_attachment. Anyways, the new version of this should give a lot more context on the details and the expected behaviours of Nova, Cinder and os-brick at each step.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"86dc12921df3796d3b57a1e44eb4dcf59b31f6ff","unresolved":false,"context_lines":[{"line_number":84,"context_line":"  The API call returns the connection_info we pass to os-brick, and the"},{"line_number":85,"context_line":"  attachment_uuid."},{"line_number":86,"context_line":"  Should os-brick fail to attach, we call remove_attachment to tell cinder"},{"line_number":87,"context_line":"  that we have closed the connection??"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"remove_attachment"},{"line_number":90,"context_line":"  We call this to find out the information to pass to os-brick to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_2b56eecd","line":87,"in_reply_to":"7a8ec9b2_33724ce4","updated":"2016-09-26 17:49:32.000000000","message":"The problem id what happens on the backend, there are stateful thing we are changing here.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e0004b402d22bf653edf60090038bcb0f1c60c38","unresolved":false,"context_lines":[{"line_number":86,"context_line":"  Should os-brick fail to attach, we call remove_attachment to tell cinder"},{"line_number":87,"context_line":"  that we have closed the connection??"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"remove_attachment"},{"line_number":90,"context_line":"  We call this to find out the information to pass to os-brick to"},{"line_number":91,"context_line":"  perform the removal of the volume attachment, given a specific"},{"line_number":92,"context_line":"  attachment_uuid."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_d227fbb3","line":89,"updated":"2016-09-26 18:06:14.000000000","message":"we call this after os-brick has done its thing.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e0004b402d22bf653edf60090038bcb0f1c60c38","unresolved":false,"context_lines":[{"line_number":98,"context_line":"  TODO: do we need a call back to cinder to confirm the remove_attachment"},{"line_number":99,"context_line":"  happened OK, or is this API meant to that?"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"unreserve"},{"line_number":102,"context_line":"  TODO???"},{"line_number":103,"context_line":"  Possibly use this to release the instance\u0027s claim on the volume,"},{"line_number":104,"context_line":"  i.e. the reverse of reserve?"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_320c9f3a","line":101,"updated":"2016-09-26 18:06:14.000000000","message":"this should return the info to tell os-brick what to do for the remove, including connection info if needed.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7e7ed5da385f2f315f22a6c59c25ea1c8a0d9788","unresolved":false,"context_lines":[{"line_number":101,"context_line":"unreserve"},{"line_number":102,"context_line":"  TODO???"},{"line_number":103,"context_line":"  Possibly use this to release the instance\u0027s claim on the volume,"},{"line_number":104,"context_line":"  i.e. the reverse of reserve?"},{"line_number":105,"context_line":"  Or is this to confirm the remove_attachment has completed?"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_7ca27e9a","line":104,"updated":"2016-09-26 18:05:18.000000000","message":"yeah, this should be called before remove_attachment, to stop races.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"2f80308fd4729069b71257d793571921e80092ee","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  TODO???"},{"line_number":103,"context_line":"  Possibly use this to release the instance\u0027s claim on the volume,"},{"line_number":104,"context_line":"  i.e. the reverse of reserve?"},{"line_number":105,"context_line":"  Or is this to confirm the remove_attachment has completed?"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Alternatives"},{"line_number":108,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a8ec9b2_fe0b4b22","line":105,"updated":"2016-09-20 16:25:58.000000000","message":"swap_volume?","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7e7ed5da385f2f315f22a6c59c25ea1c8a0d9788","unresolved":false,"context_lines":[{"line_number":103,"context_line":"  Possibly use this to release the instance\u0027s claim on the volume,"},{"line_number":104,"context_line":"  i.e. the reverse of reserve?"},{"line_number":105,"context_line":"  Or is this to confirm the remove_attachment has completed?"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"Alternatives"},{"line_number":108,"context_line":"------------"},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_5ce942e5","line":106,"updated":"2016-09-26 18:05:18.000000000","message":"Lets add live-migrate flow:\n\ncreate with new host-uuid, remove old one.\n\nSimilar for multi-attach, and migrate, shelve (host \u003d None), etc.","commit_id":"868ca20963736aa6515e733e93e39c6af92502d3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":44,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":45,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":46,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":47,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"In particular, please note:"},{"line_number":50,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_26afb795","line":47,"updated":"2016-10-04 14:57:14.000000000","message":"What about the case where we want to be able to detach the root volume of a powered-off instance, or attach/detach during shelve? Mentioning this in case we need to be able to short-circuit a volume from \"available\" to the state it\u0027s in whilst shelved (i.e. assigned but not connected or whatever).","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":44,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":45,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":46,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":47,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"In particular, please note:"},{"line_number":50,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_af489388","line":47,"in_reply_to":"3a98d1f4_26afb795","updated":"2016-10-06 15:28:42.000000000","message":"Yeah, I should add those.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"7ec19788bae4294eb683fd3258f374c9da8ec88a","unresolved":false,"context_lines":[{"line_number":64,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":65,"context_line":"the service is SIG_HUP or restarted. Based on the cached Cinder"},{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a8bc5a2_2cc95b5b","line":67,"updated":"2016-09-27 19:29:55.000000000","message":"Honestly, the GET / call to figure out the version number is probably not that bad. I would leave caching strategy to later.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":64,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":65,"context_line":"the service is SIG_HUP or restarted. Based on the cached Cinder"},{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_66f45f87","line":67,"in_reply_to":"3a98d1f4_4312dcb5","updated":"2016-10-04 14:57:14.000000000","message":"The problem comes when we startup while cinder is old, then suddenly notice that it\u0027s new, and start doing the new interaction pattern with a volume that is in an intermediate state.\n\nWe have plenty of other places where we cache things like the RPC version until SIGHUP. TBH, I think I\u0027d just cache it and require a restart to ensure that we\u0027re not in the middle of an attach or migration when we re-notice the cinder version.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":64,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":65,"context_line":"the service is SIG_HUP or restarted. Based on the cached Cinder"},{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_6f1ccb77","line":67,"in_reply_to":"3a98d1f4_66f45f87","updated":"2016-10-06 15:28:42.000000000","message":"Good idea, force the restart does solve a whole heap of problems here.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"0144ec7bbea0893308b663aeab18239d56bad58a","unresolved":false,"context_lines":[{"line_number":64,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":65,"context_line":"the service is SIG_HUP or restarted. Based on the cached Cinder"},{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_4312dcb5","line":67,"in_reply_to":"5a8bc5a2_2cc95b5b","updated":"2016-09-28 21:52:39.000000000","message":"+1","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7f80f68737d986ef73cc1a1c645db05a17790348","unresolved":false,"context_lines":[{"line_number":64,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":65,"context_line":"the service is SIG_HUP or restarted. Based on the cached Cinder"},{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a8bc5a2_b6391a44","line":67,"in_reply_to":"5a8bc5a2_2cc95b5b","updated":"2016-09-28 10:40:04.000000000","message":"True, that would help reduce the scope here.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"0144ec7bbea0893308b663aeab18239d56bad58a","unresolved":false,"context_lines":[{"line_number":66,"context_line":"microversion, we use either the existing Cinder interaction model, or the"},{"line_number":67,"context_line":"new interaction model."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":70,"context_line":"this in mind in how the code is structured. It should be possible to ensure"},{"line_number":71,"context_line":"this complexity is dealt with behind the volume api. It is likely we have two"},{"line_number":72,"context_line":"implementations for the volume API that are chosen depending on the cached API"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_c03a62cd","line":69,"range":{"start_line":69,"start_character":52,"end_line":69,"end_character":53},"updated":"2016-09-28 21:52:39.000000000","message":"be","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"7ec19788bae4294eb683fd3258f374c9da8ec88a","unresolved":false,"context_lines":[{"line_number":77,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":78,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":79,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":80,"context_line":"the Ocata timeframe, so we release with the new workflow on by default."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"},{"line_number":83,"context_line":"calls. For now I will use the names I prefer."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a8bc5a2_cce0f7cf","line":80,"updated":"2016-09-27 19:29:55.000000000","message":"+1","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"0144ec7bbea0893308b663aeab18239d56bad58a","unresolved":false,"context_lines":[{"line_number":83,"context_line":"calls. For now I will use the names I prefer."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":86,"context_line":"* initialize_attachment is what was create_attachment"},{"line_number":87,"context_line":"* initialize_detachment is what was unreserve"},{"line_number":88,"context_line":"* delete is what was remove_attachment"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_402bb2eb","line":86,"range":{"start_line":86,"start_character":36,"end_line":86,"end_character":53},"updated":"2016-09-28 21:52:39.000000000","message":"This was initialize connection + create attachment before. Now both calls are merged to one.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"43c202c9d5c7427fcb2dc2a5ebe64a704e6fe8f8","unresolved":false,"context_lines":[{"line_number":83,"context_line":"calls. For now I will use the names I prefer."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":86,"context_line":"* initialize_attachment is what was create_attachment"},{"line_number":87,"context_line":"* initialize_detachment is what was unreserve"},{"line_number":88,"context_line":"* delete is what was remove_attachment"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_aa7dda1d","line":86,"range":{"start_line":86,"start_character":36,"end_line":86,"end_character":53},"in_reply_to":"3a98d1f4_402bb2eb","updated":"2016-09-30 09:40:15.000000000","message":"True, I was writing this about vs the current cinder spec and previous patchset, but this is not right for this spec, it should be vs the current situation.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"0144ec7bbea0893308b663aeab18239d56bad58a","unresolved":false,"context_lines":[{"line_number":85,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":86,"context_line":"* initialize_attachment is what was create_attachment"},{"line_number":87,"context_line":"* initialize_detachment is what was unreserve"},{"line_number":88,"context_line":"* delete is what was remove_attachment"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":91,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_a3ec80c8","line":88,"range":{"start_line":88,"start_character":21,"end_line":88,"end_character":38},"updated":"2016-09-28 21:52:39.000000000","message":"similarly terminate + detach is merged to one","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":92,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid, host_uuid)"},{"line_number":93,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":94,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":95,"context_line":"  server_uuid. In some cases the host_uuid may be None, such as when"},{"line_number":96,"context_line":"  booting an server."},{"line_number":97,"context_line":"  For cases where we are creating a second host attachment for the same"},{"line_number":98,"context_line":"  server_uuid and volume_uuid, we should also include a \"reason\" parameter"},{"line_number":99,"context_line":"  that takes a string upto 50 characters in length. Nova will use this to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_265ed776","line":96,"range":{"start_line":95,"start_character":15,"end_line":96,"end_character":20},"updated":"2016-10-04 14:57:14.000000000","message":"Or when attaching to a shelved instance?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":92,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid, host_uuid)"},{"line_number":93,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":94,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":95,"context_line":"  server_uuid. In some cases the host_uuid may be None, such as when"},{"line_number":96,"context_line":"  booting an server."},{"line_number":97,"context_line":"  For cases where we are creating a second host attachment for the same"},{"line_number":98,"context_line":"  server_uuid and volume_uuid, we should also include a \"reason\" parameter"},{"line_number":99,"context_line":"  that takes a string upto 50 characters in length. Nova will use this to"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_920a1c20","line":96,"range":{"start_line":95,"start_character":15,"end_line":96,"end_character":20},"in_reply_to":"3a98d1f4_265ed776","updated":"2016-10-06 15:28:42.000000000","message":"yes, that too. will add.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  booting an server."},{"line_number":97,"context_line":"  For cases where we are creating a second host attachment for the same"},{"line_number":98,"context_line":"  server_uuid and volume_uuid, we should also include a \"reason\" parameter"},{"line_number":99,"context_line":"  that takes a string upto 50 characters in length. Nova will use this to"},{"line_number":100,"context_line":"  record the API action that is causes the duplicate host attachment, i.e."},{"line_number":101,"context_line":"  {\"reason\": \"os-migrateLive\"}. If no reason is given, and there is already"},{"line_number":102,"context_line":"  an attachment for the given host, creating the attachment should fail."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_a6e1079d","line":99,"range":{"start_line":99,"start_character":22,"end_line":99,"end_character":26},"updated":"2016-10-04 14:57:14.000000000","message":"\"up to\"","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  For cases where we are creating a second host attachment for the same"},{"line_number":98,"context_line":"  server_uuid and volume_uuid, we should also include a \"reason\" parameter"},{"line_number":99,"context_line":"  that takes a string upto 50 characters in length. Nova will use this to"},{"line_number":100,"context_line":"  record the API action that is causes the duplicate host attachment, i.e."},{"line_number":101,"context_line":"  {\"reason\": \"os-migrateLive\"}. If no reason is given, and there is already"},{"line_number":102,"context_line":"  an attachment for the given host, creating the attachment should fail."},{"line_number":103,"context_line":"  The first attachment should never include a reason, and so Cinder checks"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_06e71bad","line":100,"range":{"start_line":100,"start_character":29,"end_line":100,"end_character":31},"updated":"2016-10-04 14:57:14.000000000","message":"s/is//","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  an attachment for the given host, creating the attachment should fail."},{"line_number":103,"context_line":"  The first attachment should never include a reason, and so Cinder checks"},{"line_number":104,"context_line":"  there are no other attachments on other hosts for that"},{"line_number":105,"context_line":"  volume_uuid and server_uuid combination."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"},{"line_number":108,"context_line":"  {\"initialize_attachment\": {\"host\": \"\u003chost_uuid\u003e\"}}"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_86924bf5","line":105,"updated":"2016-10-04 14:57:14.000000000","message":"It seems odd to me to enforce the single-attach like this, instead of with another flag or state machine on the cinder side...","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  an attachment for the given host, creating the attachment should fail."},{"line_number":103,"context_line":"  The first attachment should never include a reason, and so Cinder checks"},{"line_number":104,"context_line":"  there are no other attachments on other hosts for that"},{"line_number":105,"context_line":"  volume_uuid and server_uuid combination."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"},{"line_number":108,"context_line":"  {\"initialize_attachment\": {\"host\": \"\u003chost_uuid\u003e\"}}"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_729f50b4","line":105,"in_reply_to":"3a98d1f4_86924bf5","updated":"2016-10-06 15:28:42.000000000","message":"Let me re-work this with your sensible suggestion of always specifying the host here. I think that clears up a whole heap of rubbish.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  the hypervisor. Cinder is responsible for ensuring if there is already"},{"line_number":112,"context_line":"  a connection on the host, that connection is not shared. The attachment"},{"line_number":113,"context_line":"  gets moved into the ATTACHING state."},{"line_number":114,"context_line":"  If the host is None, initialize_attachment can be passed a host (for the"},{"line_number":115,"context_line":"  attach volume at boot time case). If the host matches what is already set,"},{"line_number":116,"context_line":"  that is also accepted."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"},{"line_number":119,"context_line":"  {\"confirm_attachment\": null}"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_db56f305","line":116,"range":{"start_line":114,"start_character":2,"end_line":116,"end_character":24},"updated":"2016-10-04 14:57:14.000000000","message":"I\u0027m not sure what this means. If you called this once (or maybe haven\u0027t called it) then host is None and you can update the host? If host is \"foo\" and you call this again with \"foo\", then it succeeds (idempotency?).","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  the hypervisor. Cinder is responsible for ensuring if there is already"},{"line_number":112,"context_line":"  a connection on the host, that connection is not shared. The attachment"},{"line_number":113,"context_line":"  gets moved into the ATTACHING state."},{"line_number":114,"context_line":"  If the host is None, initialize_attachment can be passed a host (for the"},{"line_number":115,"context_line":"  attach volume at boot time case). If the host matches what is already set,"},{"line_number":116,"context_line":"  that is also accepted."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"},{"line_number":119,"context_line":"  {\"confirm_attachment\": null}"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_92593c01","line":116,"range":{"start_line":114,"start_character":2,"end_line":116,"end_character":24},"in_reply_to":"1a95cdbc_db56f305","updated":"2016-10-06 15:28:42.000000000","message":"So this operation is not idempotent.\n\nThe idea is during the boot process, you know its attached to the instance, but you don\u0027t know the host. So at this point, you need to set the host flag.\n\nMy mumbling was just, if you pass a host flag that matches what is already assigned, thats fine. If its None you can pass any host flag. Was just thinking of making the client simpler, we can always pass the host, which should either match, or update from None.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":119,"context_line":"  {\"confirm_attachment\": null}"},{"line_number":120,"context_line":"  This is called once the os-brick host attach has completed."},{"line_number":121,"context_line":"  The attachment gets moved into the ATTACHED state."},{"line_number":122,"context_line":"  This call exists because we some driver have volumes share attachments"},{"line_number":123,"context_line":"  Note: if the os-brick called failed, Nova deletes the attachment."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_9bb54bd2","line":122,"range":{"start_line":122,"start_character":29,"end_line":122,"end_character":30},"updated":"2016-10-04 14:57:14.000000000","message":"have? This sentence probably needs some repair :)","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  This is called once the os-brick host attach has completed."},{"line_number":121,"context_line":"  The attachment gets moved into the ATTACHED state."},{"line_number":122,"context_line":"  This call exists because we some driver have volumes share attachments"},{"line_number":123,"context_line":"  Note: if the os-brick called failed, Nova deletes the attachment."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e/action"},{"line_number":126,"context_line":"  {\"initialize_detachment\": null}"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_7bc15f2e","line":123,"range":{"start_line":123,"start_character":24,"end_line":123,"end_character":30},"updated":"2016-10-04 14:57:14.000000000","message":"\"call\"","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":136,"context_line":"  This is also called when os_brick fails to attach a volume, and we are"},{"line_number":137,"context_line":"  still in the ATTACHING state."},{"line_number":138,"context_line":"  Note: if in the ATTACHED state, you must first call initialize_detachment."},{"line_number":139,"context_line":"  TODO - what happens of os_brick fails at this point?? Should we put the"},{"line_number":140,"context_line":"  volume into some kind of error state, or we just delete it anyway?"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_e48230c8","line":139,"range":{"start_line":139,"start_character":22,"end_line":139,"end_character":24},"updated":"2016-10-04 14:57:14.000000000","message":"s/of/if. Also, I think one question mark is plenty :)","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":19590,"name":"Sarafraj Singh","email":"Sarafraj.Singh@intel.com","username":"sarafrajsingh"},"change_message_id":"87b8003b7604a59af34334080dc3973af26937d3","unresolved":false,"context_lines":[{"line_number":152,"context_line":"  If in the ATTACHED state, this includes the host_connect_info."},{"line_number":153,"context_line":"  If in the DETACHING state, this includes the host_detach_info."},{"line_number":154,"context_line":"  Note: you always get 404 for a deleted attachment."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"To make things clear, lets think through some of the common flows:"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Spawn and Delete server"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_8620729d","line":155,"updated":"2016-09-28 21:54:41.000000000","message":"Is there any case to update volume?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"43c202c9d5c7427fcb2dc2a5ebe64a704e6fe8f8","unresolved":false,"context_lines":[{"line_number":152,"context_line":"  If in the ATTACHED state, this includes the host_connect_info."},{"line_number":153,"context_line":"  If in the DETACHING state, this includes the host_detach_info."},{"line_number":154,"context_line":"  Note: you always get 404 for a deleted attachment."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"To make things clear, lets think through some of the common flows:"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Spawn and Delete server"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_2ab70ad9","line":155,"in_reply_to":"3a98d1f4_8620729d","updated":"2016-09-30 09:40:15.000000000","message":"I think it only changes via actions right now. So its just reporting the current state, I guess. For now I don\u0027t have any use case for update, but it that way.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":161,"context_line":"* Migrate"},{"line_number":162,"context_line":"* Evacuate"},{"line_number":163,"context_line":"* Shelve"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Note: for simplicity I am leaving out the volume_uuid that is required for"},{"line_number":166,"context_line":"every one of the API calls."},{"line_number":167,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_a462e814","line":164,"updated":"2016-10-04 14:57:14.000000000","message":"Just to be clear, if cinder is upgraded, but nova is not (in the case where a control plane is fully upgraded but computes lag), we will have people  using both the older and newer mechanisms simultaneously.\n\nIn that case, are we sure that if we initialize the attachment with the new api from our control plane, that computes will be able to do the same thing they did before to finish the attachment? And simultaneously, if an attachment was completed by an older compute, will the newer control plane be able to use the newer detach process with an attachment id properly?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":161,"context_line":"* Migrate"},{"line_number":162,"context_line":"* Evacuate"},{"line_number":163,"context_line":"* Shelve"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Note: for simplicity I am leaving out the volume_uuid that is required for"},{"line_number":166,"context_line":"every one of the API calls."},{"line_number":167,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_522c1402","line":164,"in_reply_to":"1a95cdbc_a462e814","updated":"2016-10-06 15:28:42.000000000","message":"Yeah, we need to be clear about these details.\n\nI was trying to get agreement on the end goal. We don\u0027t have that yet.\n\nCinder needs to deal with these differences, I suspect. I think they are so similar to the old way of doing this, it should be possible.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":12924,"name":"Patrick East","email":"east.patrick@gmail.com","username":"patrick.east"},"change_message_id":"7a75dec85cc9d287109a6e8957a8ca489000e0b7","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":184,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":185,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":186,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Interesting edge cases:"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"* should we fail to boot, and need to retry the boot on a new host,"},{"line_number":191,"context_line":"  we first create a new attachment with host\u003dNone, and we do a full detach"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a98d1f4_59984078","line":188,"range":{"start_line":185,"start_character":0,"end_line":188,"end_character":23},"updated":"2016-10-04 00:45:10.000000000","message":"One situation (not really specific to spawn and delete) I would like to make sure we consider in the new and improved attach code is to have better support for iscsi connections where we have more than one lun per session. I figure this is a good opportunity to see what we can do to improve things. The issue we have right now is that there is a potential race with detaching if another attach is being done... the flow is something like:\n\n\n\nos-brick disconnect_volume(volA, ...)\n\nos-brick connect_volume(volB, ...)\n\ndelete_attachment(volA, ...)\n\n\nThe problem being that in disconnect_volume we do device deletes on the like /dev/sdX paths and remove them, but if between unlocking from disconnect_volume and delete_attachment (the stuff**) we start another os-brick connect_volume(...) it will run an iscsi rescan. After that all our freshly deleted /dev/sdX paths come back to us if the iscsi session was still going because until delete_attachment is called the device is still being exported as a iscsi target by the backend array. It is also unfortunately (in this case) not safe inside the os-brick connect/disconnect locking :(\n\n\nHopefully that makes some sense... this is easier to explain with a whiteboard. Anyway, this isn\u0027t an issue for something like LVM iSCSI since it only uses a single lun per session, so it will *always* log out of the session and have a single lun for each.\n\n\nSo, with all that in mind, the most simple thing would be to have some way to synchronize disconnecting from os-brick and telling cinder to remove the exposed lun for that host. I don\u0027t really like the idea of just locking around it, but maybe have conditional locks if the info from initialize_connection asks for it.\n\n\nAn alternative is maybe we make os-brick have a flush api so we can do something more like:\n\n\n* disconnect volume from VM (in this case by deleting the VM)\n* flush any pending io via os-brick\n* terminate the connection with delete_attachment\n* disconnect the volume from the initiator\n\n\nIt\u0027s a little more messy since it might rip the exposed lun out from underneath the initiator by doing the delete_attachment first, but assuming we\u0027ve disconnected from the VM and flushed all the pending IO it seems like relatively low risk. I don\u0027t know how this would work for all backends though... it might fall more into the category of requiring modifications to cinder drivers to support it and has the drawback of not being very easy to do conditionally if it won\u0027t work for everyone.\n\n\n\nI\u0027m sure there are other ways we could handle this too, just throwing those out as possible ideas. Curious to see what others think on the issue.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":184,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":185,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":186,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Interesting edge cases:"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"* should we fail to boot, and need to retry the boot on a new host,"},{"line_number":191,"context_line":"  we first create a new attachment with host\u003dNone, and we do a full detach"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_3d191989","line":188,"range":{"start_line":185,"start_character":0,"end_line":188,"end_character":23},"in_reply_to":"3a98d1f4_59984078","updated":"2016-10-06 15:28:42.000000000","message":"Agreed. The above flow should take this into account.\n\nThe DETACHING and ATTACHING state should only be allowed for one attachment per host, which should cover this, I thought?\n\nI should cover this case more explicitly in here, but I intend for Cinder to the the state tracking so Nova doesn\u0027t tell os-brick to do the wrong thing.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"* should we fail to boot, and need to retry the boot on a new host,"},{"line_number":191,"context_line":"  we first create a new attachment with host\u003dNone, and we do a full detach"},{"line_number":192,"context_line":"  for the existing host attachment."},{"line_number":193,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":194,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":195,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_c41c547a","line":192,"updated":"2016-10-04 14:57:14.000000000","message":"gross :(","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"* should we fail to boot, and need to retry the boot on a new host,"},{"line_number":191,"context_line":"  we first create a new attachment with host\u003dNone, and we do a full detach"},{"line_number":192,"context_line":"  for the existing host attachment."},{"line_number":193,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":194,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":195,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_58e193cf","line":192,"in_reply_to":"1a95cdbc_c41c547a","updated":"2016-10-06 15:28:42.000000000","message":"Yeah, but its clear that we need to manage the attach/detach on a per host basis carefully. And reschedule is just a regular \"VM move / rebuild on new host\" event here. Even if it does sound more complicated than that.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":216,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Note: only real different with boot is where the host is specified during the"},{"line_number":219,"context_line":"create_attachment and initialize_attachment calls."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Live-migrate"},{"line_number":222,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_af81e14f","line":219,"updated":"2016-10-04 14:57:14.000000000","message":"Why should we do it differently? Why not just create with no host, initialize with a host?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":216,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Note: only real different with boot is where the host is specified during the"},{"line_number":219,"context_line":"create_attachment and initialize_attachment calls."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Live-migrate"},{"line_number":222,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_78ff2f67","line":219,"in_reply_to":"1a95cdbc_af81e14f","updated":"2016-10-06 15:28:42.000000000","message":"/me face palm.\n\nThats a better idea.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":224,"context_line":"During pre-live-migration-at-destination we"},{"line_number":225,"context_line":"(Source is h1 and destination is h2):"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"* attachment_uuid \u003d create_attachment(s1, h2, reason\u003d\"os-migrateLive\")"},{"line_number":228,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":229,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid)"},{"line_number":230,"context_line":"* talk to os-brick to do what is needed on the host"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_0ff815e5","line":227,"updated":"2016-10-04 14:57:14.000000000","message":"Again, why do this differently from boot?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":224,"context_line":"During pre-live-migration-at-destination we"},{"line_number":225,"context_line":"(Source is h1 and destination is h2):"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"* attachment_uuid \u003d create_attachment(s1, h2, reason\u003d\"os-migrateLive\")"},{"line_number":228,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":229,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid)"},{"line_number":230,"context_line":"* talk to os-brick to do what is needed on the host"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_b840d7a6","line":227,"in_reply_to":"1a95cdbc_0ff815e5","updated":"2016-10-06 15:28:42.000000000","message":"yeah, thats a better idea, lets see if that works.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":240,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"We are now back to having just the one attachment, the new attachment on the"},{"line_number":243,"context_line":"destination host."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":"Migrate"},{"line_number":246,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_afcf21b2","line":243,"updated":"2016-10-04 14:57:14.000000000","message":"What about the rollback case?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":240,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"We are now back to having just the one attachment, the new attachment on the"},{"line_number":243,"context_line":"destination host."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":"Migrate"},{"line_number":246,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_f8217ffc","line":243,"in_reply_to":"1a95cdbc_afcf21b2","updated":"2016-10-06 15:28:42.000000000","message":"Yeah, I should go through those here to make sure we are not missing anything.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":256,"context_line":"TODO"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"Add new attachment on new host."},{"line_number":259,"context_line":"Make administrator tidy up the connection on the old host."},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"Shelve"},{"line_number":262,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_4ff69dd8","line":259,"updated":"2016-10-04 14:57:14.000000000","message":"Should\u0027t we delete the detachment, re-attach to the new host and then make the compute node verify all its attachments on startup? Any that it gets a 404 for it can remove. Maybe we don\u0027t have the proper API to list based on those, and haven\u0027t stored the right identifiers? Still, evacuate is starting to be used to heavily, and mostly by bfv pet people, that I think a new thing that \"requires administrator cleanup\" is probably not a good idea.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":264,"context_line":"TODO"},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"When offloading a server, we create a new attachment with a null host, and do"},{"line_number":267,"context_line":"a full attach of the existing attachment."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Alternatives"},{"line_number":270,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_afd2c132","line":267,"updated":"2016-10-04 14:57:14.000000000","message":"What does this mean? Create an attachment with no host so that the volume is stuck in \"Attaching\" state forever (until unshelve)?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d983d1136deda662b8a5e500ceb80efb7bf12fb1","unresolved":false,"context_lines":[{"line_number":276,"context_line":""},{"line_number":277,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":278,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":279,"context_line":"attachment_uuid for each volume attachment."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"REST API impact"},{"line_number":282,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_4f921d59","line":279,"updated":"2016-10-04 14:57:14.000000000","message":"And we\u0027ll store that where? In the old connection_info field? What about un-upgraded services that will expect that to still be whole?\n\nIf not there, then a new field? How do we handle older computes during an upgrade?","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"337b9fa7a044952d341bbb51777ec869028b6d42","unresolved":false,"context_lines":[{"line_number":276,"context_line":""},{"line_number":277,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":278,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":279,"context_line":"attachment_uuid for each volume attachment."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"REST API impact"},{"line_number":282,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_98715be3","line":279,"in_reply_to":"1a95cdbc_4f921d59","updated":"2016-10-06 15:28:42.000000000","message":"So if the attachment_uuid is missing, we can just look that up in Cinder, much like we were going to do for multi-attach in the proposed code for that.\n\nProbably best to do this in a new field, given we could just look it up. Its more so we know whats going on.\n\nAs above, need to write all these details out problem, was first focusing on more agreement around the API flow.","commit_id":"07a573cc110ec139e5be2803ce19efab4538f1b1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":44,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":45,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":46,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":47,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":48,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":49,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":50,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_6fbd1102","line":47,"range":{"start_line":47,"start_character":23,"end_line":47,"end_character":27},"updated":"2016-10-17 16:40:21.000000000","message":"from","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  As such, need to take care when removing that connection, and not adding two"},{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"fa6399be_2fc9595b","line":64,"range":{"start_line":63,"start_character":2,"end_line":64,"end_character":70},"updated":"2016-10-17 16:40:21.000000000","message":"Do you mean cinder talking directly to brick? Or nova asking cinder for some information and then nova making a decision whether to call disconnect_volume in brick? I\u0027m thinking of the often mentioned \"is it safe to detach\" cinder API idea.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"fa6399be_62dc1f47","line":64,"in_reply_to":"fa6399be_22a40007","updated":"2016-10-18 13:15:10.000000000","message":"The problem is Nova needs to then be modified to know about every type of storage, and that what we created Cinder and os-brick to deal with.\n\nI much prefer the cinder backend being able to tell cinder whats required, and that message being transparently passed to os-brick. We need all the clients to understand the concept of a shared connection. The backend should totally be responsible for activating any protection that is needed.\n\nIn terms of os-brick changes, I believe the only thing I am suggesting is a new no-op plugin for disconnect. We could do a no-op for connect, but I think I prefer a way to check the connection (which the default implementation could be a noop).\n\nI think the bit I am missing here is the info we need from os-brick on the volume connector bit we need Nova to understand. I need to go read more about that.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"fa6399be_e43a2398","line":64,"in_reply_to":"fa6399be_2fc9595b","updated":"2016-10-17 17:00:18.000000000","message":"I was thinking nova always calls brick, but it could be cinder telling brick to do a noop or just check the connection. Means nova has less to interpret. It\u0027s not cinder calling brick, more a pass through.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"fa6399be_e4ae71e6","line":64,"in_reply_to":"fa6399be_62dc1f47","updated":"2016-10-18 17:56:58.000000000","message":"Again, keep in mind that not all virt drivers in nova are using os-brick yet. Therefore, it might make sense for cinder to return something in the connection_info dict describing if the backing volume store shares connections or not. Then any nova virt driver that wants to support multiattach would be checking that along with the number of active attachments/connections on a given host if it can disconnect, or simply decrement the attachment count in cinder for that volume.\n\nIf we want to bake logic into os-brick for multiattach, then fine, but that means you have to use os-brick to support multiattach. I know hyperv is moving to it, but not sure about plans for vmware or xen drivers.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"fa6399be_22a40007","line":64,"in_reply_to":"fa6399be_e43a2398","updated":"2016-10-17 22:43:14.000000000","message":"I\u0027m still not sure I agree with this, cinder doesn\u0027t currently have any communication with the brick piece, and brick was intended to be a generic lib of wrappers around the connection process and that was really about it.\n\nIt seems to me that the consumer (in this case Nova) should be responsible for keeping track of what it has or has not connected.  Ideally it should also be able to determine what\u0027s using a shared connection and what\u0027s not, but I realize that with some cinder backends that may be more difficult so we can try and mitigate that a bit or at least provide a handle for the cinder-backend to return something here.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":62,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":63,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":64,"context_line":"  new connection has to be added or removed at the appropriate points."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"Proposed change"},{"line_number":67,"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":8,"id":"da6895a0_3b8ec878","line":64,"in_reply_to":"fa6399be_e4ae71e6","updated":"2016-10-23 08:03:05.000000000","message":"I would much prefer cinder just returns info for Nova to know what to do. Very little logic like that should be baked into os-brick.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":69,"context_line":"The main change between the new API flow and the old API flow is that the"},{"line_number":70,"context_line":"connection_info is now stored in Cinder, so Nova (and other clients) no"},{"line_number":71,"context_line":"longer need to store that information. This should also help with operations"},{"line_number":72,"context_line":"life force detach. Cinder is also more explicitly telling os-brick what it"},{"line_number":73,"context_line":"needs to do when connecting or disconnecting a volume."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"}],"source_content_type":"text/x-rst","patch_set":8,"id":"da6895a0_bbf818e7","line":72,"updated":"2016-10-23 08:03:05.000000000","message":"nit: s/life/like/","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":69,"context_line":"The main change between the new API flow and the old API flow is that the"},{"line_number":70,"context_line":"connection_info is now stored in Cinder, so Nova (and other clients) no"},{"line_number":71,"context_line":"longer need to store that information. This should also help with operations"},{"line_number":72,"context_line":"life force detach. Cinder is also more explicitly telling os-brick what it"},{"line_number":73,"context_line":"needs to do when connecting or disconnecting a volume."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"},{"line_number":76,"context_line":"calls. For now I will use the names I prefer."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_0febb5b1","line":73,"range":{"start_line":72,"start_character":19,"end_line":73,"end_character":54},"updated":"2016-10-17 16:40:21.000000000","message":"Same question as above.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":69,"context_line":"The main change between the new API flow and the old API flow is that the"},{"line_number":70,"context_line":"connection_info is now stored in Cinder, so Nova (and other clients) no"},{"line_number":71,"context_line":"longer need to store that information. This should also help with operations"},{"line_number":72,"context_line":"life force detach. Cinder is also more explicitly telling os-brick what it"},{"line_number":73,"context_line":"needs to do when connecting or disconnecting a volume."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"},{"line_number":76,"context_line":"calls. For now I will use the names I prefer."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_42801447","line":73,"range":{"start_line":72,"start_character":19,"end_line":73,"end_character":54},"in_reply_to":"fa6399be_0febb5b1","updated":"2016-10-17 22:43:14.000000000","message":"Not quite sure how Cinder tells Brick what to do in Nova\u0027s context, maybe you could elaborate on what you\u0027re thinking here?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":78,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":79,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":80,"context_line":"  plus it now stores the connection_info"},{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_effcc174","line":81,"range":{"start_line":81,"start_character":33,"end_line":81,"end_character":50},"updated":"2016-10-17 16:40:21.000000000","message":"Do you mean the os-attach cinder API? I think we call it attach_volume on the nova side.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":78,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":79,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":80,"context_line":"  plus it now stores the connection_info"},{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_22408007","line":81,"in_reply_to":"fa6399be_04dc7745","updated":"2016-10-17 22:43:14.000000000","message":"We initially proposed a simplified API from Cinder:\n* reserve\n* create_attachment\n\nand \n\n* unreserve\n* remove_attachment\n\nIt\u0027s been expressed that there\u0027s an interest in more granularity (essentially the same level and operational detail that we offer currently), so we\u0027ve now got:\n\n* reserve\n* connection_create\n* attachment_finalize\n\nand\n\n* unreserve\n* connection_terminate\n* attachment_remove\n\nThe main difference between this and the existing flow is that we no longer have the slew of optional parameters and Cinder stores the connector and everything after a \"connection_create\" is referenced via an attachment_id.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":78,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":79,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":80,"context_line":"  plus it now stores the connection_info"},{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_e4f831c7","line":81,"in_reply_to":"fa6399be_22408007","updated":"2016-10-18 17:56:58.000000000","message":"OK, but if we just microversioned os-initialize_connection to store the connector dict that nova passes to that API we\u0027d have the same thing, right? I\u0027m trying to measure options between completely overhauling the API workflow versus incremental changes on the existing API using microversions.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":78,"context_line":"* create_attachment is what was reserve_volume"},{"line_number":79,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":80,"context_line":"  plus it now stores the connection_info"},{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_04dc7745","line":81,"in_reply_to":"fa6399be_effcc174","updated":"2016-10-17 17:00:18.000000000","message":"The name changes are a bit messed up. Attach would just tell cinder is brick worked ok.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":79,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":80,"context_line":"  plus it now stores the connection_info"},{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_6ff19195","line":84,"range":{"start_line":82,"start_character":2,"end_line":84,"end_character":68},"updated":"2016-10-17 16:40:21.000000000","message":"Is this the \u0027is it safe to detach?\u0027 API?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_04c7e545","line":84,"in_reply_to":"fa6399be_471c8d77","updated":"2016-10-18 17:56:58.000000000","message":"Except for where we call the cinder API from to reserve the volume (but it in attaching state). nova-api does that before casting off to the compute to initialize the connection. In the new flow here nova-api would still call cinder to create an attachment and it would be in \u0027attaching\u0027 state, then on nova-compute nova would pass the connector dict (from brick) to cinder to update the attachment and cinder would store that connector, and return the connection_info dict that nova then uses to call brick and connect the volume, and then once that is done nova calls cinder again to \u0027ack the attach\u0027 and move the attachment from \u0027attaching\u0027 to \u0027attached\u0027 and put the volume \u0027in-use\u0027. Still sounds very similar to what we already have honestly except cinder doesn\u0027t store the connector or connection_info.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a4ed8bf1","line":84,"in_reply_to":"fa6399be_6ff19195","updated":"2016-10-17 17:00:18.000000000","message":"Yes","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c2d7c4eb","line":84,"in_reply_to":"fa6399be_a4ed8bf1","updated":"2016-10-17 22:43:14.000000000","message":"Ahh.. ok, I didn\u0027t condense the reserve and unreserve on the Cinder side, but I can certainly do that; I\u0027ll collapse them into connection_create and connection_terminate respectively.  This will put us back into a multiple staged state though, for example:\n    connection_terminate ---\u003e detaching\n    attachment_remove ---\u003e available","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":81,"context_line":"* confirm_attachment is what was create_attachment"},{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_471c8d77","line":84,"in_reply_to":"fa6399be_c2d7c4eb","updated":"2016-10-18 13:15:10.000000000","message":"yeah, I don\u0027t think we need the separate reserve and unreserve.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":82,"context_line":"* initialize_detachment is what was unreserve, but it now"},{"line_number":83,"context_line":"  returns info to tell os-brick if it needs to disconnect or not,"},{"line_number":84,"context_line":"  and if required passes back the correct connection_info to remove."},{"line_number":85,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":86,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4f3bed38","line":85,"range":{"start_line":85,"start_character":21,"end_line":85,"end_character":30},"updated":"2016-10-17 16:40:21.000000000","message":"terminate-connection","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid)"},{"line_number":91,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":92,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4f220d03","line":91,"updated":"2016-10-17 16:40:21.000000000","message":"nit: you probably want this to be a bulleted list to format properly.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid)"},{"line_number":91,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":92,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_bf673fe9","line":91,"in_reply_to":"fa6399be_100e71e5","updated":"2016-10-18 13:15:10.000000000","message":"So that was my intent. I think it was a bad intent.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid)"},{"line_number":91,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":92,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_100e71e5","line":91,"in_reply_to":"fa6399be_44cd8f85","updated":"2016-10-17 19:26:09.000000000","message":"So you want a big paragraph? Because that\u0027s how it renders:\n\nhttp://docs-draft.openstack.org/03/373203/8/check/gate-nova-specs-docs-ubuntu-xenial/1e66cbe//doc/build/html/specs/ocata/approved/cinder-new-attach-apis.html#proposed-change","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid)"},{"line_number":91,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":92,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_44cd8f85","line":91,"in_reply_to":"fa6399be_4f220d03","updated":"2016-10-17 17:00:18.000000000","message":"I was going for a definition list","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":88,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments (server_uuid)"},{"line_number":91,"context_line":"  Returns an attachment_uuid, and stores the attachment details."},{"line_number":92,"context_line":"  Nova calls this in the API to reserve the volume for the specified"},{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_24c4e93e","line":91,"in_reply_to":"fa6399be_bf673fe9","updated":"2016-10-18 17:56:58.000000000","message":"Some ladies like a bad boy John. Just say that\u0027s what you were going for.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"},{"line_number":95,"context_line":"  or the existing attachments are in the Attached state."},{"line_number":96,"context_line":"  You are only allowed attachments to two different server_uuids if"},{"line_number":97,"context_line":"  the volume has multi-attach\u003dTrue."},{"line_number":98,"context_line":"  The new attachment will be in the RESERVED state."},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_2f53196e","line":96,"range":{"start_line":96,"start_character":38,"end_line":96,"end_character":41},"updated":"2016-10-17 16:40:21.000000000","message":"Why is this restricted to two? Is that how multi-attach works today on the Cinder side?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"},{"line_number":95,"context_line":"  or the existing attachments are in the Attached state."},{"line_number":96,"context_line":"  You are only allowed attachments to two different server_uuids if"},{"line_number":97,"context_line":"  the volume has multi-attach\u003dTrue."},{"line_number":98,"context_line":"  The new attachment will be in the RESERVED state."},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"da6895a0_bbcf38af","line":96,"in_reply_to":"fa6399be_24eb3bb2","updated":"2016-10-23 08:03:05.000000000","message":"We should allow for more than two. For Oracle RAC (the main/best use case I\u0027ve been given for multiattach) it\u0027s very likely the consumer of this will want several instances.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  server_uuid."},{"line_number":94,"context_line":"  You can only create a new attachment if there are no other attachments,"},{"line_number":95,"context_line":"  or the existing attachments are in the Attached state."},{"line_number":96,"context_line":"  You are only allowed attachments to two different server_uuids if"},{"line_number":97,"context_line":"  the volume has multi-attach\u003dTrue."},{"line_number":98,"context_line":"  The new attachment will be in the RESERVED state."},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_24eb3bb2","line":96,"in_reply_to":"fa6399be_2f53196e","updated":"2016-10-17 17:00:18.000000000","message":"Today we only allow one, via reserve calls failing, I guess. Maybe it\u0027s different. The evacuate stuff complicates things, but we only need two active ones, so seems good not to loose track and make volumes fail to delete later on?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  This binds the attachment to the specific host_uuid."},{"line_number":103,"context_line":"  For each volume_uuid, you are only allowed one attachment per"},{"line_number":104,"context_line":"  server_uuid and host_uuid pair."},{"line_number":105,"context_line":"  You are also only allowed a maximum of two host_uuids associated"},{"line_number":106,"context_line":"  per server_uuid. You should only get two attachments per server_uuid"},{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_0fec958e","line":105,"range":{"start_line":105,"start_character":2,"end_line":105,"end_character":66},"updated":"2016-10-17 16:40:21.000000000","message":"Similar question to above. I\u0027m assuming we\u0027re just sticking to two because of migration, but I wouldn\u0027t be surprised if there was some crazy use case out there that needed/wanted more than 2 attachments per volume at once.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  This binds the attachment to the specific host_uuid."},{"line_number":103,"context_line":"  For each volume_uuid, you are only allowed one attachment per"},{"line_number":104,"context_line":"  server_uuid and host_uuid pair."},{"line_number":105,"context_line":"  You are also only allowed a maximum of two host_uuids associated"},{"line_number":106,"context_line":"  per server_uuid. You should only get two attachments per server_uuid"},{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a4ee6bb2","line":105,"in_reply_to":"fa6399be_0fec958e","updated":"2016-10-17 17:00:18.000000000","message":"Maybe...","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  You are also only allowed a maximum of two host_uuids associated"},{"line_number":106,"context_line":"  per server_uuid. You should only get two attachments per server_uuid"},{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."},{"line_number":109,"context_line":"  This API returns the updated attachment document that includes the"},{"line_number":110,"context_line":"  host_connect_info that is sent to os-brick to connect the volume to"},{"line_number":111,"context_line":"  the hypervisor."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_cf98dd1e","line":108,"range":{"start_line":108,"start_character":17,"end_line":108,"end_character":43},"updated":"2016-10-17 16:40:21.000000000","message":"This is confusing to me. Wouldn\u0027t we cleanup an attachment when the first spawn failed?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  You are also only allowed a maximum of two host_uuids associated"},{"line_number":106,"context_line":"  per server_uuid. You should only get two attachments per server_uuid"},{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."},{"line_number":109,"context_line":"  This API returns the updated attachment document that includes the"},{"line_number":110,"context_line":"  host_connect_info that is sent to os-brick to connect the volume to"},{"line_number":111,"context_line":"  the hypervisor."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_0482b7c8","line":108,"in_reply_to":"fa6399be_cf98dd1e","updated":"2016-10-17 17:00:18.000000000","message":"There is an overlap, you want to reserve vol for new host, then delete old one, so there are no races","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."},{"line_number":109,"context_line":"  This API returns the updated attachment document that includes the"},{"line_number":110,"context_line":"  host_connect_info that is sent to os-brick to connect the volume to"},{"line_number":111,"context_line":"  the hypervisor."},{"line_number":112,"context_line":"  In the case where that could be a shared connection, Cinder is responsible"},{"line_number":113,"context_line":"  for only telling os-brick to make the one connection for each host to that"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_afbac96f","line":110,"range":{"start_line":110,"start_character":2,"end_line":110,"end_character":19},"updated":"2016-10-17 16:40:21.000000000","message":"This is our connection_info that we use today?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  if you are moving the server between two hosts, such as during"},{"line_number":108,"context_line":"  live-migration or a second spawn attempt."},{"line_number":109,"context_line":"  This API returns the updated attachment document that includes the"},{"line_number":110,"context_line":"  host_connect_info that is sent to os-brick to connect the volume to"},{"line_number":111,"context_line":"  the hypervisor."},{"line_number":112,"context_line":"  In the case where that could be a shared connection, Cinder is responsible"},{"line_number":113,"context_line":"  for only telling os-brick to make the one connection for each host to that"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4453cf6c","line":110,"in_reply_to":"fa6399be_afbac96f","updated":"2016-10-17 17:00:18.000000000","message":"Yes, but it more directly goes to brick","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":112,"context_line":"  In the case where that could be a shared connection, Cinder is responsible"},{"line_number":113,"context_line":"  for only telling os-brick to make the one connection for each host to that"},{"line_number":114,"context_line":"  particular volume backend."},{"line_number":115,"context_line":"  This detail should be transparent to Nova, os-brick is still called,"},{"line_number":116,"context_line":"  just the payload may tell os-brick that nothing needs to be done, expect"},{"line_number":117,"context_line":"  maybe check for the presence of an exiting connection."},{"line_number":118,"context_line":"  Note, in the case of ironic only volume attach, its possible the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"da6895a0_fbc1b081","line":115,"updated":"2016-10-23 08:03:05.000000000","message":"I think this changes now based on the comments at the beginning?\n\nAh, I see that\u0027s kind of addressed below.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":112,"context_line":"  In the case where that could be a shared connection, Cinder is responsible"},{"line_number":113,"context_line":"  for only telling os-brick to make the one connection for each host to that"},{"line_number":114,"context_line":"  particular volume backend."},{"line_number":115,"context_line":"  This detail should be transparent to Nova, os-brick is still called,"},{"line_number":116,"context_line":"  just the payload may tell os-brick that nothing needs to be done, expect"},{"line_number":117,"context_line":"  maybe check for the presence of an exiting connection."},{"line_number":118,"context_line":"  Note, in the case of ironic only volume attach, its possible the"},{"line_number":119,"context_line":"  instance_uuid and host_uuid are the same logical uuid, but that should"},{"line_number":120,"context_line":"  not worry Nova."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_8f542522","line":117,"range":{"start_line":115,"start_character":2,"end_line":117,"end_character":56},"updated":"2016-10-17 16:40:21.000000000","message":"So nova is going to call cinder to initialize the attachment, cinder gives nova back a connection_info dict, and then nova is going to pass that to os-brick\u0027s connect_volume method now which will know how to parse that data? That\u0027s all new stuff in os-brick right?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  particular volume backend."},{"line_number":115,"context_line":"  This detail should be transparent to Nova, os-brick is still called,"},{"line_number":116,"context_line":"  just the payload may tell os-brick that nothing needs to be done, expect"},{"line_number":117,"context_line":"  maybe check for the presence of an exiting connection."},{"line_number":118,"context_line":"  Note, in the case of ironic only volume attach, its possible the"},{"line_number":119,"context_line":"  instance_uuid and host_uuid are the same logical uuid, but that should"},{"line_number":120,"context_line":"  not worry Nova."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_44010f39","line":117,"in_reply_to":"fa6399be_8f542522","updated":"2016-10-17 17:00:18.000000000","message":"Yes, its os brick work. Idea is cinder controls both sides.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  {\"confirm_attachment\": null}"},{"line_number":124,"context_line":"  This is called once the os-brick host attach has completed."},{"line_number":125,"context_line":"  The attachment gets moved into the ATTACHED state."},{"line_number":126,"context_line":"  This call exists because we some driver have volumes share attachments"},{"line_number":127,"context_line":"  Note: if the os-brick called failed, Nova deletes the attachment."},{"line_number":128,"context_line":"  At this point, if there is a shared connection, Cinder knows it can be"},{"line_number":129,"context_line":"  used by other volumes that get attached on that host."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_41402136","line":126,"range":{"start_line":126,"start_character":27,"end_line":126,"end_character":41},"updated":"2016-10-17 16:40:21.000000000","message":"This call exists because some cinder drivers have volumes share attachments.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddc90c85a3e66b11320133698c646b67504895c1","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  from the hypervisor. Cinder is responsible to make sure no one"},{"line_number":136,"context_line":"  else is going to use that host connection, if it is being removed."},{"line_number":137,"context_line":"  This puts the attachment into the DETACHING state."},{"line_number":138,"context_line":"  Note, Cinder should only allow one volume to into either Detaching"},{"line_number":139,"context_line":"  or Attaching when there is a shared connection that os-brick could"},{"line_number":140,"context_line":"  be being told to remove at this point."},{"line_number":141,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_21a96de0","line":138,"range":{"start_line":138,"start_character":44,"end_line":138,"end_character":46},"updated":"2016-10-17 16:40:21.000000000","message":"to enter into?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"16f8c8e51167254af37a17c6df92bbd79a2a4936","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  from the hypervisor. Cinder is responsible to make sure no one"},{"line_number":136,"context_line":"  else is going to use that host connection, if it is being removed."},{"line_number":137,"context_line":"  This puts the attachment into the DETACHING state."},{"line_number":138,"context_line":"  Note, Cinder should only allow one volume to into either Detaching"},{"line_number":139,"context_line":"  or Attaching when there is a shared connection that os-brick could"},{"line_number":140,"context_line":"  be being told to remove at this point."},{"line_number":141,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_e4bf835e","line":138,"in_reply_to":"fa6399be_21a96de0","updated":"2016-10-17 17:00:18.000000000","message":"Yeah","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  still in the ATTACHING state."},{"line_number":147,"context_line":"  Note: if in the ATTACHED state, you must first call initialize_detachment."},{"line_number":148,"context_line":"  TODO - what happens of os_brick fails at this point?? Should we put the"},{"line_number":149,"context_line":"  volume into some kind of error state, or we just delete it anyway?"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments"},{"line_number":152,"context_line":"  Lists all the active attachments for the given volume, created_at,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"da6895a0_3bbc0805","line":149,"updated":"2016-10-23 08:03:05.000000000","message":"We probably need to put it in an error state. On the backend we could still delete the volume. But if the host has seen the volume and we just yank it out from underneath it could potentially cause server stability problems.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"a38ccce845a8926931f7cf79d23829531972d91e","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  still in the ATTACHING state."},{"line_number":147,"context_line":"  Note: if in the ATTACHED state, you must first call initialize_detachment."},{"line_number":148,"context_line":"  TODO - what happens of os_brick fails at this point?? Should we put the"},{"line_number":149,"context_line":"  volume into some kind of error state, or we just delete it anyway?"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments"},{"line_number":152,"context_line":"  Lists all the active attachments for the given volume, created_at,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a629dbe_d1cf71ae","line":149,"in_reply_to":"da6895a0_3bbc0805","updated":"2016-11-08 10:29:50.000000000","message":"Yeah, I was thinking the same thing. I am wondering if we do something similar for evacuate actually.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":153,"context_line":"  updated_at, the associated server_uuid and host_uuid, and its current state:"},{"line_number":154,"context_line":"  RESERVED, ATTACHING, ATTACHED, DETACHING."},{"line_number":155,"context_line":"  Note: deleted attachments are not shown."},{"line_number":156,"context_line":"  Note: the volume state (in-use vs attaching) can be inferred form the"},{"line_number":157,"context_line":"  attachment state. Any ATTACHED, and it is in-use."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments/\u003cattachment_uuid\u003e"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_90ac418e","line":156,"range":{"start_line":156,"start_character":63,"end_line":156,"end_character":67},"updated":"2016-10-17 19:26:09.000000000","message":"from","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"2d131864fd5253db763a05d7597bf96e9dc17dfc","unresolved":false,"context_lines":[{"line_number":180,"context_line":"either the existing Cinder interaction model, or the new interaction model."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"In two cycles time, the old interaction model should be removed. We should"},{"line_number":183,"context_line":"keep this in mind in how the code is structured. It should be possible to"},{"line_number":184,"context_line":"ensure this complexity is dealt with behind the volume api. It is likely we"},{"line_number":185,"context_line":"have two implementations for the volume API that are chosen depending on the"},{"line_number":186,"context_line":"cached API microversion."}],"source_content_type":"text/x-rst","patch_set":8,"id":"da6895a0_5b37fcaf","line":183,"updated":"2016-10-23 08:03:05.000000000","message":"+1","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":187,"context_line":"Note this will mean a hard dependency between Nova and having a version of"},{"line_number":188,"context_line":"Cinder installed that supports this new flow."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":191,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":192,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":193,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4b011a39","line":190,"range":{"start_line":190,"start_character":0,"end_line":190,"end_character":4},"updated":"2016-10-17 19:26:09.000000000","message":"There","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":189,"context_line":""},{"line_number":190,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":191,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":192,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":193,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":194,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":195,"context_line":"the Ocata timeframe, so we release with the new workflow on by default."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_0b9e4207","line":192,"range":{"start_line":192,"start_character":14,"end_line":192,"end_character":47},"updated":"2016-10-17 19:26:09.000000000","message":"Actually glance v2 isn\u0027t a great example here as we turned on glance v2 by default and immediately deprecated the option to use glance v1.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":190,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":191,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":192,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":193,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":194,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":195,"context_line":"the Ocata timeframe, so we release with the new workflow on by default."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"When upgrading, no servers will use the new flow until all api and compute"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_8b9252f5","line":194,"range":{"start_line":193,"start_character":58,"end_line":194,"end_character":44},"updated":"2016-10-17 19:26:09.000000000","message":"ok now it makes more sense re: glance v2","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":198,"context_line":"nodes are upgrade. We can check this by inspecting the min service version."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Once all nodes are upgraded, all new volume attachments will exclusively"},{"line_number":201,"context_line":"use the new flow. The BDM record will be updated to include the attachment"},{"line_number":202,"context_line":"id for each attachment, which will be used to know that that BDM is using"},{"line_number":203,"context_line":"the new flow."},{"line_number":204,"context_line":"For operations currently in flight, they should complete all operations using"},{"line_number":205,"context_line":"the version of the flow specified in the BDM."},{"line_number":206,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c648bf8d","line":203,"range":{"start_line":201,"start_character":18,"end_line":203,"end_character":13},"updated":"2016-10-17 19:26:09.000000000","message":"Hmm, do we want to store the attachment_id in the BDM table? I thought part of the reason for tracking the volume/server/host information in Cinder was so that Cinder is the source of truth and if nova needs to get an attachment for a given volume/server/host we can just query the cinder attachments API for the given volume and then filter by server/host to find what we need. I know that having the BDM.attachment_id in nova would be convenient, but it\u0027s more state tracking duplication that we\u0027re trying to avoid.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":198,"context_line":"nodes are upgrade. We can check this by inspecting the min service version."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Once all nodes are upgraded, all new volume attachments will exclusively"},{"line_number":201,"context_line":"use the new flow. The BDM record will be updated to include the attachment"},{"line_number":202,"context_line":"id for each attachment, which will be used to know that that BDM is using"},{"line_number":203,"context_line":"the new flow."},{"line_number":204,"context_line":"For operations currently in flight, they should complete all operations using"},{"line_number":205,"context_line":"the version of the flow specified in the BDM."},{"line_number":206,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4a8e5f28","line":203,"range":{"start_line":201,"start_character":18,"end_line":203,"end_character":13},"in_reply_to":"fa6399be_c648bf8d","updated":"2016-10-18 13:15:10.000000000","message":"Thats fair. It was more a marker that we are using the new flow, and because its convenient. Should always be able to look it up, if we wanted to, as you say.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":208,"context_line":"attachments over to the new flow. This involves telling Cinder about the"},{"line_number":209,"context_line":"connection info that is stored in the BDM, so Cinder now has this info, and"},{"line_number":210,"context_line":"create the attachment id in the Cinder database. This will be a nova-manage"},{"line_number":211,"context_line":"cmd that sends the info to an upgraded cinder-manager cmd. The returned"},{"line_number":212,"context_line":"attachment id is put into the BDM to tell Nova that all future operations"},{"line_number":213,"context_line":"(like detach) should now use the new flow. Cinder is responsible for ensuring"},{"line_number":214,"context_line":"you can still use the old flow when the new flow has been activated, so there"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_2b3f86d7","line":211,"range":{"start_line":211,"start_character":39,"end_line":211,"end_character":53},"updated":"2016-10-17 19:26:09.000000000","message":"cinder-manage?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":208,"context_line":"attachments over to the new flow. This involves telling Cinder about the"},{"line_number":209,"context_line":"connection info that is stored in the BDM, so Cinder now has this info, and"},{"line_number":210,"context_line":"create the attachment id in the Cinder database. This will be a nova-manage"},{"line_number":211,"context_line":"cmd that sends the info to an upgraded cinder-manager cmd. The returned"},{"line_number":212,"context_line":"attachment id is put into the BDM to tell Nova that all future operations"},{"line_number":213,"context_line":"(like detach) should now use the new flow. Cinder is responsible for ensuring"},{"line_number":214,"context_line":"you can still use the old flow when the new flow has been activated, so there"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4ab57fce","line":211,"range":{"start_line":211,"start_character":39,"end_line":211,"end_character":53},"in_reply_to":"fa6399be_2b3f86d7","updated":"2016-10-18 13:15:10.000000000","message":"oops, yes.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":214,"context_line":"you can still use the old flow when the new flow has been activated, so there"},{"line_number":215,"context_line":"are no races in moving to the new flow."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"TODO - probably missing some details here."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Spawn and Delete"},{"line_number":220,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_06a47706","line":217,"updated":"2016-10-17 19:26:09.000000000","message":"So basically we have an online data migration that runs in chunks on the BDMs that don\u0027t have an attachment_id field set. For those BDMs, we create or update volume attachments for the given volume/instance/instance.host and store the BDM.connection_info in the attachment connection_info? Do we need the connector at all? We get the volume connector dict from the virt driver (os-brick for libvirt), then pass that to os-initialize_connection and os-terminate_connection APIs today. If we need the connector from a nova-manage command we\u0027re probably in trouble, as that would require a call to the compute rpcapi.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":214,"context_line":"you can still use the old flow when the new flow has been activated, so there"},{"line_number":215,"context_line":"are no races in moving to the new flow."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"TODO - probably missing some details here."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"Spawn and Delete"},{"line_number":220,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_6a088392","line":217,"in_reply_to":"fa6399be_06a47706","updated":"2016-10-18 13:15:10.000000000","message":"Hmm, thats a very good question. I don\u0027t know.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":219,"context_line":"Spawn and Delete"},{"line_number":220,"context_line":"----------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"Consider boot server_uuid\u003ds1 on host_uuid\u003dh1"},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":225,"context_line":"* save attachment_uuid in BDM"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_861fa7b6","line":222,"updated":"2016-10-17 19:26:09.000000000","message":"Is this boot from volume with a provided volume, or BFV in the case that source_type\u003dblank/image/snapshot and nova creates the volume? Maybe it doesn\u0027t matter for the flow below.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":219,"context_line":"Spawn and Delete"},{"line_number":220,"context_line":"----------------"},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"Consider boot server_uuid\u003ds1 on host_uuid\u003dh1"},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":225,"context_line":"* save attachment_uuid in BDM"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_aa029b6d","line":222,"in_reply_to":"fa6399be_861fa7b6","updated":"2016-10-18 13:15:10.000000000","message":"Right, any of those. I should make that explicit.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c68d1f2c","line":234,"range":{"start_line":234,"start_character":30,"end_line":234,"end_character":57},"updated":"2016-10-17 19:26:09.000000000","message":"Yup:\n\nhttps://github.com/openstack/nova/blob/14.0.1/nova/virt/libvirt/driver.py#L923","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_64626118","line":234,"range":{"start_line":234,"start_character":30,"end_line":234,"end_character":57},"in_reply_to":"fa6399be_8a6cf709","updated":"2016-10-18 17:56:58.000000000","message":"Yes the above call calls brick to disconnect the volume from the host. The part where the compute manager \"detaches\" the volume from the instance comes after that.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_8a6cf709","line":234,"range":{"start_line":234,"start_character":30,"end_line":234,"end_character":57},"in_reply_to":"fa6399be_c68d1f2c","updated":"2016-10-18 13:15:10.000000000","message":"Thats not what I mean here, I should be way more precise.\n\nI mean disconnects the volume from the VM. It is still connecting to the host.  Thats what the above call is doing, as I understand it.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_26b41bd0","line":235,"updated":"2016-10-17 19:26:09.000000000","message":"So this would be similar to where we call terminate_connection today:\n\nhttps://github.com/openstack/nova/blob/14.0.1/nova/compute/manager.py#L2219\n\nAnd then we\u0027d add a new call back into the virt driver to process that host_detach_info? But we already called os-brick when we called driver.destroy() above:\n\nhttps://github.com/openstack/nova/blob/14.0.1/nova/virt/libvirt/driver.py#L923\n\nKeep in mind that not all virt drivers are using os-brick...so I guess you have a 2-phase call to brick to detach? Or is this confused?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_aa161b53","line":235,"in_reply_to":"fa6399be_26b41bd0","updated":"2016-10-18 13:15:10.000000000","message":"What I was thinking is a bit like this:\n\n  # ensure VM is now turned off, and destroyed  \n  (for bdm in ....)\n    os_brick_detach_info \u003d initialise_detachment(attachment_id)\n    try:\n      driver.detach_volume_from_host(os_brick_detach_info)\n    except Exception e:\n      mark_attachment_with_error(e)\n    else:\n      delete_attachment(attachment_id)\n\ni.e. only call os-brick after the can_attach call, and if it works, delete the attachment.\n\nBut maybe thats not possible, looks like we have to do a step before we destroy the VM. Although I assume that bit is nothing to do with the host, its VM specific, so that probably stays? I am unsure.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_045b6555","line":235,"in_reply_to":"fa6399be_aa161b53","updated":"2016-10-18 17:56:58.000000000","message":"I\u0027m assuming you mean can_detach call?\n\nAnd yeah, the flow above is a bit odd because today we destroy the VM on the host (and disconnect the volume as part of that), and then detach the volume from the instance in the database (by calling cinder os-detach). So calling driver.detach_volume_from_host after we\u0027ve already disconnected the volume from the host seems redundant and not useful.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Interesting edge cases:"},{"line_number":240,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_46c90f5a","line":237,"range":{"start_line":237,"start_character":2,"end_line":237,"end_character":36},"updated":"2016-10-17 19:26:09.000000000","message":"And this replaces:\n\nhttps://github.com/openstack/nova/blob/14.0.1/nova/compute/manager.py#L2222","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":234,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":235,"context_line":"* host_detach_info \u003d initialize_detachment(attachment_uuid)"},{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Interesting edge cases:"},{"line_number":240,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a5b80ce7","line":237,"range":{"start_line":237,"start_character":2,"end_line":237,"end_character":36},"in_reply_to":"fa6399be_46c90f5a","updated":"2016-10-18 13:15:10.000000000","message":"yeah.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Interesting edge cases:"},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"* should we fail to boot, after having attached the volume to the host,"},{"line_number":242,"context_line":"  and need to retry the boot on a new host, this counts as a move."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c6299ff4","line":239,"updated":"2016-10-17 19:26:09.000000000","message":"Another interesting edge case is local delete in the nova-api service - that\u0027s the case that the compute service that the instance was running on is down, so we cleanup the volumes from the API:\n\nhttps://github.com/openstack/nova/blob/14.0.1/nova/compute/api.py#L1915\n\nWe\u0027ll have to account for that with the new flow too.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":236,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":237,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Interesting edge cases:"},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"* should we fail to boot, after having attached the volume to the host,"},{"line_number":242,"context_line":"  and need to retry the boot on a new host, this counts as a move."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_858148fe","line":239,"in_reply_to":"fa6399be_c6299ff4","updated":"2016-10-18 13:15:10.000000000","message":"Totally forgot that one. Yuck...\n\nI am tempted to make that a similar flow to evacuate, except that would stop us ever being able to delete the volume. You would have a pending attachment that the nova-compute node could spot when it starts back up.\n\nThats messy...","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  for the existing host attachment."},{"line_number":245,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":246,"context_line":"  correctly cleaned up, but only when required."},{"line_number":247,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":248,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Attach and Detach volume"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_02be1cd4","line":247,"range":{"start_line":247,"start_character":0,"end_line":247,"end_character":77},"updated":"2016-10-17 22:43:14.000000000","message":"yes, we should use attachment_id\u0027s for successive calls to Cinder to act on an attachment rather than the volume.  My current work has an attachment resource that is used for everything AFTER the connection_intialize, one extra volume related call is a remove_all_attachments by specified volume-id.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":245,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":246,"context_line":"  correctly cleaned up, but only when required."},{"line_number":247,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":248,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Attach and Detach volume"},{"line_number":251,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a6d74bec","line":248,"range":{"start_line":248,"start_character":65,"end_line":248,"end_character":77},"updated":"2016-10-17 19:26:09.000000000","message":"I\u0027d say no because if it\u0027s a multi-attach volume you can\u0027t delete it if it has other attachments (or just at all if bdm.delete_on_termination is False).","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":245,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":246,"context_line":"  correctly cleaned up, but only when required."},{"line_number":247,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":248,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Attach and Detach volume"},{"line_number":251,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_2a55ab1c","line":248,"range":{"start_line":248,"start_character":70,"end_line":248,"end_character":76},"updated":"2016-10-18 13:15:10.000000000","message":"Yeah sorry, I mean delete attachment, not delete volume.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":245,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":246,"context_line":"  correctly cleaned up, but only when required."},{"line_number":247,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)?"},{"line_number":248,"context_line":"* should the call to os-brick to detach fail, what should we do? call delete?"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Attach and Detach volume"},{"line_number":251,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_02a53cb4","line":248,"range":{"start_line":248,"start_character":65,"end_line":248,"end_character":77},"in_reply_to":"fa6399be_a6d74bec","updated":"2016-10-17 22:43:14.000000000","message":"You can delete the attachment record on the Cinder side; we\u0027ll create a unique attachment record for any connection, including shared connections.  This is particularly important going forward when it comes to multi-attach and other things.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Consider attach with server_uuid\u003ds1 on host_uuid\u003dh1"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":256,"context_line":"* save attachment_uuid in BDM"},{"line_number":257,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid, host_uuid\u003dh1)"},{"line_number":258,"context_line":"* talk to os-brick to do what is needed on the host"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_466caf36","line":255,"range":{"start_line":255,"start_character":20,"end_line":255,"end_character":41},"updated":"2016-10-17 19:26:09.000000000","message":"Might be helpful to have a volume_uuid\u003dv1 variable in these examples since you\u0027d create the attachment for a given volume and server.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Consider attach with server_uuid\u003ds1 on host_uuid\u003dh1"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":256,"context_line":"* save attachment_uuid in BDM"},{"line_number":257,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid, host_uuid\u003dh1)"},{"line_number":258,"context_line":"* talk to os-brick to do what is needed on the host"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_6a35e3f5","line":255,"range":{"start_line":255,"start_character":20,"end_line":255,"end_character":41},"in_reply_to":"fa6399be_466caf36","updated":"2016-10-18 13:15:10.000000000","message":"yeah, I was being lazy.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":265,"context_line":"* First attempt to hot unplug the volume from the VM"},{"line_number":266,"context_line":"* If this fails, we should fail the operation."},{"line_number":267,"context_line":"* Once completed, we call initialize_detachment(attachment_uuid)"},{"line_number":268,"context_line":"* call os-brick to possible do the attach"},{"line_number":269,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":270,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":271,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a64aebaa","line":268,"range":{"start_line":268,"start_character":2,"end_line":268,"end_character":41},"updated":"2016-10-17 19:26:09.000000000","message":"wording?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":265,"context_line":"* First attempt to hot unplug the volume from the VM"},{"line_number":266,"context_line":"* If this fails, we should fail the operation."},{"line_number":267,"context_line":"* Once completed, we call initialize_detachment(attachment_uuid)"},{"line_number":268,"context_line":"* call os-brick to possible do the attach"},{"line_number":269,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":270,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":271,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4a173f54","line":268,"range":{"start_line":268,"start_character":2,"end_line":268,"end_character":41},"in_reply_to":"fa6399be_a64aebaa","updated":"2016-10-18 13:15:10.000000000","message":"I mean possibly, i.e. the attach may not always be needed when its a shared volume.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":266,"context_line":"* If this fails, we should fail the operation."},{"line_number":267,"context_line":"* Once completed, we call initialize_detachment(attachment_uuid)"},{"line_number":268,"context_line":"* call os-brick to possible do the attach"},{"line_number":269,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":270,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Note: there is no different with boot in terms of API calls to Cinder."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_26d5fbb8","line":269,"range":{"start_line":269,"start_character":2,"end_line":269,"end_character":51},"updated":"2016-10-17 19:26:09.000000000","message":"Similar to my questions about the 2-phase detach above.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":278,"context_line":"(Source is h1 and destination is h2):"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":281,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":282,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid, h2)"},{"line_number":283,"context_line":"* talk to os-brick to do what is needed on the host"},{"line_number":284,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_26a33b51","line":281,"updated":"2016-10-17 19:26:09.000000000","message":"Will the BDM have source and target attachment fields? If the server is already attached to h1 using the new flow, doesn\u0027t the BDM already have an attachment_id set for h1? Does that swap to be the attachment_id for h2 during the migration and if so, couldn\u0027t we lose our place with the h1 attachment for detach or rollback?","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":278,"context_line":"(Source is h1 and destination is h2):"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":281,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":282,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid, h2)"},{"line_number":283,"context_line":"* talk to os-brick to do what is needed on the host"},{"line_number":284,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_858228c7","line":281,"in_reply_to":"fa6399be_26a33b51","updated":"2016-10-18 13:15:10.000000000","message":"So I was getting too cleaver here.\n\nMaybe we should do this like flavor on an instance, we could have attachment_id, source_attachment_id and destination_attachment_id. When we are done, only the attachment-id would be set.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":278,"context_line":"(Source is h1 and destination is h2):"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"* attachment_uuid \u003d create_attachment(s1)"},{"line_number":281,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":282,"context_line":"* host_connect_info \u003d initialize_attachment(attachment_uuid, h2)"},{"line_number":283,"context_line":"* talk to os-brick to do what is needed on the host"},{"line_number":284,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_3f5236de","line":281,"in_reply_to":"fa6399be_858228c7","updated":"2016-10-18 17:56:58.000000000","message":"We could, except I still prefer Cinder managing the attachment records. Nova can tell which is the source and which is the destination attachment based on the host stored in the attachment.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":288,"context_line":""},{"line_number":289,"context_line":"During post-live-migration on source host, we:"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"* host_detach_info \u003d initialize_detachment(old_attachment_uuid)"},{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_06b5577d","line":291,"range":{"start_line":291,"start_character":43,"end_line":291,"end_character":62},"updated":"2016-10-17 19:26:09.000000000","message":"Per my question above, where is this stored? I guess Cinder might have it given since is storing the attachments for the given volume, and should have the server and host information in the attachment before we started the migration, so we could look it up from the cinder API if needed.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":288,"context_line":""},{"line_number":289,"context_line":"During post-live-migration on source host, we:"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"* host_detach_info \u003d initialize_detachment(old_attachment_uuid)"},{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_90c988af","line":291,"range":{"start_line":291,"start_character":43,"end_line":291,"end_character":62},"in_reply_to":"fa6399be_06b5577d","updated":"2016-10-18 13:15:10.000000000","message":"We can look it up from the Cinder API at any time, but it seems good to store that in the BDM too.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":288,"context_line":""},{"line_number":289,"context_line":"During post-live-migration on source host, we:"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"* host_detach_info \u003d initialize_detachment(old_attachment_uuid)"},{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_9f57c2c9","line":291,"range":{"start_line":291,"start_character":43,"end_line":291,"end_character":62},"in_reply_to":"fa6399be_90c988af","updated":"2016-10-18 17:56:58.000000000","message":"Same as above, I don\u0027t think we want Nova doing this state tracking at all in case we get out of sync.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"We are now back to having just the one attachment, the new attachment on the"},{"line_number":296,"context_line":"destination host."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Note how the BDM stores an attachment id for the source and destination host"},{"line_number":299,"context_line":"while the live-migration is in process."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c616ff57","line":296,"range":{"start_line":295,"start_character":0,"end_line":296,"end_character":17},"updated":"2016-10-17 19:26:09.000000000","message":"This furthers my point that I don\u0027t think the nova BDM table should store the attachment_id, we can get that information from Cinder if/when needed. If the BDM.attachment_id was used to signal when we use the \u0027new flow\u0027 I\u0027d think we can also do that using the same checks that will go into the API layer and are cached, i.e. the minimum compute service version and the volume API microversion check. Basically, set a global that says if we can do this new flow.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"We are now back to having just the one attachment, the new attachment on the"},{"line_number":296,"context_line":"destination host."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Note how the BDM stores an attachment id for the source and destination host"},{"line_number":299,"context_line":"while the live-migration is in process."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_3feeb6ec","line":296,"range":{"start_line":295,"start_character":0,"end_line":296,"end_character":17},"in_reply_to":"fa6399be_b05cccee","updated":"2016-10-18 17:56:58.000000000","message":"Well, it seems the window that someone gets caught up in a sighup during an attach would be small and the worst that would happen is the attach fails because we don\u0027t pass the attachment ID to cinder\u0027s new APIs.\n\nThe sticky part would be the detach, i.e. we attached with the old flow, and we\u0027re detaching we have the new APIs available. But in that case I\u0027d think if we don\u0027t find the attachment on the cinder side (whatever the new API GET call is), then we assume the attachment is from the old flow and we handle appropriately.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":292,"context_line":"* call to os-brick to do what is needed on the host"},{"line_number":293,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"We are now back to having just the one attachment, the new attachment on the"},{"line_number":296,"context_line":"destination host."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Note how the BDM stores an attachment id for the source and destination host"},{"line_number":299,"context_line":"while the live-migration is in process."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_b05cccee","line":296,"range":{"start_line":295,"start_character":0,"end_line":296,"end_character":17},"in_reply_to":"fa6399be_c616ff57","updated":"2016-10-18 13:15:10.000000000","message":"We have to do the new flow per BDM, but we could do that with a boolean.\n\nIt has to be per flow, so we don\u0027t switch version mid flow, and get properly confused.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":314,"context_line":"* Add a new attachment for the new host"},{"line_number":315,"context_line":"* Put the attachment on the old host should be put into a disconnecting state"},{"line_number":316,"context_line":"* If the old compute node starts up, it detects attachments in the"},{"line_number":317,"context_line":"  disconnecting state, and completes the disconnection"},{"line_number":318,"context_line":"* Should the node never be brought back up, the admin can do a force detach"},{"line_number":319,"context_line":"  on all relevant volume attachments"},{"line_number":320,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_28086928","line":317,"range":{"start_line":317,"start_character":2,"end_line":317,"end_character":15},"updated":"2016-10-17 19:26:09.000000000","message":"DETACHING state? Should be consistent with the attachments states defined earlier in this spec.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":314,"context_line":"* Add a new attachment for the new host"},{"line_number":315,"context_line":"* Put the attachment on the old host should be put into a disconnecting state"},{"line_number":316,"context_line":"* If the old compute node starts up, it detects attachments in the"},{"line_number":317,"context_line":"  disconnecting state, and completes the disconnection"},{"line_number":318,"context_line":"* Should the node never be brought back up, the admin can do a force detach"},{"line_number":319,"context_line":"  on all relevant volume attachments"},{"line_number":320,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_106c989b","line":317,"range":{"start_line":317,"start_character":2,"end_line":317,"end_character":15},"in_reply_to":"fa6399be_28086928","updated":"2016-10-18 13:15:10.000000000","message":"oops, yes.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":323,"context_line":""},{"line_number":324,"context_line":"TODO"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"* When shelving, add a new attachment, with no host set, in the RESERVED state"},{"line_number":327,"context_line":"* When offloading, do a regular detach of the existing attachment"},{"line_number":328,"context_line":"* Note: BDM needs to store both attachment-uuids"},{"line_number":329,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_4824bdae","line":326,"updated":"2016-10-17 19:26:09.000000000","message":"Is this flow for shelving an instance that has existing volume attachments, or for attaching a volume to a shelved offloaded instance? They are different flows so we should be clear.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":323,"context_line":""},{"line_number":324,"context_line":"TODO"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"* When shelving, add a new attachment, with no host set, in the RESERVED state"},{"line_number":327,"context_line":"* When offloading, do a regular detach of the existing attachment"},{"line_number":328,"context_line":"* Note: BDM needs to store both attachment-uuids"},{"line_number":329,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_900ee8e3","line":326,"in_reply_to":"fa6399be_4824bdae","updated":"2016-10-18 13:15:10.000000000","message":"This was for an existing attachment.\n\nI should look at both.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":330,"context_line":"Alternatives"},{"line_number":331,"context_line":"------------"},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"We could struggle on fixing bugs in a \"whack a mole\" way."},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Data model impact"},{"line_number":336,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a8b8f92b","line":333,"updated":"2016-10-17 19:26:09.000000000","message":"Well I think the alternative is we basically resurrect Ildikov\u0027s multiattach patches, and hack something into the cinder API that nova calls when disconnecting a volume to tell us if we can do it or not, i.e. the attachment ref counting thing on the cinder side, in other words the \u0027is it safe to detach\u0027 API. Honestly the more time we spend talking through new API flows, it really seems like we\u0027re basically doing the same APIs over again but with maybe different fields being stored on the cinder side (the connection_info and host). And if we\u0027re already baking in \u0027is it safe to detach\u0027 logic / APIs for the new flow, I\u0027m not sure what it\u0027s buying us for all of the trouble.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":330,"context_line":"Alternatives"},{"line_number":331,"context_line":"------------"},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"We could struggle on fixing bugs in a \"whack a mole\" way."},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Data model impact"},{"line_number":336,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_f01c8415","line":333,"in_reply_to":"fa6399be_627b582a","updated":"2016-10-18 13:15:10.000000000","message":"It does feel like we are doing too much at once here, and we should find a way of staging things.\n\nA safe to detach call would be a good add. Storing the connecting_info and host on the cinder side, is required to be able to do lots of the clean up and force calls.\n\nI need to think on that a little more.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":330,"context_line":"Alternatives"},{"line_number":331,"context_line":"------------"},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"We could struggle on fixing bugs in a \"whack a mole\" way."},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Data model impact"},{"line_number":336,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_627b582a","line":333,"in_reply_to":"fa6399be_a8b8f92b","updated":"2016-10-17 22:43:14.000000000","message":"@Matt, in a number of ways you\u0027re absolutely correct and this is the same concern that I had(have) [rewriting the same API\u0027s with different params].\n\nThere is still a significant benefit though to fixing and simplifying these calls and interactions I think.  I do think we could do better, but there\u0027s certainly a desire for greater granularity.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":336,"context_line":"-----------------"},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":339,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":340,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":343,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a88f1974","line":340,"range":{"start_line":339,"start_character":46,"end_line":340,"end_character":56},"updated":"2016-10-17 19:26:09.000000000","message":"Again, I think cinder will be storing this and nova can just query for it.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dc72a429bfde83380512910c1b0a6c69bf151081","unresolved":false,"context_lines":[{"line_number":336,"context_line":"-----------------"},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":339,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":340,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":343,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_5f11aaae","line":340,"range":{"start_line":339,"start_character":46,"end_line":340,"end_character":56},"in_reply_to":"fa6399be_50b530ce","updated":"2016-10-18 17:56:58.000000000","message":"Nova already stores the connection_info in the BDM, and in mitaka we started storing the connector dict within the connection_info. The connector dict is what we got from os-brick prior to connection, and the connector dict is what we need to pass to os-terminate_connection on detach, and not having that on attachments created before mitaka was a bug, but at least we are passing that during local-delete now:\n\nhttps://review.openstack.org/#/c/257853/","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":336,"context_line":"-----------------"},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":339,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":340,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":343,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_c2726449","line":340,"range":{"start_line":339,"start_character":46,"end_line":340,"end_character":56},"in_reply_to":"fa6399be_a88f1974","updated":"2016-10-17 22:43:14.000000000","message":"So yes, Cinder will have this and we could certainly set up a way to query it.  The reality is that the only time Cinder needs a connector now is during the \"connection_initialize\" call, that\u0027s it.  None of the other calls made to Cinder regarding attach/detach use a connector object now.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":336,"context_line":"-----------------"},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":339,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":340,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":343,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_50b530ce","line":340,"range":{"start_line":339,"start_character":46,"end_line":340,"end_character":56},"in_reply_to":"fa6399be_c2726449","updated":"2016-10-18 13:15:10.000000000","message":"Yeah, we can stop storing the attachment id.\n\nI guess I am worried about where we end up changing host name for some reason, and we can no longer look up the attachment, its handy having the id. I am probably worrying way too much about that. I don\u0027t see what saving only the attachment-id rather than all the connection info is a problem.\n\nWe may have found the problem of not having the connection info in your note about local delete.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":366,"context_line":"Performance Impact"},{"line_number":367,"context_line":"------------------"},{"line_number":368,"context_line":""},{"line_number":369,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":370,"context_line":"all drivers."},{"line_number":371,"context_line":""},{"line_number":372,"context_line":"Other deployer impact"},{"line_number":373,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_48f75df5","line":370,"range":{"start_line":369,"start_character":0,"end_line":370,"end_character":12},"updated":"2016-10-17 19:26:09.000000000","message":"Well, there would be more API calls to cinder, so there is that extra API traffic.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":366,"context_line":"Performance Impact"},{"line_number":367,"context_line":"------------------"},{"line_number":368,"context_line":""},{"line_number":369,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":370,"context_line":"all drivers."},{"line_number":371,"context_line":""},{"line_number":372,"context_line":"Other deployer impact"},{"line_number":373,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_707dd4e6","line":370,"range":{"start_line":369,"start_character":0,"end_line":370,"end_character":12},"in_reply_to":"fa6399be_429d7458","updated":"2016-10-18 13:15:10.000000000","message":"6 down to 4? I am missing the details on what those calls are.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":366,"context_line":"Performance Impact"},{"line_number":367,"context_line":"------------------"},{"line_number":368,"context_line":""},{"line_number":369,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":370,"context_line":"all drivers."},{"line_number":371,"context_line":""},{"line_number":372,"context_line":"Other deployer impact"},{"line_number":373,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_429d7458","line":370,"range":{"start_line":369,"start_character":0,"end_line":370,"end_character":12},"in_reply_to":"fa6399be_48f75df5","updated":"2016-10-17 22:43:14.000000000","message":"I\u0027ve actually proposed *fewer* API calls;\n6 --\u003e 2\n\n even with the revisit to address granularity concerns, we\u0027ll still be equal or fewer (fewer unless something else gets added into the mix).\n\n6 --\u003e 4","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"661ae3a696b9cbcccf3a862c69c7ced692677e28","unresolved":false,"context_lines":[{"line_number":411,"context_line":"Testing"},{"line_number":412,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_48459d15","line":414,"updated":"2016-10-17 19:26:09.000000000","message":"Just thinking out loud, we\u0027d have some CI jobs like this:\n\n1. single node dsvm job would be running all of the latest code, so it\u0027s using the new flow always.\n\n2. Any partial grenade jobs would be running the old flow because you\u0027d have 1 remaining nova-compute service running newton code, so the min service version check doesn\u0027t pass.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"b9d0c10fa8ccd7da36115e0b5c6b43c75993c421","unresolved":false,"context_lines":[{"line_number":411,"context_line":"Testing"},{"line_number":412,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_a2dad015","line":414,"in_reply_to":"fa6399be_48459d15","updated":"2016-10-17 22:43:14.000000000","message":"@Matt, yep!  I\u0027ve been looking at how to deal with case number 2.  I\u0027m assuming there\u0027s some way to tie in via the conductor to get an \"all node updated\" before trying to make the switch?\n\nThe only solution I\u0027ve come up with to this point is that you in fact support both simultaneously which while sort of a pain does seem to work.  That means that the Nova code has to be compatible and for now you have to leave all of the existing mechanisms in place which sucks, but it does work and frankly we have to do that for at least a full release anyway.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"3c4414302e1df300e5bc96cb8ff0fb4338128dba","unresolved":false,"context_lines":[{"line_number":411,"context_line":"Testing"},{"line_number":412,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."}],"source_content_type":"text/x-rst","patch_set":8,"id":"fa6399be_9034284b","line":414,"in_reply_to":"fa6399be_a2dad015","updated":"2016-10-18 13:15:10.000000000","message":"Yeah, see above, I think we have to support both flows for a little while, until we get everyone moved across.","commit_id":"d8e90e4ba79c35cb903088d501ed09ebf8adc8aa"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* Attach a volume to an instance, including during spawning an instance,"},{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possible"},{"line_number":38,"context_line":"  detach the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate a instance, involves setting up the volume connection on the"},{"line_number":40,"context_line":"  destination host, before kicking off the live-migrate, then removing source"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_b1abdd88","line":37,"range":{"start_line":37,"start_character":64,"end_line":37,"end_character":72},"updated":"2016-11-08 12:33:41.000000000","message":"possibly","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":35,"context_line":"* Attach a volume to an instance, including during spawning an instance,"},{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possible"},{"line_number":38,"context_line":"  detach the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate a instance, involves setting up the volume connection on the"},{"line_number":40,"context_line":"  destination host, before kicking off the live-migrate, then removing source"},{"line_number":41,"context_line":"  host connections once the live-migrate has completed."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_98351648","line":38,"range":{"start_line":38,"start_character":2,"end_line":38,"end_character":8},"updated":"2016-11-08 12:33:41.000000000","message":"disconnect","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possible"},{"line_number":38,"context_line":"  detach the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate a instance, involves setting up the volume connection on the"},{"line_number":40,"context_line":"  destination host, before kicking off the live-migrate, then removing source"},{"line_number":41,"context_line":"  host connections once the live-migrate has completed."},{"line_number":42,"context_line":"* Migrate and resize are very similar to live-migrate, from this new view of"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_1193a95c","line":39,"range":{"start_line":39,"start_character":15,"end_line":39,"end_character":16},"updated":"2016-11-08 12:33:41.000000000","message":"an","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possible"},{"line_number":38,"context_line":"  detach the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate a instance, involves setting up the volume connection on the"},{"line_number":40,"context_line":"  destination host, before kicking off the live-migrate, then removing source"},{"line_number":41,"context_line":"  host connections once the live-migrate has completed."},{"line_number":42,"context_line":"* Migrate and resize are very similar to live-migrate, from this new view of"},{"line_number":43,"context_line":"  the world."},{"line_number":44,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_71b6a5dd","line":41,"range":{"start_line":39,"start_character":0,"end_line":41,"end_character":55},"updated":"2016-11-08 12:33:41.000000000","message":"Would it be worth highlighting that we might also need to roll the above back if the migration fails?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possible"},{"line_number":38,"context_line":"  detach the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate a instance, involves setting up the volume connection on the"},{"line_number":40,"context_line":"  destination host, before kicking off the live-migrate, then removing source"},{"line_number":41,"context_line":"  host connections once the live-migrate has completed."},{"line_number":42,"context_line":"* Migrate and resize are very similar to live-migrate, from this new view of"},{"line_number":43,"context_line":"  the world."},{"line_number":44,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_f05a784f","line":41,"range":{"start_line":39,"start_character":0,"end_line":41,"end_character":55},"in_reply_to":"9a629dbe_71b6a5dd","updated":"2016-11-09 12:32:36.000000000","message":"I guess that detail is covered below, was trying to keep this bit short as possible. Not sure.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":50,"context_line":""},{"line_number":51,"context_line":"In particular, please note:"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"* Volume attachment is specific to a host name, server uuid, and volume uuid"},{"line_number":54,"context_line":"* You can have multiple attachments to the same volume, to different instances"},{"line_number":55,"context_line":"  (on the same host or different hosts), when the volume is marked"},{"line_number":56,"context_line":"  multi_attach\u003dTrue"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_e47755d2","line":53,"range":{"start_line":53,"start_character":42,"end_line":53,"end_character":46},"updated":"2016-11-08 12:33:41.000000000","message":"_uuid?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":59,"context_line":"* Volume connections on a host can be shared with other volumes that are"},{"line_number":60,"context_line":"  connected to the same volume backend, depending on the chosen driver."},{"line_number":61,"context_line":"  As such, need to take care when removing that connection, and not adding two"},{"line_number":62,"context_line":"  connections by mistake. Please note the Attaching and detaching states are"},{"line_number":63,"context_line":"  exclusive per host_uuid to ensure there are no races during that operation,"},{"line_number":64,"context_line":"  and has to be the responsibility of Cinder as it has to tell os-brick if a"},{"line_number":65,"context_line":"  new connection has to be added or removed at the appropriate points."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_d1ecd1c9","line":62,"range":{"start_line":62,"start_character":42,"end_line":62,"end_character":43},"updated":"2016-11-08 12:33:41.000000000","message":"a","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":70,"context_line":"The main change between the new API flow and the old API flow is that the"},{"line_number":71,"context_line":"connection_info is now stored in Cinder, so Nova (and other clients)"},{"line_number":72,"context_line":"no longer need to store that information. Cinder is also more explicitly"},{"line_number":73,"context_line":"telling os-brick what it needs to do when connecting or disconnecting"},{"line_number":74,"context_line":"a volume."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_d8022e3e","line":73,"range":{"start_line":73,"start_character":8,"end_line":73,"end_character":16},"updated":"2016-11-08 12:33:41.000000000","message":"Shouldn\u0027t this be Nova as it is using the new API itself before calling os-brick?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":70,"context_line":"The main change between the new API flow and the old API flow is that the"},{"line_number":71,"context_line":"connection_info is now stored in Cinder, so Nova (and other clients)"},{"line_number":72,"context_line":"no longer need to store that information. Cinder is also more explicitly"},{"line_number":73,"context_line":"telling os-brick what it needs to do when connecting or disconnecting"},{"line_number":74,"context_line":"a volume."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"TODO, there is discussion on how the Cinder APIs look for all of these API"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_733bd29c","line":73,"range":{"start_line":73,"start_character":8,"end_line":73,"end_character":16},"in_reply_to":"9a629dbe_d8022e3e","updated":"2016-11-09 12:32:36.000000000","message":"Yeah, thats drifted out of date.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"f2d5dedf8f4b4f5590bd79f8da2bea47cbf17c83","unresolved":false,"context_lines":[{"line_number":77,"context_line":"calls. For now I will use the names I prefer."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* create_attachment is close to what was reserve_volume"},{"line_number":80,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":81,"context_line":"  plus it now stores the connection_info"},{"line_number":82,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":83,"context_line":"  required tidy up on the back end, and confirm the detach worked."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_ab950fe5","line":80,"range":{"start_line":80,"start_character":2,"end_line":80,"end_character":23},"updated":"2016-11-08 20:00:36.000000000","message":"I\u0027m not sure we are planning to have an initialize_attachment call too. My understanding was to have create and update as you refer in line #84.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":77,"context_line":"calls. For now I will use the names I prefer."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* create_attachment is close to what was reserve_volume"},{"line_number":80,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":81,"context_line":"  plus it now stores the connection_info"},{"line_number":82,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":83,"context_line":"  required tidy up on the back end, and confirm the detach worked."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_18fd863a","line":80,"range":{"start_line":80,"start_character":46,"end_line":80,"end_character":47},"updated":"2016-11-08 12:33:41.000000000","message":"_","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":77,"context_line":"calls. For now I will use the names I prefer."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* create_attachment is close to what was reserve_volume"},{"line_number":80,"context_line":"* initialize_attachment is what was initialize connection,"},{"line_number":81,"context_line":"  plus it now stores the connection_info"},{"line_number":82,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":83,"context_line":"  required tidy up on the back end, and confirm the detach worked."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_905bfc86","line":80,"range":{"start_line":80,"start_character":2,"end_line":80,"end_character":23},"in_reply_to":"9a629dbe_ab950fe5","updated":"2016-11-09 12:32:36.000000000","message":"oops, that got left behind.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  plus it now stores the connection_info"},{"line_number":82,"context_line":"* delete is what was terminate and detach, and is used to do any"},{"line_number":83,"context_line":"  required tidy up on the back end, and confirm the detach worked."},{"line_number":84,"context_line":"* update is used to replace initialize connection"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Here are the key Cinder APIs we need to worry about:"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_789a0216","line":84,"range":{"start_line":84,"start_character":38,"end_line":84,"end_character":39},"updated":"2016-11-08 12:33:41.000000000","message":"_","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":188,"context_line":"* once we land on the chosen host, h1, we continue"},{"line_number":189,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":190,"context_line":"* connection_info \u003d update_attachment(attach_uuid, host_uuid\u003dh1, con)"},{"line_number":191,"context_line":"* (if shared connection, take lock, and check if connection is needed)"},{"line_number":192,"context_line":"* work with osbrick to ensure host connection in place"},{"line_number":193,"context_line":"* update instance xml (etc)."},{"line_number":194,"context_line":"* boot the server"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_93b419f3","line":191,"range":{"start_line":191,"start_character":2,"end_line":191,"end_character":70},"updated":"2016-11-08 12:33:41.000000000","message":"by calling something like get_attachments(host_uuid\u003dh1, con) or asking os_brick to confirm if the volume is already connected?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":188,"context_line":"* once we land on the chosen host, h1, we continue"},{"line_number":189,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":190,"context_line":"* connection_info \u003d update_attachment(attach_uuid, host_uuid\u003dh1, con)"},{"line_number":191,"context_line":"* (if shared connection, take lock, and check if connection is needed)"},{"line_number":192,"context_line":"* work with osbrick to ensure host connection in place"},{"line_number":193,"context_line":"* update instance xml (etc)."},{"line_number":194,"context_line":"* boot the server"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_211ae46e","line":191,"range":{"start_line":191,"start_character":2,"end_line":191,"end_character":70},"in_reply_to":"9a629dbe_93b419f3","updated":"2016-11-09 12:32:36.000000000","message":"I should make it clear, and add more details in the next section.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":199,"context_line":"* connection_info \u003d get_attachment_info(attachment_uuid)"},{"line_number":200,"context_line":"* if shared backend, acquire lock for detach process, if other attachments"},{"line_number":201,"context_line":"  listed as sharing the connection, skip os-brick detach call"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_c40ed133","line":198,"range":{"start_line":198,"start_character":30,"end_line":198,"end_character":57},"updated":"2016-11-08 12:33:41.000000000","message":"We don\u0027t want to do this until we are sure it\u0027s required below right?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"Now when the server is deleted, we detach the volume:"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* shutdown and delete the VM, this disconnects the volume"},{"line_number":199,"context_line":"* connection_info \u003d get_attachment_info(attachment_uuid)"},{"line_number":200,"context_line":"* if shared backend, acquire lock for detach process, if other attachments"},{"line_number":201,"context_line":"  listed as sharing the connection, skip os-brick detach call"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_8121f0a1","line":198,"range":{"start_line":198,"start_character":30,"end_line":198,"end_character":57},"in_reply_to":"9a629dbe_c40ed133","updated":"2016-11-09 12:32:36.000000000","message":"I mean disconnected from the hypervisor point of view.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":210,"context_line":"  for the existing host attachment."},{"line_number":211,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":212,"context_line":"  correctly cleaned up, but only when required."},{"line_number":213,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)"},{"line_number":214,"context_line":"* TODO: should the call to os-brick to detach fail, what should we do?"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Attach and Detach volume"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_4432c1f2","line":213,"range":{"start_line":213,"start_character":26,"end_line":213,"end_character":32},"updated":"2016-11-08 12:33:41.000000000","message":"connect?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":211,"context_line":"  This is required to ensure when there is a shared host connection, it is"},{"line_number":212,"context_line":"  correctly cleaned up, but only when required."},{"line_number":213,"context_line":"* should os-brick fail to attach, we call delete_attachment(attachment_uuid)"},{"line_number":214,"context_line":"* TODO: should the call to os-brick to detach fail, what should we do?"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Attach and Detach volume"},{"line_number":217,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_e441153b","line":214,"range":{"start_line":214,"start_character":39,"end_line":214,"end_character":45},"updated":"2016-11-08 12:33:41.000000000","message":"disconnect?","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":230,"context_line":"* First attempt to hot unplug the volume from the VM"},{"line_number":231,"context_line":"* If this fails, we should fail the operation."},{"line_number":232,"context_line":"* connection_info \u003d get_attachment_info(attachment_uuid)"},{"line_number":233,"context_line":"* call os-brick to do the detach, if required, in the usual way"},{"line_number":234,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Note: there is little difference with boot in terms of API calls to Cinder."}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_e4dd9571","line":233,"range":{"start_line":233,"start_character":26,"end_line":233,"end_character":32},"updated":"2016-11-08 12:33:41.000000000","message":"disconnect","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":245,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":246,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh2, con)"},{"line_number":247,"context_line":"* this is allowed, even if multi-attach\u003dfalse"},{"line_number":248,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":249,"context_line":"* talk to os-brick to connect to the host, in the usual way"},{"line_number":250,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"},{"line_number":251,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_4418011e","line":248,"range":{"start_line":248,"start_character":2,"end_line":248,"end_character":60},"updated":"2016-11-08 12:33:41.000000000","message":"or stash the original attachment_uuids for the src in migrate_data? We should also be able to remove the bdms we are already stashing there thanks to cinder now controlling connection_info.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f9a0a5306e66c11d3ce8efcc66ade05d3db4d52d","unresolved":false,"context_lines":[{"line_number":245,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":246,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh2, con)"},{"line_number":247,"context_line":"* this is allowed, even if multi-attach\u003dfalse"},{"line_number":248,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":249,"context_line":"* talk to os-brick to connect to the host, in the usual way"},{"line_number":250,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"},{"line_number":251,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_8221eea1","line":248,"range":{"start_line":248,"start_character":2,"end_line":248,"end_character":60},"in_reply_to":"9a629dbe_4418011e","updated":"2016-11-09 12:32:36.000000000","message":"But storing the attachment_ids in the migrate data would mean having to store the list of volumes attached to the instance, and store the two attachment_ids for each of those.\n\nIt seems far easier to track the two host connections inside the BDM, where we store all volume related information.\n\nNote we are no longer needing to store the connection_info.\n\nI feel like I must be missing something, but I think it could work either way around.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7bfca98e169d9a808c9bdb4c0b1be0fee2be8974","unresolved":false,"context_lines":[{"line_number":262,"context_line":"destination host. For rollback, we would do the reverse, i.e. detach the"},{"line_number":263,"context_line":"destination node attachment."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Note how the BDM stores an attachment id for the source and destination host"},{"line_number":266,"context_line":"while the live-migration is in process."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Migrate"},{"line_number":269,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9a629dbe_a4ab9d88","line":266,"range":{"start_line":265,"start_character":0,"end_line":266,"end_character":39},"updated":"2016-11-08 12:33:41.000000000","message":"as above, an alternative is just to stash the original attachment_uuids that in migrate_data.","commit_id":"03453f65cbf3c6f00806eab2a4155ba236e39e20"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"1d1457c185ae35ceca7c65527b36923aa90505a5","unresolved":false,"context_lines":[{"line_number":403,"context_line":"* Part of pre_live_migration_at_destination"},{"line_number":404,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":405,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh2, con)"},{"line_number":406,"context_line":"* this is allowed, even if multi-attach\u003dfalse"},{"line_number":407,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":408,"context_line":"* talk to os-brick to connect to the host, in the usual way"},{"line_number":409,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9a629dbe_e69d4b67","line":406,"range":{"start_line":406,"start_character":19,"end_line":406,"end_character":45},"updated":"2016-11-09 19:07:45.000000000","message":"I would extend this to be super clear, like: even if multi-attach\u003dfalse as the instance_uuid is the same","commit_id":"4e3400513d7597325cec27f1a7f3fd1e79857bec"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"1d1457c185ae35ceca7c65527b36923aa90505a5","unresolved":false,"context_lines":[{"line_number":403,"context_line":"* Part of pre_live_migration_at_destination"},{"line_number":404,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":405,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh2, con)"},{"line_number":406,"context_line":"* this is allowed, even if multi-attach\u003dfalse"},{"line_number":407,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":408,"context_line":"* talk to os-brick to connect to the host, in the usual way"},{"line_number":409,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9a629dbe_06eebfb3","line":406,"range":{"start_line":406,"start_character":27,"end_line":406,"end_character":45},"updated":"2016-11-09 19:07:45.000000000","message":"If we allow live-migrate with multi-attach we might add a comment about disconnecting the volume on the source to be careful with the shared connection case.","commit_id":"4e3400513d7597325cec27f1a7f3fd1e79857bec"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cinder-new-attach-apis"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Make Nova use Cinder\u0027s new attach/dettach APIs."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Problem description"},{"line_number":16,"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":12,"id":"7a77a97e_84abf2d5","line":13,"updated":"2016-11-19 23:41:15.000000000","message":"s/dettach/detach","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"dda424033ae7fb85d0e39e7edb9a7f0b8a00b7e3","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cinder-new-attach-apis"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Make Nova use Cinder\u0027s new attach/dettach APIs."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Problem description"},{"line_number":16,"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":12,"id":"7a77a97e_5f9d4e58","line":13,"in_reply_to":"7a77a97e_84abf2d5","updated":"2016-11-21 17:12:52.000000000","message":"oops.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":42,"context_line":"  the destination host connection is removed."},{"line_number":43,"context_line":"* Migrate and resize are very similar to live-migrate, from this new view of"},{"line_number":44,"context_line":"  the world."},{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_44a39a4f","line":45,"updated":"2016-11-19 23:41:15.000000000","message":"Guh, just s/Evacuate/Rebuild/ :)","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"d19cef2a9691a581e3da2d1e8f69e637d4439bec","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_00fe276b","line":48,"updated":"2016-11-14 22:49:26.000000000","message":"from","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_780d993d","line":48,"in_reply_to":"7a77a97e_00fe276b","updated":"2016-11-19 23:41:15.000000000","message":"Why do we want the volume to stay \"logically attached\" to an instance that is shelved?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"dda424033ae7fb85d0e39e7edb9a7f0b8a00b7e3","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_bff022cb","line":48,"in_reply_to":"7a77a97e_780d993d","updated":"2016-11-21 17:12:52.000000000","message":"The idea of shelved is just to logically model an instance that is just turned off, and not currently on a host.\n\nYou don\u0027t want someone else stealing your volume, stopping you from booting up. If you don\u0027t mind about that, what you want is a snapshot, not shelve.\n\nThis is how it works today.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"0f208d45bae7b06021d4b1d39a2d14228453d7cd","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"5a74a57a_6ce0f6cd","line":48,"in_reply_to":"7a77a97e_b5768104","updated":"2016-11-28 17:08:25.000000000","message":"There is no connection to the back end here, once the shelved instance is offloaded from the host.\n\nIts purely the instance keeps the volume \"reserved\" to the same instance, so you can\u0027t start using (by accident) for some other VM without releasing the volume from that VM. In the same way you don\u0027t let other people use your IP address while you are shelved.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"2d9c0836769d0d0170a975bd7fa57b6e34e58501","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_b5768104","line":48,"in_reply_to":"7a77a97e_bff022cb","updated":"2016-11-21 17:55:34.000000000","message":"\"logically model an instance that is just turned off\" should mean that there are no more connections from the instance to its volume. Therefore, I see no reason to have shelved instances consuming a connection to a volume.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_b807311b","line":49,"updated":"2016-11-19 23:41:15.000000000","message":"Why?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"2d9c0836769d0d0170a975bd7fa57b6e34e58501","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_f5c5590a","line":49,"in_reply_to":"7a77a97e_1fa596b4","updated":"2016-11-21 17:55:34.000000000","message":"So the instance should just be shut down, then. Honestly, the whole shelved thing is stupid, IMHO. And I really don\u0027t see the point of keeping a connection to a volume open from a shelved instance.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"dda424033ae7fb85d0e39e7edb9a7f0b8a00b7e3","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_1fa596b4","line":49,"in_reply_to":"7a77a97e_b807311b","updated":"2016-11-21 17:12:52.000000000","message":"Because its attached at the moment, but you might want to change that without booting up the instance. Just like you would with a shutdown VM.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"0f208d45bae7b06021d4b1d39a2d14228453d7cd","unresolved":false,"context_lines":[{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5a74a57a_8c955234","line":49,"in_reply_to":"7a77a97e_f5c5590a","updated":"2016-11-28 17:08:25.000000000","message":"So I should be clear, there is no connection to the volume backend, its just a logical \"reserve\" of the volume for the specific instance, as the volume is (generally) only allowed to be connected to one instance at once.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"9d1201ce65a51b9782e10ce151607a10d717a747","unresolved":false,"context_lines":[{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_eaa4af09","line":50,"updated":"2016-11-14 19:52:25.000000000","message":"detach other volumes for a powered off instance?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of a powered off instance"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_fa8e2826","line":50,"in_reply_to":"7a77a97e_eaa4af09","updated":"2016-11-15 09:33:51.000000000","message":"In my Nova head, thats the same as a powered on instance.\n\nThe root volume can only be removed when the instance is powered off.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Volume attachment is specific to a host uuid, server uuid, and volume uuid"},{"line_number":55,"context_line":"* You can have multiple attachments to the same volume, to different instances"},{"line_number":56,"context_line":"  (on the same host or different hosts), when the volume is marked"},{"line_number":57,"context_line":"  multi_attach\u003dTrue"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_930fb62d","line":54,"updated":"2016-11-19 23:41:15.000000000","message":"s/server uuid/instance uuid/ (because the corresponding Cinder API refers to them as instances, not servers)","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"dda424033ae7fb85d0e39e7edb9a7f0b8a00b7e3","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Volume attachment is specific to a host uuid, server uuid, and volume uuid"},{"line_number":55,"context_line":"* You can have multiple attachments to the same volume, to different instances"},{"line_number":56,"context_line":"  (on the same host or different hosts), when the volume is marked"},{"line_number":57,"context_line":"  multi_attach\u003dTrue"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_bf9e6261","line":54,"in_reply_to":"7a77a97e_930fb62d","updated":"2016-11-21 17:12:52.000000000","message":"Not sure thats decided yet, was trying to talk Nova terms for this spec.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"9d1201ce65a51b9782e10ce151607a10d717a747","unresolved":false,"context_lines":[{"line_number":58,"context_line":"* For the same server uuid and volume uuid, you can have connections on two"},{"line_number":59,"context_line":"  different hosts, even when multi_attach\u003dFalse. This is generally used when"},{"line_number":60,"context_line":"  moving a VM."},{"line_number":61,"context_line":"* Volume connections on a host can be shared with other volumes that are"},{"line_number":62,"context_line":"  connected to the same volume backend, depending on the chosen driver."},{"line_number":63,"context_line":"  As such, need to take care when removing that connection, and not adding two"},{"line_number":64,"context_line":"  connections by mistake and not removing an in use connection too early."}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_ca09b3df","line":61,"updated":"2016-11-14 19:52:25.000000000","message":"Do you mean iSCSI connections/sessions here?  If so, os-brick and the iscsiadm utilities handle connecting to the target portal correctly.   os-brick also handles removing sessions if there are no more volumes attached to that target portal left over.\n\nIf you mean a single volume attachment is used with multiple VMs, then that is a different scenario.   In that case Nova should get some hints from Cinder if that volume is shared with multiple VMs on that same host.  Nova shouldn\u0027t call os-brick in that case to remove the volume from the host if it\u0027s still being used.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":58,"context_line":"* For the same server uuid and volume uuid, you can have connections on two"},{"line_number":59,"context_line":"  different hosts, even when multi_attach\u003dFalse. This is generally used when"},{"line_number":60,"context_line":"  moving a VM."},{"line_number":61,"context_line":"* Volume connections on a host can be shared with other volumes that are"},{"line_number":62,"context_line":"  connected to the same volume backend, depending on the chosen driver."},{"line_number":63,"context_line":"  As such, need to take care when removing that connection, and not adding two"},{"line_number":64,"context_line":"  connections by mistake and not removing an in use connection too early."}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_9ac7f444","line":61,"in_reply_to":"7a77a97e_ca09b3df","updated":"2016-11-15 09:33:51.000000000","message":"Right its the later case I am trying to describe here. I describe the hints from Cinder below.\n\nDo we need a lock for both cases though? Sounds like I should list out both cases.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"9d1201ce65a51b9782e10ce151607a10d717a747","unresolved":false,"context_lines":[{"line_number":73,"context_line":"Nova and Cinder, that is well understood by both sides."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"One other big change between the new API flow and the old API flow"},{"line_number":76,"context_line":"is that the connection_info is now stored in Cinder."},{"line_number":77,"context_line":"There have been many bugs around Nova getting confused and handing back"},{"line_number":78,"context_line":"incorrect information to Cinder. This avoids all those problems."},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_ea34af4b","line":76,"updated":"2016-11-14 19:52:25.000000000","message":"We also need to store the connector in Cinder.\n\nThe connection_info is the target based information that comes back from Cinder\u0027s driver at initialize_connection time.\n\nThe connector is the initiator side information collected about a host, by os-brick.  This connector is passed to Cinder\u0027s initialize_connection so the Cinder backend knows who to export a volume to.   That connector is needed to remove an exported volume from the backend.   Cinder should store it to resolve the current issues we have today when nova needs to tell cinder to detach a volume, but doesn\u0027t have instance information.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":73,"context_line":"Nova and Cinder, that is well understood by both sides."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"One other big change between the new API flow and the old API flow"},{"line_number":76,"context_line":"is that the connection_info is now stored in Cinder."},{"line_number":77,"context_line":"There have been many bugs around Nova getting confused and handing back"},{"line_number":78,"context_line":"incorrect information to Cinder. This avoids all those problems."},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_5a88fce7","line":76,"in_reply_to":"7a77a97e_ea34af4b","updated":"2016-11-15 09:33:51.000000000","message":"Good point, I glossed over that being stored as well, I just assumed it. Matt keeping putting me right about the connector.\n\nI now get Lee\u0027s comments below now.\n\nThis does complicate the upgrade story, I should tidy that up.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":83,"context_line":"Please note:"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"* create_attachment is very close to what was reserve_volume"},{"line_number":86,"context_line":"* update_attachment is replacing initialize_attachment"},{"line_number":87,"context_line":"* delete_attachment replaces all previous operations used in"},{"line_number":88,"context_line":"  detaching a volume"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_a2d95f59","line":86,"range":{"start_line":86,"start_character":44,"end_line":86,"end_character":54},"updated":"2016-11-11 09:42:02.000000000","message":"connection?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"9d1201ce65a51b9782e10ce151607a10d717a747","unresolved":false,"context_lines":[{"line_number":83,"context_line":"Please note:"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"* create_attachment is very close to what was reserve_volume"},{"line_number":86,"context_line":"* update_attachment is replacing initialize_attachment"},{"line_number":87,"context_line":"* delete_attachment replaces all previous operations used in"},{"line_number":88,"context_line":"  detaching a volume"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_8a46dbbd","line":86,"range":{"start_line":86,"start_character":44,"end_line":86,"end_character":54},"in_reply_to":"9a629dbe_a2d95f59","updated":"2016-11-14 19:52:25.000000000","message":"yah should be initialize_connection","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"    {\"attachment\": {"},{"line_number":95,"context_line":"      \"server_uuid\": \"\u003cserver_uuid\u003e\","},{"line_number":96,"context_line":"      [\"host_uuid\": \"...\", \"connector\": \"...\"]"},{"line_number":97,"context_line":"    }}"},{"line_number":98,"context_line":"    {\"attachment\": {"},{"line_number":99,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_bbf79dd1","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":46},"updated":"2016-11-11 09:42:02.000000000","message":"Shouldn\u0027t these just be key values in the dict we are posting?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"    {\"attachment\": {"},{"line_number":95,"context_line":"      \"server_uuid\": \"\u003cserver_uuid\u003e\","},{"line_number":96,"context_line":"      [\"host_uuid\": \"...\", \"connector\": \"...\"]"},{"line_number":97,"context_line":"    }}"},{"line_number":98,"context_line":"    {\"attachment\": {"},{"line_number":99,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_faed488f","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":46},"in_reply_to":"7a77a97e_4a23e305","updated":"2016-11-15 09:33:51.000000000","message":"server \u003d instance, host \u003d hypervisor\n\nIts a Nova API concept thing. might be better using some other name in the Cinder API to make the distinction clearer.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"9d1201ce65a51b9782e10ce151607a10d717a747","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":"    {\"attachment\": {"},{"line_number":95,"context_line":"      \"server_uuid\": \"\u003cserver_uuid\u003e\","},{"line_number":96,"context_line":"      [\"host_uuid\": \"...\", \"connector\": \"...\"]"},{"line_number":97,"context_line":"    }}"},{"line_number":98,"context_line":"    {\"attachment\": {"},{"line_number":99,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_4a23e305","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":46},"in_reply_to":"9a629dbe_bbf79dd1","updated":"2016-11-14 19:52:25.000000000","message":"what is the difference between server_uuid and host _uuid ?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":103,"context_line":"    }}"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* Returns an attachment document that includes the attachment_uuid"},{"line_number":106,"context_line":"* We only allow one server_uuid per volume if multi-attach\u003dFalse."},{"line_number":107,"context_line":"* Note: we assume cinder ensures that is atomic, and its not possible"},{"line_number":108,"context_line":"  to race and actually have two server_uuids attached to the volume"},{"line_number":109,"context_line":"* We allow multiple attachments for the same server_uuid,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_a0c86f23","line":106,"updated":"2016-11-19 23:41:15.000000000","message":"s/server_uuid/instance_uuid/ to be consistent with the Cinder API.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"94353fdbbce3f31b4cc625237a1a4e0301d6d97b","unresolved":false,"context_lines":[{"line_number":114,"context_line":"* Volume moves into the \"inuse\" state (TODO - no agreement on this)"},{"line_number":115,"context_line":"* If no host_uuid and connector given, attachment goes into \"attaching\" state"},{"line_number":116,"context_line":"* If host_uuid and connector are given, attahment goes into \"in-use\" state,"},{"line_number":117,"context_line":"  and returns valid conenction_info that can be passed to os-brick"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::"},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_a0ef8f85","line":117,"updated":"2016-11-19 23:41:15.000000000","message":"s/conenction_info/connection_info/","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* When these properties are set, Cinder works with the backend to get"},{"line_number":134,"context_line":"  the connection_info that needs to be passed to os-brick, and returns"},{"line_number":135,"context_line":"  that in the attachment document."},{"line_number":136,"context_line":"* This call is also used to set \"status\"\u003d\"error\", for when Nova was unable"},{"line_number":137,"context_line":"  to successfully disconnect the host connection to the volume backend."},{"line_number":138,"context_line":"  When this is done, note that the cinder backend should do similar cleanup"},{"line_number":139,"context_line":"  to when the volume is deleted, and that volume no longer reserves the volume"},{"line_number":140,"context_line":"  for the associated server_uuid, and it no longer counts towards the list of"},{"line_number":141,"context_line":"  attachments that share a host connection. It is only here so its clear there"},{"line_number":142,"context_line":"  may be something on the associated host that will need manual cleanup, or a"},{"line_number":143,"context_line":"  retry of the clean up when the nova-compute service is next started. As such"},{"line_number":144,"context_line":"  the connection_info will still be present to allow the retry of disconnect"},{"line_number":145,"context_line":"  of the host connection to the cinder backend."},{"line_number":146,"context_line":"* Once a volume is in the in-use state, the only allowed change is to the"},{"line_number":147,"context_line":"  status"},{"line_number":148,"context_line":"* Note: because there is no acknowledgment that the host connection succeeded,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_5098206a","line":145,"range":{"start_line":136,"start_character":2,"end_line":145,"end_character":47},"updated":"2016-11-11 09:42:02.000000000","message":"As I\u0027ve noted below it would be useful if we could set the error state with or without providing a host connector for the evacuate use case. It would also be nice to have an example of this in the spec.\n\n    POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::\n\n    {\"attachment\": {\n      \"host_uuid\": \"\u003chost_uuid\u003e\",\n      \"status\": \"error\"}}\n    {\"attachment\": {\n      \"uuid\": \"\u003cattachment_uuid\u003e\",\n      \"status\": \"error\"\n    }}","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* When these properties are set, Cinder works with the backend to get"},{"line_number":134,"context_line":"  the connection_info that needs to be passed to os-brick, and returns"},{"line_number":135,"context_line":"  that in the attachment document."},{"line_number":136,"context_line":"* This call is also used to set \"status\"\u003d\"error\", for when Nova was unable"},{"line_number":137,"context_line":"  to successfully disconnect the host connection to the volume backend."},{"line_number":138,"context_line":"  When this is done, note that the cinder backend should do similar cleanup"},{"line_number":139,"context_line":"  to when the volume is deleted, and that volume no longer reserves the volume"},{"line_number":140,"context_line":"  for the associated server_uuid, and it no longer counts towards the list of"},{"line_number":141,"context_line":"  attachments that share a host connection. It is only here so its clear there"},{"line_number":142,"context_line":"  may be something on the associated host that will need manual cleanup, or a"},{"line_number":143,"context_line":"  retry of the clean up when the nova-compute service is next started. As such"},{"line_number":144,"context_line":"  the connection_info will still be present to allow the retry of disconnect"},{"line_number":145,"context_line":"  of the host connection to the cinder backend."},{"line_number":146,"context_line":"* Once a volume is in the in-use state, the only allowed change is to the"},{"line_number":147,"context_line":"  status"},{"line_number":148,"context_line":"* Note: because there is no acknowledgment that the host connection succeeded,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_fa3628b3","line":145,"range":{"start_line":136,"start_character":2,"end_line":145,"end_character":47},"in_reply_to":"9a629dbe_5098206a","updated":"2016-11-15 09:33:51.000000000","message":"I am being unclear, but you only should only need to do\n\nPOST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::\n\n    {\"attachment\": {\"status\": \"in-use\"}}\n\nThat second value is meant to be the response information.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":170,"context_line":""},{"line_number":171,"context_line":"TODO: GET attachments/?host_uuid\u003d\"\u003cuuid\u003e\"\u0026status\u003d\"error\""},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* To recover from evacuate, Nova wants to know all the attachments related"},{"line_number":174,"context_line":"  to the given host, that are in the error state. This means the detach"},{"line_number":175,"context_line":"  operation can be retried, and if successful, the attachment can be deleted."},{"line_number":176,"context_line":"* When nova-compute starts up, we could check with os-brick to ensure all the"},{"line_number":177,"context_line":"  host connections are correctly present, and there are no missing connections"},{"line_number":178,"context_line":"  or extra connections, compared to what is expected."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_30648cb7","line":175,"range":{"start_line":173,"start_character":2,"end_line":175,"end_character":77},"updated":"2016-11-11 09:42:02.000000000","message":"This assumes that the new host sets the attachment into error and at the moment that means using the original hosts connector right? \n\nWould it be possible to have the new host set the attachment into an error state just using the host_uuid, leaving Cinder to stash and reuse the correct connector?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":170,"context_line":""},{"line_number":171,"context_line":"TODO: GET attachments/?host_uuid\u003d\"\u003cuuid\u003e\"\u0026status\u003d\"error\""},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* To recover from evacuate, Nova wants to know all the attachments related"},{"line_number":174,"context_line":"  to the given host, that are in the error state. This means the detach"},{"line_number":175,"context_line":"  operation can be retried, and if successful, the attachment can be deleted."},{"line_number":176,"context_line":"* When nova-compute starts up, we could check with os-brick to ensure all the"},{"line_number":177,"context_line":"  host connections are correctly present, and there are no missing connections"},{"line_number":178,"context_line":"  or extra connections, compared to what is expected."}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_3af3400c","line":175,"range":{"start_line":173,"start_character":2,"end_line":175,"end_character":77},"in_reply_to":"9a629dbe_30648cb7","updated":"2016-11-15 09:33:51.000000000","message":"It only needs the attachment_uuid in this new flow.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":331,"context_line":"* Acquire the shared_host_connection lock"},{"line_number":332,"context_line":"* Set the host_uuid and connector to make the attachment into \"in-use\" state"},{"line_number":333,"context_line":"* if shared_host_connection_attachments\u003d0, call os-brick to connect"},{"line_number":334,"context_line":"* if shared_host_connection_attachments\u003e0, call os-brick to check connection"},{"line_number":335,"context_line":"* if the connection fails, delete the attachment, and fail the operation"},{"line_number":336,"context_line":"* Release the shared_host_connection lock"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_302c8c98","line":334,"range":{"start_line":334,"start_character":43,"end_line":334,"end_character":76},"updated":"2016-11-11 09:42:02.000000000","message":"+1 but it might end up being a noop to begin with while os-brick implements this check for the various shared backends.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":355,"context_line":"* attach volume to server"},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"Note this is no different for attach vs multi-attach, except for correctly"},{"line_number":358,"context_line":"tell the hypervisor about multi-attach."},{"line_number":359,"context_line":""},{"line_number":360,"context_line":"Consider the detach:"},{"line_number":361,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_d06190d4","line":358,"range":{"start_line":358,"start_character":4,"end_line":358,"end_character":5},"updated":"2016-11-11 09:42:02.000000000","message":"ing","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":486,"context_line":"Should there be a rollback of the live-migration for some reason, then instead"},{"line_number":487,"context_line":"of disconnecting the volume attachment on the source, we need to disconnect"},{"line_number":488,"context_line":"the volume attachment on the destination node. This follow the same process as"},{"line_number":489,"context_line":"above except with the new_attachment_uuid instead of the old_attachment_uuid."},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"Things to note:"},{"line_number":492,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_3bc2ade9","line":489,"range":{"start_line":489,"start_character":22,"end_line":489,"end_character":25},"updated":"2016-11-11 09:42:02.000000000","message":"dest?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":486,"context_line":"Should there be a rollback of the live-migration for some reason, then instead"},{"line_number":487,"context_line":"of disconnecting the volume attachment on the source, we need to disconnect"},{"line_number":488,"context_line":"the volume attachment on the destination node. This follow the same process as"},{"line_number":489,"context_line":"above except with the new_attachment_uuid instead of the old_attachment_uuid."},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"Things to note:"},{"line_number":492,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_bbaebd2b","line":489,"range":{"start_line":489,"start_character":57,"end_line":489,"end_character":60},"updated":"2016-11-11 09:42:02.000000000","message":"src?","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":486,"context_line":"Should there be a rollback of the live-migration for some reason, then instead"},{"line_number":487,"context_line":"of disconnecting the volume attachment on the source, we need to disconnect"},{"line_number":488,"context_line":"the volume attachment on the destination node. This follow the same process as"},{"line_number":489,"context_line":"above except with the new_attachment_uuid instead of the old_attachment_uuid."},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"Things to note:"},{"line_number":492,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_3a0fc0e2","line":489,"range":{"start_line":489,"start_character":57,"end_line":489,"end_character":60},"in_reply_to":"9a629dbe_bbaebd2b","updated":"2016-11-15 09:33:51.000000000","message":"Was keeping old and new to be consistent with he bullet points above.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7df3d196639e43fec84815d25c6b80db8c81a637","unresolved":false,"context_lines":[{"line_number":505,"context_line":"--------"},{"line_number":506,"context_line":""},{"line_number":507,"context_line":"* Add a new attachment for the new host"},{"line_number":508,"context_line":"* Attachment on the old host should be put into a error state"},{"line_number":509,"context_line":"* If the old compute node starts up, it detects attachments in the"},{"line_number":510,"context_line":"  error state, and completes the disconnection"},{"line_number":511,"context_line":"* Should the node never be brought back up, the admin can do a force detach"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9a629dbe_7b14254c","line":508,"range":{"start_line":508,"start_character":2,"end_line":508,"end_character":61},"updated":"2016-11-11 09:42:02.000000000","message":"Again note that we don\u0027t have the old connector details at this point.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ab1e51ffd14c78511b72da68bed9f703453bcff4","unresolved":false,"context_lines":[{"line_number":505,"context_line":"--------"},{"line_number":506,"context_line":""},{"line_number":507,"context_line":"* Add a new attachment for the new host"},{"line_number":508,"context_line":"* Attachment on the old host should be put into a error state"},{"line_number":509,"context_line":"* If the old compute node starts up, it detects attachments in the"},{"line_number":510,"context_line":"  error state, and completes the disconnection"},{"line_number":511,"context_line":"* Should the node never be brought back up, the admin can do a force detach"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_1a3124a3","line":508,"range":{"start_line":508,"start_character":2,"end_line":508,"end_character":61},"in_reply_to":"9a629dbe_7b14254c","updated":"2016-11-15 09:33:51.000000000","message":"Correct, and that should be fine using this new flow. You just need the attachment_uuid. I should make that clearer above.","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"d19cef2a9691a581e3da2d1e8f69e637d4439bec","unresolved":false,"context_lines":[{"line_number":549,"context_line":""},{"line_number":550,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":551,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":552,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":553,"context_line":""},{"line_number":554,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":555,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":12,"id":"7a77a97e_40257fc0","line":552,"updated":"2016-11-14 22:49:26.000000000","message":"I really have very little understanding of what\u0027s going on with this stuff, but this sentence above sounds very reassuring and calming compared with everything else.\n\nOr to put it another way: storing only an identifier++","commit_id":"a20a43dfcba1b8958ee752852c5f4e5015f022b5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":33,"context_line":"The main API actions to consider are:"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* Attach a volume to an instance, including during spawning an instance,"},{"line_number":36,"context_line":"  and calling os-brick to possibly connect the volume to the hypervisor."},{"line_number":37,"context_line":"* Detach volume from an instance, including calling os-brick to possibly"},{"line_number":38,"context_line":"  disconnect the volume from the hypervisor host."},{"line_number":39,"context_line":"* Live-migrate an instance, involves setting up the volume connection on the"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_2c570e27","line":36,"range":{"start_line":36,"start_character":26,"end_line":36,"end_character":34},"updated":"2016-12-05 17:05:38.000000000","message":"nit: I\u0027m not sure why this says \u0027possibly\u0027 here and below, are there cases where we attach a volume to an instance but don\u0027t actually mount it?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":45,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":46,"context_line":"  old connection, and attach the volume on the new host."},{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of an instance (only when instance is powered off)"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_4c2b6a94","line":48,"range":{"start_line":48,"start_character":23,"end_line":48,"end_character":27},"updated":"2016-12-05 17:05:38.000000000","message":"from","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":47,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":48,"context_line":"  we need to detach it form the host when the instance is offloaded."},{"line_number":49,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":50,"context_line":"* Detach the root volume of an instance (only when instance is powered off)"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In particular, please note:"},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_27b8072a","line":50,"updated":"2016-12-05 17:05:38.000000000","message":"I guess this is referring to the use case here?\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/detach-boot-volume.html\n\nJust wondering since ^ isn\u0027t all merged yet.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":69,"context_line":"Proposed change"},{"line_number":70,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The main change here is we making a very clear contract between"},{"line_number":73,"context_line":"Nova and Cinder, that is well understood by both sides."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"One other big change between the new API flow and the old API flow"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_07ddcb6e","line":72,"range":{"start_line":72,"start_character":24,"end_line":72,"end_character":26},"updated":"2016-12-05 17:05:38.000000000","message":"we are","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments ::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"    {\"attachment\": {"},{"line_number":99,"context_line":"      \"server_uuid\": \"\u003cserver_uuid\u003e\","},{"line_number":100,"context_line":"      [\"host_uuid\": \"...\", \"connector\": {...}]"},{"line_number":101,"context_line":"    }}"},{"line_number":102,"context_line":"    {\"attachment\": {"},{"line_number":103,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","},{"line_number":104,"context_line":"      \"status\": \"attaching\""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_a7a97792","line":101,"range":{"start_line":98,"start_character":4,"end_line":101,"end_character":6},"updated":"2016-12-05 17:05:38.000000000","message":"So this is the request - we know that host and connector can be null or not provided right? Today when attaching a volume (not boot from volume), nova calls the reserve cinder API, at which point we don\u0027t have the connector from os-brick. We\u0027d have the server id and for a pre-existing server we\u0027d have the host I guess for the host the server is running on.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  the host_uuid\u0027s could be None/null (see retry during spawn)."},{"line_number":119,"context_line":"* Note: again we assume cinder ensures there are never two attachments"},{"line_number":120,"context_line":"  with the same host_uuid and server_uuid for this volume."},{"line_number":121,"context_line":"* Volume moves into the \"inuse\" state (TODO - no agreement on this)"},{"line_number":122,"context_line":"* If no host_uuid and connector given, attachment goes into \"attaching\" state"},{"line_number":123,"context_line":"* If host_uuid and connector are given, attahment goes into \"in-use\" state,"},{"line_number":124,"context_line":"  and returns valid conenction_info that can be passed to os-brick"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_c79cb35f","line":121,"range":{"start_line":121,"start_character":25,"end_line":121,"end_character":30},"updated":"2016-12-05 17:05:38.000000000","message":"nit: in-use","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  with the same host_uuid and server_uuid for this volume."},{"line_number":121,"context_line":"* Volume moves into the \"inuse\" state (TODO - no agreement on this)"},{"line_number":122,"context_line":"* If no host_uuid and connector given, attachment goes into \"attaching\" state"},{"line_number":123,"context_line":"* If host_uuid and connector are given, attahment goes into \"in-use\" state,"},{"line_number":124,"context_line":"  and returns valid conenction_info that can be passed to os-brick"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::"},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_271f27b8","line":124,"range":{"start_line":123,"start_character":2,"end_line":124,"end_character":66},"updated":"2016-12-05 17:05:38.000000000","message":"Is this update_attachment or create_attachment, or both? I\u0027m still a bit worried about marking the volume in-use before we actually connect it on the host, but not sure what we can do about it without having a callback \u0027ack\u0027 from nova to cinder like we have with the existing os-detach cinder API call that nova makes after connecting the volume via os-brick. I do worry about things like Tempest that are polling until the volume goes to in-use and then tries to ssh into the guest to read the partitions and verify the volume is mounted...\n\n--\n\nsmcginnis also brought up the idea of setting a task_state on the instance when we\u0027re attaching a volume, which we don\u0027t do today, but I\u0027m not sure why, I guess because the volume service started in nova and you could just track the status on the volume while it was being attached, but that is changing semantically here, so maybe we need a task state transition on the instance now for this flow.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":123,"context_line":"* If host_uuid and connector are given, attahment goes into \"in-use\" state,"},{"line_number":124,"context_line":"  and returns valid conenction_info that can be passed to os-brick"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"    {\"attachment\": {"},{"line_number":129,"context_line":"      \"host_uuid\": \"\u003chost_uuid\u003e\","}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_47734315","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":4},"updated":"2016-12-05 17:05:38.000000000","message":"PUT? This is update_attachment right?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"POST volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e ::"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"    {\"attachment\": {"},{"line_number":129,"context_line":"      \"host_uuid\": \"\u003chost_uuid\u003e\","},{"line_number":130,"context_line":"      \"connector\": \"\u003cfoo\u003e\"}}"},{"line_number":131,"context_line":"    {\"attachment\": {"},{"line_number":132,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","},{"line_number":133,"context_line":"      \"status\": \"in-use\""},{"line_number":134,"context_line":"      \"connection_info\": {...},"},{"line_number":135,"context_line":"      ..."},{"line_number":136,"context_line":"    }}"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* This is called from the nova-compute node, to update the host_uuid and"},{"line_number":139,"context_line":"  connector. The connector generally comes from os-brick."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_a7cfb727","line":136,"range":{"start_line":128,"start_character":4,"end_line":136,"end_character":6},"updated":"2016-12-05 17:05:38.000000000","message":"nit: label which is the request and which is the response","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* This is called from the nova-compute node, to update the host_uuid and"},{"line_number":139,"context_line":"  connector. The connector generally comes from os-brick."},{"line_number":140,"context_line":"* When these properties are set, Cinder works with the backend to get"},{"line_number":141,"context_line":"  the connection_info that needs to be passed to os-brick, and returns"},{"line_number":142,"context_line":"  that in the attachment document."},{"line_number":143,"context_line":"* This call can also used to set the attachment status to \"error\"."},{"line_number":144,"context_line":"  When used for that purpose, you would send a document like this ::"},{"line_number":145,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_87c39bec","line":142,"range":{"start_line":140,"start_character":2,"end_line":142,"end_character":34},"updated":"2016-12-05 17:05:38.000000000","message":"Might be worth calling out, this is what os-initialize_connection would be used for today. I think it\u0027s worth noting in this doc which existing things are getting replaced in here in the new parts that are laid out.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":140,"context_line":"* When these properties are set, Cinder works with the backend to get"},{"line_number":141,"context_line":"  the connection_info that needs to be passed to os-brick, and returns"},{"line_number":142,"context_line":"  that in the attachment document."},{"line_number":143,"context_line":"* This call can also used to set the attachment status to \"error\"."},{"line_number":144,"context_line":"  When used for that purpose, you would send a document like this ::"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"    {\"attachment\": {\"status\": \"error\"}"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_07b06b89","line":143,"range":{"start_line":143,"start_character":21,"end_line":143,"end_character":25},"updated":"2016-12-05 17:05:38.000000000","message":"be used","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":143,"context_line":"* This call can also used to set the attachment status to \"error\"."},{"line_number":144,"context_line":"  When used for that purpose, you would send a document like this ::"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"    {\"attachment\": {\"status\": \"error\"}"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"  An example of when to set the status to error is when you are unable"},{"line_number":149,"context_line":"  to successfully disconnect the host connection to the volume backend."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_075eab43","line":146,"updated":"2016-12-05 17:05:38.000000000","message":"It seems really weird to me that nova can change the status on an attachment like this...why wouldn\u0027t nova just delete the attachment?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":148,"context_line":"  An example of when to set the status to error is when you are unable"},{"line_number":149,"context_line":"  to successfully disconnect the host connection to the volume backend."},{"line_number":150,"context_line":"  When this is done, note that the cinder backend should do similar cleanup"},{"line_number":151,"context_line":"  to when the volume is deleted, and that volume no longer reserves the volume"},{"line_number":152,"context_line":"  for the associated server_uuid, and it no longer counts towards the list of"},{"line_number":153,"context_line":"  attachments that share a host connection. It is only here so its clear there"},{"line_number":154,"context_line":"  may be something on the associated host that will need manual cleanup, or a"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_27056713","line":151,"range":{"start_line":151,"start_character":42,"end_line":151,"end_character":48},"updated":"2016-12-05 17:05:38.000000000","message":"attachment?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":157,"context_line":"  of the host connection to the cinder backend."},{"line_number":158,"context_line":"* Once a volume is in the in-use state, the only allowed change is to the"},{"line_number":159,"context_line":"  status"},{"line_number":160,"context_line":"* Note: because there is no acknowledgment that the host connection succeeded,"},{"line_number":161,"context_line":"  Nova is responsible for ensuring the connection is correctly used or removed"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e?show_connection_info\u003dtrue"},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_22e63544","line":161,"range":{"start_line":160,"start_character":2,"end_line":161,"end_character":78},"updated":"2016-12-05 17:05:38.000000000","message":"Yeah today nova calls the cinder os-attach API to change the status on the volume to \u0027in-use\u0027, we no longer have that, as noted above, and could have race issues where the volume isn\u0027t actually connected yet.\n\nThinking at a higher level, let\u0027s say we call update_attachment and provide the host and connector, cinder returns the connection_info and marks the volume as in-use, but then we fail to connect the volume via os-brick. The volume status would be going from attaching, to in-use, then to error, which would be a bit weird. What does the user do at that point? Detach the volume? I\u0027d think nova would do that cleanup automatically.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":160,"context_line":"* Note: because there is no acknowledgment that the host connection succeeded,"},{"line_number":161,"context_line":"  Nova is responsible for ensuring the connection is correctly used or removed"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e?show_connection_info\u003dtrue"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"* When deleting an attachment, Nova uses this API to get the connection_info"},{"line_number":166,"context_line":"  needed to call os-bricks disconnect, or similar."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_826549b6","line":163,"range":{"start_line":163,"start_character":45,"end_line":163,"end_character":70},"updated":"2016-12-05 17:05:38.000000000","message":"Why not just have nova do the GET on the attachment and get this detail there? Seems simpler than having a special query parameter for this.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* Nova calls this to tell Cinder the volume has been successfully disconnected"},{"line_number":174,"context_line":"  from both the server and the host (if required, see shared connections)."},{"line_number":175,"context_line":"* Should os-brick fail to attach the host connection, this is also called"},{"line_number":176,"context_line":"* Should os-brick fail to remove the host connection DELETE is not used, the"},{"line_number":177,"context_line":"  attachment update call is used to put the attachment into an error state."},{"line_number":178,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_820c69ee","line":175,"range":{"start_line":175,"start_character":2,"end_line":175,"end_character":73},"updated":"2016-12-05 17:05:38.000000000","message":"This is conflicting with the above statements about nova setting the attachment status to error if the host connection fails in os-brick. But this is really what I\u0027d think we\u0027d do rather than nova mucking with the attachment status.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":178,"context_line":""},{"line_number":179,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"* Lists all the active attachment_uuids for the given volume."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"TODO: GET attachments/?host_uuid\u003d\"\u003cuuid\u003e\"\u0026status\u003d\"error\""},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_62bcaddc","line":181,"range":{"start_line":181,"start_character":23,"end_line":181,"end_character":39},"updated":"2016-12-05 17:05:38.000000000","message":"Returns a list of attachment uuids or attachment objects? I\u0027d think the latter.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":183,"context_line":"TODO: GET attachments/?host_uuid\u003d\"\u003cuuid\u003e\"\u0026status\u003d\"error\""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"* To recover from evacuate, Nova wants to know all the attachments related"},{"line_number":186,"context_line":"  to the given host, that are in the error state. This means the detach"},{"line_number":187,"context_line":"  operation can be retried, and if successful, the attachment can be deleted."},{"line_number":188,"context_line":"* When nova-compute starts up, we could check with os-brick to ensure all the"},{"line_number":189,"context_line":"  host connections are correctly present, and there are no missing connections"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_e297dd45","line":186,"range":{"start_line":186,"start_character":21,"end_line":186,"end_character":48},"updated":"2016-12-05 17:05:38.000000000","message":"Do they need to be in the error state? If they are attachments on a failed host don\u0027t we just assume they are dead and we need to clean them up?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":204,"context_line":"Transition to new flow"},{"line_number":205,"context_line":"----------------------"},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"When starting up we check the Cinder API microversion and cache that until"},{"line_number":208,"context_line":"the service is restarted. Based on the cached Cinder microversion, we use"},{"line_number":209,"context_line":"either the existing Cinder interaction model, or the new interaction model."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"In two cycles time, support for the old interaction model should be removed"},{"line_number":212,"context_line":"from Nova. We should keep this in mind in how the code is structured."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_22763506","line":209,"range":{"start_line":207,"start_character":0,"end_line":209,"end_character":75},"updated":"2016-12-05 17:05:38.000000000","message":"It\u0027s not only the cinder microversion available, but if the computes are new enough to have the code to handle the new flow. For example, if we have an instance on a newton host and we attach a volume to it, we can\u0027t use the new create_attachment API because the compute will try to use os-initialize_connection and os-attach, rather than update_attachment. So from the API POV, it\u0027s really (1) minimum cinder microversion and (2) minimum nova-compute service version.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":208,"context_line":"the service is restarted. Based on the cached Cinder microversion, we use"},{"line_number":209,"context_line":"either the existing Cinder interaction model, or the new interaction model."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"In two cycles time, support for the old interaction model should be removed"},{"line_number":212,"context_line":"from Nova. We should keep this in mind in how the code is structured."},{"line_number":213,"context_line":"This complexity should be hidden behind the volume_api."},{"line_number":214,"context_line":"Note this will mean a hard dependency between Nova and having a version of"},{"line_number":215,"context_line":"Cinder installed that supports this new flow."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":218,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_22e475aa","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":45},"updated":"2016-12-05 17:05:38.000000000","message":"Again, you could have an instance booted in kilo that hasn\u0027t been updated in forever, with a volume attached to it, the connection_info will be in the nova bdm and we have to migrate that data so that if we ever need to detach that volume it\u0027s going to work with the new flow. I\u0027m assuming there is something later in this spec about doing the online data migrations.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":214,"context_line":"Note this will mean a hard dependency between Nova and having a version of"},{"line_number":215,"context_line":"Cinder installed that supports this new flow."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":218,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":219,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":220,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_82f54958","line":217,"range":{"start_line":217,"start_character":0,"end_line":217,"end_character":4},"updated":"2016-12-05 17:05:38.000000000","message":"There","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":215,"context_line":"Cinder installed that supports this new flow."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":218,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":219,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":220,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":221,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":222,"context_line":"the Ocata timeframe, so we release with the new workflow on by default."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"When upgrading, no servers will use the new flow until all api and compute"},{"line_number":225,"context_line":"nodes are upgraded. We can check this by inspecting the min service version."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_a2b40582","line":222,"range":{"start_line":218,"start_character":0,"end_line":222,"end_character":71},"updated":"2016-12-05 17:05:38.000000000","message":"I\u0027m not sure why we need config options for this. Can\u0027t we just handle the code path logic based on what\u0027s noted above, i.e. cinder microversion and minimum nova-compute service version?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":234,"context_line":"To allow us to remove the old flow, we want to transition all existing volume"},{"line_number":235,"context_line":"attachments over to the new flow. This involves telling Cinder about the"},{"line_number":236,"context_line":"connection info that is stored in the BDM, so Cinder now has this info, and"},{"line_number":237,"context_line":"create the attachment id in the Cinder database. This will be a nova-manage"},{"line_number":238,"context_line":"cmd that sends the info to an upgraded cinder-manager cmd. The returned"},{"line_number":239,"context_line":"attachment id is put into the BDM to tell Nova that all future operations"},{"line_number":240,"context_line":"(like detach) should now use the new flow. Cinder is responsible for ensuring"},{"line_number":241,"context_line":"you can still use the old flow when the new flow has been activated, so there"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_48c35389","line":238,"range":{"start_line":237,"start_character":49,"end_line":238,"end_character":58},"updated":"2016-12-05 17:05:38.000000000","message":"nova-manage is going to call a cinder-manage CLI? That seems odd, we don\u0027t have a Cinder API we can use?\n\nCouldn\u0027t nova create an attachment in cinder passing the server id and host id? The tricky part would be the connection_info and connector. We started storing the connector in the connection_info in the bdm in I think newton (and backported that to mitaka), but it\u0027s not there for all existing attachments created before that. But nova has the connection_info, could we update the attachment with that, or pass it in when creating the attachment and then maybe cinder would know, this is an existing attachment, take some special action, don\u0027t do new things on it, we\u0027re just tracking it. The missing piece would be the connector, which we\u0027d have to get from nova-compute...which would mean doing an RPC call to the compute from nova-manage which is kind of gross.\n\nI\u0027m wondering if there are other ways we can \u0027heal\u0027 this information outside of nova-manage, like with a periodic task in the computes themselves.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ddf12dcc15f7cb5c426f22a0b84e80dcf73651d1","unresolved":false,"context_lines":[{"line_number":234,"context_line":"To allow us to remove the old flow, we want to transition all existing volume"},{"line_number":235,"context_line":"attachments over to the new flow. This involves telling Cinder about the"},{"line_number":236,"context_line":"connection info that is stored in the BDM, so Cinder now has this info, and"},{"line_number":237,"context_line":"create the attachment id in the Cinder database. This will be a nova-manage"},{"line_number":238,"context_line":"cmd that sends the info to an upgraded cinder-manager cmd. The returned"},{"line_number":239,"context_line":"attachment id is put into the BDM to tell Nova that all future operations"},{"line_number":240,"context_line":"(like detach) should now use the new flow. Cinder is responsible for ensuring"},{"line_number":241,"context_line":"you can still use the old flow when the new flow has been activated, so there"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_d7953a33","line":238,"range":{"start_line":237,"start_character":49,"end_line":238,"end_character":58},"in_reply_to":"3a71b18c_48c35389","updated":"2016-12-05 17:49:38.000000000","message":"During the nova/cinder meeting today hemna pointed out there is already a volume_attachments table in cinder which stores the instance_uuid. I think he thinks the new cinder APIs are going to use this existing data for the new flow, but I\u0027m not entirely sure that jgriffith is on board with that. I think either way it means existing attachments have something stored in cinder, and nova just needs to call \u0027update_attachment\u0027 on them and pass the connector so cinder can start storing that for a later detach via delete_attachment.\n\nSo I think the migration/upgrade process is really just a periodic task in the compute manager that queries the database for all BDMs associated with an instance on CONF.host where volume_id is not None and BDM.attachment_id is None, and then (1) get the connector from brick, (2) update the attachment in cinder, which stores the connector and refreshes the connection_info (and stores it in cinder), and then (3) nova drops the BDM.connection_info and sets the BDM.attachment_id which essentially takes it out of the loop. We could handle 1 bdm per periodic task iteration, like the _heal_instance_info_cache periodic task does.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":248,"context_line":"there is a shared connection to the volume backend, but this is covered in"},{"line_number":249,"context_line":"a later section. Lets first consider when it is not a shared connection:"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"* attach_uuid \u003d create_attachment(s1)"},{"line_number":252,"context_line":"* save attachment_uuid in BDM"},{"line_number":253,"context_line":"* once we land on the chosen host, h1, we continue"},{"line_number":254,"context_line":"* con \u003d osbrick.get_connector()"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_c895a333","line":251,"updated":"2016-12-05 17:05:38.000000000","message":"nit: maybe prefix each step with where it happens, i.e. \n\n (nova-api) attach_uuid \u003d create_attachment(s1)\n (nova-api) save attachment_uuid in BDM\n (nova-compute) con \u003d osbrick.get_connector()\n ..","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c14cb9a966dff3117f591bd03c549d760367f41f","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  server_uuid, to ensure the volume stays reserved to this server_uuid, and"},{"line_number":277,"context_line":"  we update the BDM with the new attachment_id."},{"line_number":278,"context_line":"  Then we follow the full detach process for the old host, and delete the"},{"line_number":279,"context_line":"  original detachment. This may seem excessive, but this full detach process"},{"line_number":280,"context_line":"  is needed due to issues with shared connections, see below."},{"line_number":281,"context_line":"* should os-brick fail to connect, we call delete_attachment(attachment_uuid)"},{"line_number":282,"context_line":"  and fail the build on this host (we could retry on another host)."}],"source_content_type":"text/x-rst","patch_set":13,"id":"7a77a97e_9aac5437","line":279,"range":{"start_line":279,"start_character":11,"end_line":279,"end_character":21},"updated":"2016-11-21 17:40:11.000000000","message":"attachment","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c14cb9a966dff3117f591bd03c549d760367f41f","unresolved":false,"context_lines":[{"line_number":270,"context_line":""},{"line_number":271,"context_line":"Interesting edge cases:"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* should we fail to boot, after having updated the volume attachment with"},{"line_number":274,"context_line":"  the host, the retry on a new host counts as a move."},{"line_number":275,"context_line":"  So we first create a new attachment with an empty host_uuid, but the same"},{"line_number":276,"context_line":"  server_uuid, to ensure the volume stays reserved to this server_uuid, and"},{"line_number":277,"context_line":"  we update the BDM with the new attachment_id."},{"line_number":278,"context_line":"  Then we follow the full detach process for the old host, and delete the"},{"line_number":279,"context_line":"  original detachment. This may seem excessive, but this full detach process"},{"line_number":280,"context_line":"  is needed due to issues with shared connections, see below."},{"line_number":281,"context_line":"* should os-brick fail to connect, we call delete_attachment(attachment_uuid)"},{"line_number":282,"context_line":"  and fail the build on this host (we could retry on another host)."},{"line_number":283,"context_line":"* should the call to os-brick to disconnect fail, we should put the"}],"source_content_type":"text/x-rst","patch_set":13,"id":"7a77a97e_7512295a","line":280,"range":{"start_line":273,"start_character":2,"end_line":280,"end_character":61},"updated":"2016-11-21 17:40:11.000000000","message":"I\u0027m not crazy about this but I haven\u0027t read the rest of the spec yet for full context. But I thought we\u0027d have nova-api create the attachment and stash the id on the BDM. The attachment is one per volume/instance combination, like ports. So with ports we update the port with the host binding details on the compute, and don\u0027t mess with that between retries, until we\u0027re done retrying and we deallocate (unbind or delete) the port. I was thinking similar with vol attachments, we\u0027d have one for the vol/instance during the build, but we\u0027re updating it\u0027s connector information per host. On the last host if we still fail we detach/delete the attachment. But then nova-compute doesn\u0027t need to be messing with creating attachments in the api and compute, and making sure it\u0027s cleaning everything up in between.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":280,"context_line":"  is needed due to issues with shared connections, see below."},{"line_number":281,"context_line":"* should os-brick fail to connect, we call delete_attachment(attachment_uuid)"},{"line_number":282,"context_line":"  and fail the build on this host (we could retry on another host)."},{"line_number":283,"context_line":"* should the call to os-brick to disconnect fail, we should put the"},{"line_number":284,"context_line":"  attachment into an \"error\" state. The delete should not fail, but it allows"},{"line_number":285,"context_line":"  the administrator to clean up any failed detach, as required."},{"line_number":286,"context_line":""},{"line_number":287,"context_line":"Shared Host Connections"},{"line_number":288,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_eba259fb","line":285,"range":{"start_line":283,"start_character":2,"end_line":285,"end_character":63},"updated":"2016-12-05 17:05:38.000000000","message":"I still don\u0027t like nova touching the state on the vol attachment. If we\u0027re just looking to signal that something is hosed and requires manual admin intervention, then I\u0027d think nova can put the instance into error state and put a fault on it.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":287,"context_line":"Shared Host Connections"},{"line_number":288,"context_line":"-----------------------"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"When you have volume backends that use a single host connection to server"},{"line_number":291,"context_line":"multiple volume connections on each host, you get something like this ::"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"                 +-------------------+"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_2bb1b147","line":290,"range":{"start_line":290,"start_character":67,"end_line":290,"end_character":73},"updated":"2016-12-05 17:05:38.000000000","message":"serve","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":324,"context_line":"connection is shared or not, and also says how many attachments currently"},{"line_number":325,"context_line":"share the same connection. It could look something like this:"},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"GET volumes/\u003cvolume_uuid\u003e/attachments/\u003cuuid\u003e?show_connection_info\u003dtrue ::"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"    {\"attachment\": {"},{"line_number":330,"context_line":"      \"uuid\": \"\u003cattachment_uuid\u003e\","}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_2b745166","line":327,"range":{"start_line":327,"start_character":45,"end_line":327,"end_character":65},"updated":"2016-12-05 17:05:38.000000000","message":"Why do we need this? Shouldn\u0027t we always get it when doing a GET on vol attachment details?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":335,"context_line":"      ..."},{"line_number":336,"context_line":"    }}"},{"line_number":337,"context_line":""},{"line_number":338,"context_line":"When a connection is shared, we must hold a lock on the compute host to"},{"line_number":339,"context_line":"ensure no other shared connection operations happen at the same time."},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"For attach, if shared_host_connection\u003dTrue:"},{"line_number":342,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_8b1565e6","line":339,"range":{"start_line":338,"start_character":0,"end_line":339,"end_character":69},"updated":"2016-12-05 17:05:38.000000000","message":"Is this per-host? Because if not, we can still have a problem as we don\u0027t have an external DLM so we could lock on host A but couldn\u0027t we be connecting to the same shared backed on host B? I\u0027m totally throwing random things out here as I don\u0027t know the rules around shared connections with cinder backends.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":343,"context_line":"* Acquire the shared_host_connection lock"},{"line_number":344,"context_line":"* Set the host_uuid and connector to make the attachment into \"in-use\" state"},{"line_number":345,"context_line":"* if shared_host_connection_attachments\u003d0, call os-brick to connect"},{"line_number":346,"context_line":"* if shared_host_connection_attachments\u003e0, call os-brick to check connection"},{"line_number":347,"context_line":"* if the connection fails, delete the attachment, and fail the operation"},{"line_number":348,"context_line":"* Release the shared_host_connection lock"},{"line_number":349,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_eb57b957","line":346,"range":{"start_line":346,"start_character":60,"end_line":346,"end_character":76},"updated":"2016-12-05 17:05:38.000000000","message":"What does this do? Just check that the shared connection is still OK?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":352,"context_line":"* Acquire the shared_host_connection lock"},{"line_number":353,"context_line":"* Get a fresh copy of the attachment document from Cinder"},{"line_number":354,"context_line":"* if shared_host_connection_attachments\u003d0, call os-brick to disconnect"},{"line_number":355,"context_line":"* if disconnect failed, but the attachment into the error state"},{"line_number":356,"context_line":"* if disconnect worked, delete the attachment"},{"line_number":357,"context_line":"* Release the shared_host_connection lock"},{"line_number":358,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_abc86123","line":355,"range":{"start_line":355,"start_character":24,"end_line":355,"end_character":27},"updated":"2016-12-05 17:05:38.000000000","message":"put","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":360,"context_line":"------------------------"},{"line_number":361,"context_line":""},{"line_number":362,"context_line":"Consider attach with server_uuid\u003ds1 on host_uuid\u003dh1"},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":365,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh1, con)"},{"line_number":366,"context_line":"* talk to os-brick to do what is needed on the host"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_2bb29194","line":363,"updated":"2016-12-05 17:05:38.000000000","message":"You skipped the parts that happen in nova-api here, but we\u0027d create the attachment from nova-api right? And we\u0027d do that by passing the server and host ids?\n\n\u003clater\u003e\n\nOh I see below we create the attachment on the host, why don\u0027t we do that in the API to be the same as boot from volume? If we want to be similar to the existing flow, we want to create the attachment from the nova-api service to essentially \u0027reserve\u0027 the volume while attaching.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":372,"context_line":"Consider the detach:"},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"* First attempt to hot unplug the volume from the VM"},{"line_number":375,"context_line":"* If this fails, we should fail the operation, i.e. don\u0027t delete attachment."},{"line_number":376,"context_line":"* connection_info \u003d get_attachment_info(attachment_uuid)"},{"line_number":377,"context_line":"* call os-brick to do the detach, if required, in the usual way"},{"line_number":378,"context_line":"* delete_attachment(attachment_uuid)"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_ab32210e","line":375,"updated":"2016-12-05 17:05:38.000000000","message":"Do we put the instance into error state?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":377,"context_line":"* call os-brick to do the detach, if required, in the usual way"},{"line_number":378,"context_line":"* delete_attachment(attachment_uuid)"},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"Note: there is little difference with boot in terms of API calls to Cinder."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Live-migrate"},{"line_number":383,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_6b048917","line":380,"updated":"2016-12-05 17:05:38.000000000","message":"Except for the question above about creating the attachment from the compute rather than the API.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":472,"context_line":"happen during the pre-live-migration-at-destination (where source is h1 and"},{"line_number":473,"context_line":"destination is h2, and the server uuid is s1) we have something like this:"},{"line_number":474,"context_line":""},{"line_number":475,"context_line":"* Part of pre_live_migration_at_destination"},{"line_number":476,"context_line":"* con \u003d osbrick.get_connector()"},{"line_number":477,"context_line":"* connection_info \u003d create_attachment(s1, host_uuid\u003dh2, con)"},{"line_number":478,"context_line":"* this is allowed, even if multi-attach\u003dfalse, because the server uuid of s1"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_4edc3b73","line":475,"updated":"2016-12-05 17:05:38.000000000","message":"Again, it would be useful to prefix where these calls happen from, e.g. (compute h2) Part of pre_live_migration_at_destination","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":479,"context_line":"  matches the existing attachment and the host_uuid is different to the"},{"line_number":480,"context_line":"  existing attachment"},{"line_number":481,"context_line":"* save attachment_uuid in BDM as destination attachment_uuid"},{"line_number":482,"context_line":"* talk to os-brick to connect to the host, in the way that tasks into account"},{"line_number":483,"context_line":"  shared host connections"},{"line_number":484,"context_line":"* pass the correct XML to the live-migrate cmd to attach to the new connection"},{"line_number":485,"context_line":"  on the destination host"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_eec7c795","line":482,"range":{"start_line":482,"start_character":59,"end_line":482,"end_character":64},"updated":"2016-12-05 17:05:38.000000000","message":"takes","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":488,"context_line":"source host, and will now only be used on the destination host. To disconnect"},{"line_number":489,"context_line":"the volume from the source host, we have to do this:"},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"* Part of post-live-migration on source host"},{"line_number":492,"context_line":"* connection_info \u003d get_attachment_info(old_attachment_uuid)"},{"line_number":493,"context_line":"* call to os-brick to do what is needed to disconnect the host from the volume"},{"line_number":494,"context_line":"  backend, in the way that takes account of shared host connections."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_ae386fa1","line":491,"updated":"2016-12-05 17:05:38.000000000","message":"(compute h1) prefix","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":493,"context_line":"* call to os-brick to do what is needed to disconnect the host from the volume"},{"line_number":494,"context_line":"  backend, in the way that takes account of shared host connections."},{"line_number":495,"context_line":"* delete_attachment(old_attachment_uuid)"},{"line_number":496,"context_line":"* If there was an error, put the old_attachment_uuid into the error state"},{"line_number":497,"context_line":""},{"line_number":498,"context_line":"Should there be a rollback of the live-migration for some reason, then instead"},{"line_number":499,"context_line":"of disconnecting the volume attachment on the source, we need to disconnect"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_8e6733b6","line":496,"updated":"2016-12-05 17:05:38.000000000","message":"Hmm, this seems wonky. Why wouldn\u0027t we consider the live migration a failure and rollback?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":503,"context_line":""},{"line_number":504,"context_line":"Things to note:"},{"line_number":505,"context_line":""},{"line_number":506,"context_line":"* BDM stores an attachment id for the source and destination host"},{"line_number":507,"context_line":"  while the live-migration is in process."},{"line_number":508,"context_line":"* We are back to having just the one attachment for the given server uuid"},{"line_number":509,"context_line":""},{"line_number":510,"context_line":"Migrate"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_6ec65769","line":507,"range":{"start_line":506,"start_character":2,"end_line":507,"end_character":41},"updated":"2016-12-05 17:05:38.000000000","message":"So above when we talked about storing the attachment_id in the BDM, is that really like active_attachment_id? I\u0027m just wondering what the fields are going to be for the BDM with the attachments, we could have source/target_attachment_ids in the BDMs, but those leak migration details a bit. And if you never live migration the VM, then the attachment ID is always stored in source_attachment_id or something, so I\u0027d think maybe calling it active_attachment_id and inactive_attachment_id and then swapping them later during live migration would make more sense, but it\u0027s not great either. I\u0027m not really sure, just thinking out loud.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":512,"context_line":""},{"line_number":513,"context_line":"Similar to live-migrate, at the start of the migration we have attachments"},{"line_number":514,"context_line":"for both the source and destination node. On calling confirm resize we do"},{"line_number":515,"context_line":"a detach on source, a call to revert resize and its detach on destination."},{"line_number":516,"context_line":""},{"line_number":517,"context_line":"Evacuate"},{"line_number":518,"context_line":"--------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_cebccbbd","line":515,"range":{"start_line":515,"start_character":20,"end_line":515,"end_character":43},"updated":"2016-12-05 17:05:38.000000000","message":"hmm? why revert the resize when we\u0027re confirming the resize?","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":521,"context_line":"* Attachment on the old host should be put into a error state, the"},{"line_number":522,"context_line":"  attachment_uuid is stored in the BDM (or can be found by listing all the"},{"line_number":523,"context_line":"  attachments for the affected volumes)."},{"line_number":524,"context_line":"* If the old compute node starts up, it detects attachments in the"},{"line_number":525,"context_line":"  error state, and completes the disconnection"},{"line_number":526,"context_line":"* Should the node never be brought back up, the admin can do a force detach"},{"line_number":527,"context_line":"  on all relevant volume attachments"},{"line_number":528,"context_line":"* Note that attachments in the error state do not reserver a volume for"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_8e49f3b9","line":525,"range":{"start_line":524,"start_character":2,"end_line":525,"end_character":46},"updated":"2016-12-05 17:05:38.000000000","message":"I commented on this above, but I\u0027m not sure why we care about the attachments being in error state. If the instance was evacuated, we should have a migration record for it to know it was evacuated. In that case, we just need to get all attachments for this server and host and delete them as we can consider them bogus now.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":525,"context_line":"  error state, and completes the disconnection"},{"line_number":526,"context_line":"* Should the node never be brought back up, the admin can do a force detach"},{"line_number":527,"context_line":"  on all relevant volume attachments"},{"line_number":528,"context_line":"* Note that attachments in the error state do not reserver a volume for"},{"line_number":529,"context_line":"  the given server_uuid, nor do they count towards the list of connections"},{"line_number":530,"context_line":"  that should be sharing a host connection."},{"line_number":531,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_4eda7be9","line":528,"range":{"start_line":528,"start_character":50,"end_line":528,"end_character":58},"updated":"2016-12-05 17:05:38.000000000","message":"reserve","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":532,"context_line":"Shelve"},{"line_number":533,"context_line":"------"},{"line_number":534,"context_line":""},{"line_number":535,"context_line":"* When offloading, add a new attachment with no host set,"},{"line_number":536,"context_line":"  then delete old attachment after successful os-brick disconnect"},{"line_number":537,"context_line":""},{"line_number":538,"context_line":"Swap Volume"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_ce692bfb","line":535,"range":{"start_line":535,"start_character":19,"end_line":535,"end_character":56},"updated":"2016-12-05 17:05:38.000000000","message":"Wouldn\u0027t this fail if the volume has multiattach\u003dFalse?\n\nAlso, wouldn\u0027t this put the volume into \u0027attaching\u0027 state but then we never actually attach that volume until the instance is unshelved, if ever. Seems like a hairy mess.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":556,"context_line":"attachment uuid to stop any possible confusion around which attachment is"},{"line_number":557,"context_line":"associated to each BDM."},{"line_number":558,"context_line":""},{"line_number":559,"context_line":"During live-migration we could store the additional attachment_ids in the"},{"line_number":560,"context_line":"migrate data, rather than as part of the BDM."},{"line_number":561,"context_line":""},{"line_number":562,"context_line":"Data model impact"},{"line_number":563,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_ee38a7f0","line":560,"range":{"start_line":559,"start_character":0,"end_line":560,"end_character":45},"updated":"2016-12-05 17:05:38.000000000","message":"This might help with my concerns around how to model multiple vol attachments in the BDM above.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":566,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":567,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":568,"context_line":""},{"line_number":569,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":570,"context_line":"populated for existing connections, and how Nova uses this to know if the"},{"line_number":571,"context_line":"old or new flow should be used."},{"line_number":572,"context_line":""},{"line_number":573,"context_line":"REST API impact"},{"line_number":574,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_f106c61a","line":571,"range":{"start_line":569,"start_character":0,"end_line":571,"end_character":31},"updated":"2016-12-05 17:05:38.000000000","message":"I guess it\u0027s not called out, but while migrating old BDMs to the new flow, after creating the attachment record in Cinder and populating it with the bdm.connection_info we had before, would we then drop the connection_info from the BDM when we update it with the attachment_id? Maybe not necessary, but seems like that would make the BDM look more like the new flow.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":584,"context_line":"Notifications impact"},{"line_number":585,"context_line":"--------------------"},{"line_number":586,"context_line":""},{"line_number":587,"context_line":"None."},{"line_number":588,"context_line":""},{"line_number":589,"context_line":"Other end user impact"},{"line_number":590,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_117182a8","line":587,"updated":"2016-12-05 17:05:38.000000000","message":"This might have overlap with:\n\nhttps://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":589,"context_line":"Other end user impact"},{"line_number":590,"context_line":"---------------------"},{"line_number":591,"context_line":""},{"line_number":592,"context_line":"None."},{"line_number":593,"context_line":""},{"line_number":594,"context_line":"Performance Impact"},{"line_number":595,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_11f6e2f8","line":592,"updated":"2016-12-05 17:05:38.000000000","message":"As noted far about, I worry about the race where the volume goes to in-use state before we actually connect it on the host via os-brick. I can definitely see Tempest polling the volume status until it\u0027s in-use and then assuming it can ssh into the guest and see the volume is mounted. So there might need to be new assumptions from the client side made, or we set task_state on the instance while attaching a volume...","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4331b9d2ac21fd73543276981f6947764e3c4184","unresolved":false,"context_lines":[{"line_number":641,"context_line":""},{"line_number":642,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":643,"context_line":""},{"line_number":644,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":645,"context_line":"both the old a new code paths, until we delete the old code path."},{"line_number":646,"context_line":""},{"line_number":647,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3a71b18c_715396e2","line":644,"updated":"2016-12-05 17:05:38.000000000","message":"There is a typo in here, but as noted above I don\u0027t like needing to rely on config options for this as we can do it knowing the cinder API version and minimum nova-compute service version.","commit_id":"f15e8a585fb316939dec889c8e9ba136750ed176"}],"specs/pike/approved/cinder-new-attach-apis.rst":[{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"baea29185f31ced5fd90065d7870277f9646e2c7","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Use Cinder\u0027s new Attach/Dettach APIs"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cinder-new-attach-apis"}],"source_content_type":"text/x-rst","patch_set":14,"id":"da36d5c6_a799d470","line":8,"updated":"2017-02-20 21:39:26.000000000","message":"%s/Dettach/Detach/g","commit_id":"e3c1953f98b028aa89faa455fb562933fac79ba2"},{"author":{"_account_id":12924,"name":"Patrick East","email":"east.patrick@gmail.com","username":"patrick.east"},"change_message_id":"d297ccc7b61943a16f00b1868075c1c9648a09a6","unresolved":false,"context_lines":[{"line_number":183,"context_line":"connections, and it lists the other attachments currently making use of that"},{"line_number":184,"context_line":"shared attachment."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"TODO - is that true now??"},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"To ensure there are no races when attaching and detaching the shared backend"},{"line_number":189,"context_line":"attachment, when cinder says the backend is shared, we take a host lock,"}],"source_content_type":"text/x-rst","patch_set":14,"id":"da36d5c6_c5a58da2","line":186,"updated":"2017-02-22 21:11:28.000000000","message":"It looks like the *how* for this is still a little bit of a TBD. Right now cinder gets this info from volume drivers on detach, which is too late for the proposed flow. If we instead did it on attach or something this should work pretty well. I\u0027m assuming this is more of a cinder change that needs to be settled on. The proposed flow below sounds good to me.","commit_id":"e3c1953f98b028aa89faa455fb562933fac79ba2"},{"author":{"_account_id":3189,"name":"Chet Burgess","email":"cfb@metacloud.com","username":"cfb-n"},"change_message_id":"5ff8a76b9aa031fa2518b465363f93aca4657417","unresolved":false,"context_lines":[{"line_number":261,"context_line":"-----------"},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"TODO - how does this fit in the picture?"},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Alternatives"},{"line_number":266,"context_line":"------------"},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"da36d5c6_a364ed21","line":264,"updated":"2017-02-23 19:43:52.000000000","message":"You need a section on boot-from-volume. As per the issue pointed out in https://review.openstack.org/#/c/417541/9, the new attachment API will allow you to get an attachment for a volume that is still in a creating/downloading state. As the compute code is written today it will only wait for a volume to become ready if a volume_id is *not* passed into the boot from volume call. If we move to the attachment API and make a boot from volume call with an existing volume_id that is still in a creating or downloading state the instance will fail to spawn because it won\u0027t be able to actually connect to the volume till its ready.\n\nAs per the spec we have code in nova already to wait on the volume to become ready. We need to update nova-compute to use the waiting logic on all boot from volume calls.","commit_id":"e3c1953f98b028aa89faa455fb562933fac79ba2"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":46,"context_line":"* Evacuate, we know the old host is no longer running, and we need to attach"},{"line_number":47,"context_line":"  the volume to a new host. If the old host comes back up ever, it needs to"},{"line_number":48,"context_line":"  delete the old connection, if that old host is never started, the operator"},{"line_number":49,"context_line":"  needs to clean up the old connections in Cinder."},{"line_number":50,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":51,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":52,"context_line":"* Attach/Detach a volume attached to a shelved instance"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_0358fdf9","line":49,"updated":"2017-03-01 12:30:08.000000000","message":"On evacuate we should clean up the old connections in cinder immediately, because they must never be re-used. The host only needs to reliably detect that a connection has been evacuated.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8010dfc89ae38eadbc20477bd3860c80aab5f9f3","unresolved":false,"context_lines":[{"line_number":46,"context_line":"* Evacuate, we know the old host is no longer running, and we need to attach"},{"line_number":47,"context_line":"  the volume to a new host. If the old host comes back up ever, it needs to"},{"line_number":48,"context_line":"  delete the old connection, if that old host is never started, the operator"},{"line_number":49,"context_line":"  needs to clean up the old connections in Cinder."},{"line_number":50,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":51,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":52,"context_line":"* Attach/Detach a volume attached to a shelved instance"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_647d0a1c","line":49,"in_reply_to":"ba2be162_0358fdf9","updated":"2017-03-01 19:03:08.000000000","message":"We leave those attachment so we know they need to be cleaned up still. Lets go through that more below.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"In particular, please note:"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* Volume attachment is specific to a host uuid, server uuid, and volume uuid"},{"line_number":58,"context_line":"* You can have multiple attachments to the same volume, to different instances"},{"line_number":59,"context_line":"  (on the same host or different hosts), when the volume is marked"},{"line_number":60,"context_line":"  multi_attach\u003dTrue"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ce7b777a","line":57,"range":{"start_line":57,"start_character":48,"end_line":57,"end_character":59},"updated":"2017-02-28 14:33:42.000000000","message":"s/server uuid/instance uuid/g as used in the cinder spec.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"In particular, please note:"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* Volume attachment is specific to a host uuid, server uuid, and volume uuid"},{"line_number":58,"context_line":"* You can have multiple attachments to the same volume, to different instances"},{"line_number":59,"context_line":"  (on the same host or different hosts), when the volume is marked"},{"line_number":60,"context_line":"  multi_attach\u003dTrue"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_5e4f1192","line":57,"range":{"start_line":57,"start_character":48,"end_line":57,"end_character":59},"in_reply_to":"ba2be162_ce7b777a","updated":"2017-03-01 09:08:31.000000000","message":"yeah, server uuid is the Nova API term, instance uuid is the cinder API term :(","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9cb9ccec9ef1b4848ed961f9081279d8cffe3ff3","unresolved":false,"context_lines":[{"line_number":79,"context_line":"Firstly, we need to decide when it is safe to use the new API. We need to have"},{"line_number":80,"context_line":"the Cinder v3 API configured, and that endpoint should have the micro-version"},{"line_number":81,"context_line":"v3.xx available. In addition we should only use the new API when all of the"},{"line_number":82,"context_line":"nova-compute nodes have been upgraded. We can detect that by looking up the"},{"line_number":83,"context_line":"minimum service version relating to when we add the support for the new"},{"line_number":84,"context_line":"Cinder API."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"If we allow the use of the new API, we can use that for all new attachments."},{"line_number":87,"context_line":"When adding a new attachments we:"}],"source_content_type":"text/x-rst","patch_set":15,"id":"da36d5c6_f1b55731","line":84,"range":{"start_line":82,"start_character":39,"end_line":84,"end_character":11},"updated":"2017-02-28 12:09:26.000000000","message":"Does it also mean we need to bump the service version when nova starts using the new Cinder API?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":79,"context_line":"Firstly, we need to decide when it is safe to use the new API. We need to have"},{"line_number":80,"context_line":"the Cinder v3 API configured, and that endpoint should have the micro-version"},{"line_number":81,"context_line":"v3.xx available. In addition we should only use the new API when all of the"},{"line_number":82,"context_line":"nova-compute nodes have been upgraded. We can detect that by looking up the"},{"line_number":83,"context_line":"minimum service version relating to when we add the support for the new"},{"line_number":84,"context_line":"Cinder API."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"If we allow the use of the new API, we can use that for all new attachments."},{"line_number":87,"context_line":"When adding a new attachments we:"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_3e189d84","line":84,"range":{"start_line":82,"start_character":39,"end_line":84,"end_character":11},"in_reply_to":"da36d5c6_f1b55731","updated":"2017-03-01 09:08:31.000000000","message":"Yes, we do. I can be explicit about that.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9cb9ccec9ef1b4848ed961f9081279d8cffe3ff3","unresolved":false,"context_lines":[{"line_number":89,"context_line":"* (api) call attachment_create, with no connector, before API call returns."},{"line_number":90,"context_line":"  BDM record is updated with attachment_id."},{"line_number":91,"context_line":"  Note, if the volume is not multi_attach\u003dTrue, it will only allow one"},{"line_number":92,"context_line":"  instance_uuid to be associated with each volume. While the long term aim"},{"line_number":93,"context_line":"  is to enable multi-attach, this spec will not attach to any volume that has"},{"line_number":94,"context_line":"  multi-attach\u003dTrue."},{"line_number":95,"context_line":"* (compute) get connector info and use that to call attachment_update."},{"line_number":96,"context_line":"  The API now returns with all the information that needs to be given to"},{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"}],"source_content_type":"text/x-rst","patch_set":15,"id":"da36d5c6_91c33b8a","line":94,"range":{"start_line":92,"start_character":51,"end_line":94,"end_character":20},"updated":"2017-02-28 12:09:26.000000000","message":"Even if it is the first instance that tries to use the volume marked with multi-attach\u003dTrue?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":89,"context_line":"* (api) call attachment_create, with no connector, before API call returns."},{"line_number":90,"context_line":"  BDM record is updated with attachment_id."},{"line_number":91,"context_line":"  Note, if the volume is not multi_attach\u003dTrue, it will only allow one"},{"line_number":92,"context_line":"  instance_uuid to be associated with each volume. While the long term aim"},{"line_number":93,"context_line":"  is to enable multi-attach, this spec will not attach to any volume that has"},{"line_number":94,"context_line":"  multi-attach\u003dTrue."},{"line_number":95,"context_line":"* (compute) get connector info and use that to call attachment_update."},{"line_number":96,"context_line":"  The API now returns with all the information that needs to be given to"},{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_b93ae7cb","line":94,"range":{"start_line":92,"start_character":51,"end_line":94,"end_character":20},"in_reply_to":"da36d5c6_91c33b8a","updated":"2017-03-01 09:08:31.000000000","message":"Good question... not sure actually. I think we would have to just not attach it.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  The API now returns with all the information that needs to be given to"},{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":98,"context_line":"  connection to the volume backend."},{"line_number":99,"context_line":"* (compute) use os.brick to connect to the volume backend, and attach to"},{"line_number":100,"context_line":"  the VM. If there are any errors, perform a disconnect flow."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"For a detach:"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_8e817f50","line":99,"range":{"start_line":99,"start_character":2,"end_line":99,"end_character":11},"updated":"2017-02-28 14:33:42.000000000","message":"As below I would use (virt) here.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  The API now returns with all the information that needs to be given to"},{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":98,"context_line":"  connection to the volume backend."},{"line_number":99,"context_line":"* (compute) use os.brick to connect to the volume backend, and attach to"},{"line_number":100,"context_line":"  the VM. If there are any errors, perform a disconnect flow."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"For a detach:"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_3974379b","line":99,"range":{"start_line":99,"start_character":2,"end_line":99,"end_character":11},"in_reply_to":"ba2be162_8e817f50","updated":"2017-03-01 09:08:31.000000000","message":"I was really talking about the process here, we probably want to sort out that code a bit in the process of this.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9cb9ccec9ef1b4848ed961f9081279d8cffe3ff3","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":98,"context_line":"  connection to the volume backend."},{"line_number":99,"context_line":"* (compute) use os.brick to connect to the volume backend, and attach to"},{"line_number":100,"context_line":"  the VM. If there are any errors, perform a disconnect flow."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"For a detach:"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"da36d5c6_115d8bec","line":100,"range":{"start_line":100,"start_character":45,"end_line":100,"end_character":60},"updated":"2017-02-28 12:09:26.000000000","message":"Is it the same as a detach flow described below?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":98,"context_line":"  connection to the volume backend."},{"line_number":99,"context_line":"* (compute) use os.brick to connect to the volume backend, and attach to"},{"line_number":100,"context_line":"  the VM. If there are any errors, perform a disconnect flow."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"For a detach:"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_399b57cb","line":100,"range":{"start_line":100,"start_character":45,"end_line":100,"end_character":60},"in_reply_to":"ba2be162_eef75bf3","updated":"2017-03-01 09:08:31.000000000","message":"I could be more explicit, but yes, call attachement_remove","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":98,"context_line":"  connection to the volume backend."},{"line_number":99,"context_line":"* (compute) use os.brick to connect to the volume backend, and attach to"},{"line_number":100,"context_line":"  the VM. If there are any errors, perform a disconnect flow."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"For a detach:"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_eef75bf3","line":100,"range":{"start_line":100,"start_character":45,"end_line":100,"end_character":60},"in_reply_to":"da36d5c6_115d8bec","updated":"2017-02-28 14:33:42.000000000","message":"AFAIK yes as we do today but only the compute attachment_remove part.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"* (compute) if attachment_id is set in the BDM, we use the new detach flow,"},{"line_number":105,"context_line":"  otherwise we fall back to the old detach flow. The new flow is..."},{"line_number":106,"context_line":"* (compute) call os-brick to detach the volume"},{"line_number":107,"context_line":"* (compute) if success, attachment_remove is called."},{"line_number":108,"context_line":"  If there was an error, we add an instance fault"},{"line_number":109,"context_line":"  and set the instance into the error state."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ae864363","line":106,"range":{"start_line":106,"start_character":2,"end_line":106,"end_character":46},"updated":"2017-02-28 14:33:42.000000000","message":"The first step is to detach the volume from the instance itself. I\u0027d add the following before this os-brick step :\n\n(virt) detach the volume from the instance.\n\nos-brick is also called from the virt layer so I\u0027d replace \n\n(compute) here with (virt).","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":103,"context_line":""},{"line_number":104,"context_line":"* (compute) if attachment_id is set in the BDM, we use the new detach flow,"},{"line_number":105,"context_line":"  otherwise we fall back to the old detach flow. The new flow is..."},{"line_number":106,"context_line":"* (compute) call os-brick to detach the volume"},{"line_number":107,"context_line":"* (compute) if success, attachment_remove is called."},{"line_number":108,"context_line":"  If there was an error, we add an instance fault"},{"line_number":109,"context_line":"  and set the instance into the error state."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_19b7733a","line":106,"range":{"start_line":106,"start_character":2,"end_line":106,"end_character":46},"in_reply_to":"ba2be162_ae864363","updated":"2017-03-01 09:08:31.000000000","message":"I was trying to keep this process based, maybe incorrectly.\n\nI will add in detach.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":117,"context_line":"------------"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"During live-migration, we start the process by ensuring the volume is attached"},{"line_number":120,"context_line":"on both the source and destination. When a volume is mutli_attach\u003dFalse, and"},{"line_number":121,"context_line":"we are about to start live-migrating VM1, you get a situation like this ::"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"    +-------------------+   +-------------------+"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_a37491fd","line":120,"range":{"start_line":120,"start_character":52,"end_line":120,"end_character":65},"updated":"2017-03-01 12:30:08.000000000","message":"Typo","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Note both attachments are associated with the same server uuid,"},{"line_number":155,"context_line":"which is why the two attachments are allowed even though multi_attach\u003dFalse."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Should the live-migration succeed, the VM1 (inactive) is the final location,"},{"line_number":158,"context_line":"and the host1 connection will be removed. If it fails and we rollback the"},{"line_number":159,"context_line":"live-migration, VM1 (active) will be the only connection, and the host2"},{"line_number":160,"context_line":"connection will need to be removed."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"So in the new approach we make the following calls to Cinder:"},{"line_number":163,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_0ec4af90","line":160,"range":{"start_line":157,"start_character":0,"end_line":160,"end_character":35},"updated":"2017-02-28 14:33:42.000000000","message":"I think it would make more sense to talk about which attachment is used if we succeed and fail here.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Note both attachments are associated with the same server uuid,"},{"line_number":155,"context_line":"which is why the two attachments are allowed even though multi_attach\u003dFalse."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Should the live-migration succeed, the VM1 (inactive) is the final location,"},{"line_number":158,"context_line":"and the host1 connection will be removed. If it fails and we rollback the"},{"line_number":159,"context_line":"live-migration, VM1 (active) will be the only connection, and the host2"},{"line_number":160,"context_line":"connection will need to be removed."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"So in the new approach we make the following calls to Cinder:"},{"line_number":163,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_9981a34d","line":160,"range":{"start_line":157,"start_character":0,"end_line":160,"end_character":35},"in_reply_to":"ba2be162_0ec4af90","updated":"2017-03-01 09:08:31.000000000","message":"yeah, will reword that.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":171,"context_line":"Shared Volume Backend Connections"},{"line_number":172,"context_line":"---------------------------------"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"Cinder is able to tell Nova a given volume connection is shared by multiple"},{"line_number":175,"context_line":"connections. If shared, it lists the other attachments currently making use"},{"line_number":176,"context_line":"of that shared attachment."},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ce40d70a","line":174,"updated":"2017-02-28 14:33:42.000000000","message":"if","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":181,"context_line":""},{"line_number":182,"context_line":"When attaching, if the cinder says its a shared attachment:"},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"* Update the attachment with the connector, and"},{"line_number":185,"context_line":"  check if its a shared attachment."},{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_0e72ef7c","line":185,"range":{"start_line":184,"start_character":0,"end_line":185,"end_character":35},"updated":"2017-02-28 14:33:42.000000000","message":"by checking the returned connection_info right?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9cb9ccec9ef1b4848ed961f9081279d8cffe3ff3","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"* Update the attachment with the connector, and"},{"line_number":185,"context_line":"  check if its a shared attachment."},{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"},{"line_number":189,"context_line":"  same attachments."},{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"}],"source_content_type":"text/x-rst","patch_set":15,"id":"da36d5c6_719de758","line":187,"range":{"start_line":186,"start_character":2,"end_line":187,"end_character":31},"updated":"2017-02-28 12:09:26.000000000","message":"Is this lock used by Cinder and Nova together?\n\nA lock in nova prevents parallel nova operations to interfere. However Cinder REST API still can be used to manipulate the number of attachments to the same volume in parallel with Nova.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8010dfc89ae38eadbc20477bd3860c80aab5f9f3","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"* Update the attachment with the connector, and"},{"line_number":185,"context_line":"  check if its a shared attachment."},{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"},{"line_number":189,"context_line":"  same attachments."},{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_24b152e2","line":187,"range":{"start_line":186,"start_character":2,"end_line":187,"end_character":31},"in_reply_to":"ba2be162_3e951640","updated":"2017-03-01 19:03:08.000000000","message":"Technically yes, this was keeping it simple for now.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"* Update the attachment with the connector, and"},{"line_number":185,"context_line":"  check if its a shared attachment."},{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"},{"line_number":189,"context_line":"  same attachments."},{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_b902e73c","line":187,"range":{"start_line":186,"start_character":2,"end_line":187,"end_character":31},"in_reply_to":"da36d5c6_719de758","updated":"2017-03-01 09:08:31.000000000","message":"Its a Nova only lock, that is specific the the host, but the list of attachments we are looking at are only those shared by the Nova host, so that should be fine.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":"* Update the attachment with the connector, and"},{"line_number":185,"context_line":"  check if its a shared attachment."},{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"},{"line_number":189,"context_line":"  same attachments."},{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_3e951640","line":187,"range":{"start_line":186,"start_character":2,"end_line":187,"end_character":31},"in_reply_to":"da36d5c6_719de758","updated":"2017-03-01 12:30:08.000000000","message":"Whoa! The scope of this lock doesn\u0027t need to exceed the shared connection. We should allow concurrent attachments to different shared connections.\n\nThis can be handled entirely with locking on the Nova side. Unless the Cinder REST API either blocks or provides a callback mechanism for indicating success, it already races here. As long as the cinder user isn\u0027t informed of a successful attach/detach before that attach/detach has actually occurred, locking exclusively on the Nova side will ensure that operations are ordered.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":186,"context_line":"* If shared attachment, acquire a host wide lock for all volume"},{"line_number":187,"context_line":"  attach and detach operations."},{"line_number":188,"context_line":"* With the lock held, get the list of attachments that share the"},{"line_number":189,"context_line":"  same attachments."},{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"},{"line_number":191,"context_line":"  call os.brick\u0027s attach in the usual way."},{"line_number":192,"context_line":"* If there are other attachments, we are not the first, so there"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_43b0358c","line":189,"range":{"start_line":189,"start_character":7,"end_line":189,"end_character":18},"updated":"2017-03-01 12:30:08.000000000","message":"connection","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* If there are no other attachments, we must be the first, so we"},{"line_number":191,"context_line":"  call os.brick\u0027s attach in the usual way."},{"line_number":192,"context_line":"* If there are other attachments, we are not the first, so there"},{"line_number":193,"context_line":"  is no need to call os.brick\u0027s attach. We could check the connection"},{"line_number":194,"context_line":"  if os.brick adds such support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"When it comes to detach, it is very similar:"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_0ee74f13","line":194,"range":{"start_line":193,"start_character":40,"end_line":194,"end_character":32},"updated":"2017-02-28 14:33:42.000000000","message":"+1 we didn\u0027t bring this up at the PTG but it would be useful.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  call os.brick\u0027s attach in the usual way."},{"line_number":192,"context_line":"* If there are other attachments, we are not the first, so there"},{"line_number":193,"context_line":"  is no need to call os.brick\u0027s attach. We could check the connection"},{"line_number":194,"context_line":"  if os.brick adds such support."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"When it comes to detach, it is very similar:"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_befe6603","line":194,"updated":"2017-03-01 12:30:08.000000000","message":"This is fragile, because it ignores that things which should be connected might not be. For example this could be because of a crash, a network interruption, or because the host rebooted. Higher level logic can\u0027t reasonably know about these things, so the higher level must *always* call the driver with the intended state. The driver (os.brick) can then be responsible for ensuring we are in the correct state.\n\nIOW, we must always call os.brick\u0027s attach. attach should be idempotent.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":199,"context_line":"* If shared get the host wide volume operation lock"},{"line_number":200,"context_line":"* Fetch the list of attachments we are shared with"},{"line_number":201,"context_line":"* If empty, we have to call os.bricks disconnect"},{"line_number":202,"context_line":"* If there are other attachments, we must not call disconnect"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"When you mix live-migrate and shared host connections, because we now create"},{"line_number":205,"context_line":"a unique connection for the source and destination host, we are able to use"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_9e7e02ad","line":202,"updated":"2017-03-01 12:30:08.000000000","message":"This is not safe in general. Take the case of GlusterFS[1]. Nova\u0027s GlusterFS driver can implement GlusterFS connections either by mounting them on the host, or by getting qemu to connect directly to GlusterFS. The former case is a \u0027shared connection\u0027, the latter isn\u0027t. Note that the decision of which mode to use is made based on the versions of libvirt and qemu installed on the compute host, and cinder knows nothing about this.\n\nIOW we must always call disconnect, but cinder could provide the hint to the driver that the connection is still in use by other instances on that host.\n\n[1] This is actually now a hypothetical both because GlusterFS has been removed from cinder, and Nova\u0027s min libvirt/qemu is such that shared connection glusterfs is no longer required anyway. However, this same situation probably exists elsewhere, and if not it will come up again. e.g. host vs qemu iscsi support.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8010dfc89ae38eadbc20477bd3860c80aab5f9f3","unresolved":false,"context_lines":[{"line_number":199,"context_line":"* If shared get the host wide volume operation lock"},{"line_number":200,"context_line":"* Fetch the list of attachments we are shared with"},{"line_number":201,"context_line":"* If empty, we have to call os.bricks disconnect"},{"line_number":202,"context_line":"* If there are other attachments, we must not call disconnect"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"When you mix live-migrate and shared host connections, because we now create"},{"line_number":205,"context_line":"a unique connection for the source and destination host, we are able to use"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_c47dd6b2","line":202,"in_reply_to":"ba2be162_9e7e02ad","updated":"2017-03-01 19:03:08.000000000","message":"I will clarify what I am expecting from cinder here.\n\nI prefer your always call os.brick with enough info for it to make the correct call.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":257,"context_line":"* (destination) Create a second attachment for this instance_uuid for"},{"line_number":258,"context_line":"  any attached volumes"},{"line_number":259,"context_line":"* (destination) Connect the volumes as normal"},{"line_number":260,"context_line":"* (source) Should the source host ever start back up, it notes an instance"},{"line_number":261,"context_line":"  has been evacuated, and starts to clean up each evacuated instance."},{"line_number":262,"context_line":"  The BDM allows us to look up all attachments for the server_uuid and"},{"line_number":263,"context_line":"  volume_uuid. We must never clean up the attachment_id listed in the BDM"},{"line_number":264,"context_line":"  as that is in use on the destination host. There is likely only one other"},{"line_number":265,"context_line":"  attachment, we can check the host matches our host name, and if so, call"},{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ae080393","line":268,"range":{"start_line":260,"start_character":0,"end_line":268,"end_character":30},"updated":"2017-02-28 14:33:42.000000000","message":"I can\u0027t find the notes from the PTG on the etherpad [1] but my understanding was that we wouldn\u0027t stash the old attachment_id in the bdm. We should be able to look up any attachments for the host and instance directly from the cinder and cleanup that way.\n\n[1] https://etherpad.openstack.org/p/nova-ptg-pike-cinder","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":257,"context_line":"* (destination) Create a second attachment for this instance_uuid for"},{"line_number":258,"context_line":"  any attached volumes"},{"line_number":259,"context_line":"* (destination) Connect the volumes as normal"},{"line_number":260,"context_line":"* (source) Should the source host ever start back up, it notes an instance"},{"line_number":261,"context_line":"  has been evacuated, and starts to clean up each evacuated instance."},{"line_number":262,"context_line":"  The BDM allows us to look up all attachments for the server_uuid and"},{"line_number":263,"context_line":"  volume_uuid. We must never clean up the attachment_id listed in the BDM"},{"line_number":264,"context_line":"  as that is in use on the destination host. There is likely only one other"},{"line_number":265,"context_line":"  attachment, we can check the host matches our host name, and if so, call"},{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_fa69aa8c","line":268,"range":{"start_line":260,"start_character":0,"end_line":268,"end_character":30},"in_reply_to":"ba2be162_3eb6dddc","updated":"2017-03-01 12:30:08.000000000","message":"This cleanup races with the deletion of the instance and/or the volume. If it comes back up, the host needs to hold enough information to entirely cleanup all local resources.\n\nLets say a host suffers a hardware failure which doesn\u0027t get fixed for 6 weeks. When it comes back up in 6 weeks, its instances, their volumes and BDMs no longer exist anywhere. However, it still needs to take steps to unconfigure host volume attachments locally.\n\nFor the libvirt driver, we can probably reconstruct a connection_info from the libvirt xml of the evacuated instance. However, connection_info is really something we only want os-brick to be concerned with, so there\u0027s an interesting layering thing here.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":257,"context_line":"* (destination) Create a second attachment for this instance_uuid for"},{"line_number":258,"context_line":"  any attached volumes"},{"line_number":259,"context_line":"* (destination) Connect the volumes as normal"},{"line_number":260,"context_line":"* (source) Should the source host ever start back up, it notes an instance"},{"line_number":261,"context_line":"  has been evacuated, and starts to clean up each evacuated instance."},{"line_number":262,"context_line":"  The BDM allows us to look up all attachments for the server_uuid and"},{"line_number":263,"context_line":"  volume_uuid. We must never clean up the attachment_id listed in the BDM"},{"line_number":264,"context_line":"  as that is in use on the destination host. There is likely only one other"},{"line_number":265,"context_line":"  attachment, we can check the host matches our host name, and if so, call"},{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_3eb6dddc","line":268,"range":{"start_line":260,"start_character":0,"end_line":268,"end_character":30},"in_reply_to":"ba2be162_ae080393","updated":"2017-03-01 09:08:31.000000000","message":"So what you say, was my intent with those words, let me correct that.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8010dfc89ae38eadbc20477bd3860c80aab5f9f3","unresolved":false,"context_lines":[{"line_number":257,"context_line":"* (destination) Create a second attachment for this instance_uuid for"},{"line_number":258,"context_line":"  any attached volumes"},{"line_number":259,"context_line":"* (destination) Connect the volumes as normal"},{"line_number":260,"context_line":"* (source) Should the source host ever start back up, it notes an instance"},{"line_number":261,"context_line":"  has been evacuated, and starts to clean up each evacuated instance."},{"line_number":262,"context_line":"  The BDM allows us to look up all attachments for the server_uuid and"},{"line_number":263,"context_line":"  volume_uuid. We must never clean up the attachment_id listed in the BDM"},{"line_number":264,"context_line":"  as that is in use on the destination host. There is likely only one other"},{"line_number":265,"context_line":"  attachment, we can check the host matches our host name, and if so, call"},{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ff07c37e","line":268,"range":{"start_line":260,"start_character":0,"end_line":268,"end_character":30},"in_reply_to":"ba2be162_fa69aa8c","updated":"2017-03-01 19:03:08.000000000","message":"I thought we had enough information in the migration objects, but if you mix in volume detach, we might must be missing something, and db prune breaks some other things. I need to think about that more.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Shelve"},{"line_number":274,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_2e3c132f","line":271,"range":{"start_line":269,"start_character":0,"end_line":271,"end_character":58},"updated":"2017-02-28 14:33:42.000000000","message":"I think we talked about adding a nova-manage command for this right?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Shelve"},{"line_number":274,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_def5c183","line":271,"range":{"start_line":269,"start_character":0,"end_line":271,"end_character":58},"in_reply_to":"ba2be162_2e3c132f","updated":"2017-03-01 09:08:31.000000000","message":"So that would be a possible addition, we need to update the existing clean up logic anyways.\n\nI am a bit torn honestly, but I think we need it.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8010dfc89ae38eadbc20477bd3860c80aab5f9f3","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Shelve"},{"line_number":274,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_7f78332c","line":271,"range":{"start_line":269,"start_character":0,"end_line":271,"end_character":58},"in_reply_to":"ba2be162_da1a2617","updated":"2017-03-01 19:03:08.000000000","message":"It was nice to acknowledge the clean up, but I get your point.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  os-brick to clean up the attachment, and if that succeeds delete the"},{"line_number":267,"context_line":"  attachment. If if fails the attachment is left, and an instance fault"},{"line_number":268,"context_line":"  is recorded on the instance."},{"line_number":269,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":270,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"},{"line_number":271,"context_line":"  will be unable to use that volume with another instance."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Shelve"},{"line_number":274,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_da1a2617","line":271,"range":{"start_line":269,"start_character":0,"end_line":271,"end_character":58},"in_reply_to":"ba2be162_def5c183","updated":"2017-03-01 12:30:08.000000000","message":"My preference would be that the source attachments be cleaned up in cinder immediately. For the reasons above a robust evacuate needs to be able to recover this situation anyway.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":282,"context_line":"Swap Volume"},{"line_number":283,"context_line":"-----------"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"TODO - how does this fit in the picture? It is assume we would have to have"},{"line_number":286,"context_line":"an attachment on both the source and destination node."},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Alternatives"},{"line_number":289,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_8e941fe9","line":286,"range":{"start_line":285,"start_character":0,"end_line":286,"end_character":54},"updated":"2017-02-28 14:33:42.000000000","message":"swap_volume happens on a single host so assuming we are swapping volume A with B we would just need to  : \n\n1. (compute) create_attachment and connect to the volume B if required.\n2. (virt) swap volume A with volume B.\n3. (compute) update the bdm with the attachment_id for volume B.\n4. (virt) disconnect volume A.\n5. (compute) delete_attachment for volume A.\n6. (compute) update_attachment to update the volume id for volume B.\n\nUrgh, I\u0027ll revisit the swap_volume code again to check that\u0027s correct.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":282,"context_line":"Swap Volume"},{"line_number":283,"context_line":"-----------"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"TODO - how does this fit in the picture? It is assume we would have to have"},{"line_number":286,"context_line":"an attachment on both the source and destination node."},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Alternatives"},{"line_number":289,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_7eb4d5f1","line":286,"range":{"start_line":285,"start_character":0,"end_line":286,"end_character":54},"in_reply_to":"ba2be162_8e941fe9","updated":"2017-03-01 09:08:31.000000000","message":"oh, that sounds about correct, eek.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":3189,"name":"Chet Burgess","email":"cfb@metacloud.com","username":"cfb-n"},"change_message_id":"34ef34bdb340f955c3d3ad7a0ff2214cd1d4c21c","unresolved":false,"context_lines":[{"line_number":284,"context_line":""},{"line_number":285,"context_line":"TODO - how does this fit in the picture? It is assume we would have to have"},{"line_number":286,"context_line":"an attachment on both the source and destination node."},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Alternatives"},{"line_number":289,"context_line":"------------"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_34ed2e8c","line":287,"updated":"2017-02-28 22:09:01.000000000","message":"You need a section on boot-from-volume. As per the issue pointed out in https://review.openstack.org/#/c/417541/9, the new attachment API will allow you to get an attachment for a volume that is still in a creating/downloading state. As the compute code is written today it will only wait for a volume to become ready if a volume_id is *not* passed into the boot from volume call. If we move to the attachment API and make a boot from volume call with an existing volume_id that is still in a creating or downloading state the instance will fail to spawn because it won\u0027t be able to actually connect to the volume till its ready.\n\nAs per the spec we have code in nova already to wait on the volume to become ready. We need to update nova-compute to use the waiting logic on all boot from volume calls.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":284,"context_line":""},{"line_number":285,"context_line":"TODO - how does this fit in the picture? It is assume we would have to have"},{"line_number":286,"context_line":"an attachment on both the source and destination node."},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"Alternatives"},{"line_number":289,"context_line":"------------"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_9eb0a9f6","line":287,"in_reply_to":"ba2be162_34ed2e8c","updated":"2017-03-01 09:08:31.000000000","message":"Ooops, yeah. \n\nWe actually need that for all possible attachments I believe. I will put that in there.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":294,"context_line":"key alternatives is to add lots of state machine complexity into the API so"},{"line_number":295,"context_line":"the shared connection related locking is handled by Cinder in the API layer."},{"line_number":296,"context_line":"While it makes the clients more complex, it seemed simpler for Nova and other"},{"line_number":297,"context_line":"clients to do the above locking discussed above."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"Nova could look up the attachment uuid rather than store it in the BDM, there"},{"line_number":300,"context_line":"is a period where the host uuid is not set, so it seems safer to store the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_ba09f233","line":297,"updated":"2017-03-01 12:30:08.000000000","message":"Consider a client makes the following cinder calls:\n\n1. attach\n2. detach\n3. attach\n\nLets assume we\u0027re using only nova-side locking. Call 1 kicks off a nova worker which starts attaching. Calls 2 and 3 also kick off nova workers to detach and attach respectively, but they are both blocked by the lock held by call 1.\n\nThe outcome of the sequence of calls is non-deterministic, based on which of calls 2 and 3 wins the race when call 1 drops its lock.\n\nHow are we going to ensure this behaviour is deterministic for the user? For example, we could ensure that the detach call will immediately return failure to the user, as we\u0027re still attaching to that host/instance. There are a bunch of ways to solve this, but we do need to pick one, and it will be part of the user-visible api.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":302,"context_line":"associated to each BDM."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"During live-migration we could store the additional attachment_ids in the"},{"line_number":305,"context_line":"migrate data, rather than as part of the BDM."},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"Data model impact"},{"line_number":308,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_59c64168","line":305,"updated":"2017-03-01 12:30:08.000000000","message":"I think it must do that. We need to ensure that Nova has a *persistent* record of both attachments simultaneously for both live and non-live migration, also remembering that a single migration may involve multiple attachments.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":309,"context_line":""},{"line_number":310,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":311,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":312,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":315,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_4e2f87a1","line":312,"range":{"start_line":312,"start_character":0,"end_line":312,"end_character":15},"updated":"2017-02-28 14:33:42.000000000","message":"I\u0027ve used attachment_id in the WIP series I\u0027ve posted below, this is in-line with some of the other uuid\u0027s we store in the DB but I\u0027d be happy to change if required :\n\nhttps://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/cinder-new-attach-apis","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":309,"context_line":""},{"line_number":310,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":311,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":312,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":315,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_9e87c90e","line":312,"range":{"start_line":312,"start_character":0,"end_line":312,"end_character":15},"in_reply_to":"ba2be162_4e2f87a1","updated":"2017-03-01 09:08:31.000000000","message":"attachment_id is what its called in the cinder API, so lets go with that.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"573e6faed7e380cccd789e0f5a65d8d7d41b3849","unresolved":false,"context_lines":[{"line_number":309,"context_line":""},{"line_number":310,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":311,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":312,"context_line":"attachment_uuid for each host the volume is attached to."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"See the transition plan for more details on how the attachment_uuid is"},{"line_number":315,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_591e41bb","line":312,"range":{"start_line":312,"start_character":0,"end_line":312,"end_character":15},"in_reply_to":"ba2be162_9e87c90e","updated":"2017-03-01 12:30:08.000000000","message":"Not sure what your specific plans are here, but I think Nova should still stash the connection_info it\u0027s using somewhere. With this new model cinder becomes the canonical source, but there\u0027s no reason not to store it. We don\u0027t really need to make a REST call to cinder during instance reboot or host restart, for eg.\n\nIncidentally, if we stored it in a host-local stash, that would also be more efficient (no rpc at all, even to the db), and it would solve the robustness issue of cleanup after evacuation, even if the instance and volume have been permanently deleted.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":365,"context_line":"Primary assignee:"},{"line_number":366,"context_line":"  Matt Riedemann"},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Other contributors:"},{"line_number":369,"context_line":"  John Griffith"},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Work Items"},{"line_number":372,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_511d6665","line":369,"range":{"start_line":368,"start_character":0,"end_line":369,"end_character":15},"updated":"2017-02-28 14:33:42.000000000","message":"Happy to be added here.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":365,"context_line":"Primary assignee:"},{"line_number":366,"context_line":"  Matt Riedemann"},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Other contributors:"},{"line_number":369,"context_line":"  John Griffith"},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Work Items"},{"line_number":372,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_de794131","line":369,"range":{"start_line":368,"start_character":0,"end_line":369,"end_character":15},"in_reply_to":"ba2be162_511d6665","updated":"2017-03-01 09:08:31.000000000","message":"coolness.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9cb9ccec9ef1b4848ed961f9081279d8cffe3ff3","unresolved":false,"context_lines":[{"line_number":391,"context_line":"Depends on the Cinder work to add the new API."},{"line_number":392,"context_line":"This was completed in Ocata."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"We also depend on the work stop remove Nova\u0027s check_attach logic, and now call"},{"line_number":395,"context_line":"reserve volume in Cinder, including for boot from volume."},{"line_number":396,"context_line":""},{"line_number":397,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":15,"id":"da36d5c6_0200d7a9","line":394,"range":{"start_line":394,"start_character":27,"end_line":394,"end_character":31},"updated":"2017-02-28 12:09:26.000000000","message":"nit: is this an unnecessary word here?","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":391,"context_line":"Depends on the Cinder work to add the new API."},{"line_number":392,"context_line":"This was completed in Ocata."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"We also depend on the work stop remove Nova\u0027s check_attach logic, and now call"},{"line_number":395,"context_line":"reserve volume in Cinder, including for boot from volume."},{"line_number":396,"context_line":""},{"line_number":397,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_3e8fbd24","line":394,"range":{"start_line":394,"start_character":27,"end_line":394,"end_character":31},"in_reply_to":"da36d5c6_0200d7a9","updated":"2017-03-01 09:08:31.000000000","message":"oops.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"91eec31f09d69e6338719168d48237b3757081bc","unresolved":false,"context_lines":[{"line_number":391,"context_line":"Depends on the Cinder work to add the new API."},{"line_number":392,"context_line":"This was completed in Ocata."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"We also depend on the work stop remove Nova\u0027s check_attach logic, and now call"},{"line_number":395,"context_line":"reserve volume in Cinder, including for boot from volume."},{"line_number":396,"context_line":""},{"line_number":397,"context_line":"Testing"},{"line_number":398,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_b103020d","line":395,"range":{"start_line":394,"start_character":0,"end_line":395,"end_character":57},"updated":"2017-02-28 14:33:42.000000000","message":"This has already landed and can be dropped.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ded54335f42f38aadfec1572e86f4d43666805d1","unresolved":false,"context_lines":[{"line_number":391,"context_line":"Depends on the Cinder work to add the new API."},{"line_number":392,"context_line":"This was completed in Ocata."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"We also depend on the work stop remove Nova\u0027s check_attach logic, and now call"},{"line_number":395,"context_line":"reserve volume in Cinder, including for boot from volume."},{"line_number":396,"context_line":""},{"line_number":397,"context_line":"Testing"},{"line_number":398,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":15,"id":"ba2be162_9e9ee954","line":395,"range":{"start_line":394,"start_character":0,"end_line":395,"end_character":57},"in_reply_to":"ba2be162_b103020d","updated":"2017-03-01 09:08:31.000000000","message":"yeah, why not. It hadn\u0027t when I wrote this.","commit_id":"89ed0db2dd17ee17859fd5199d73cd1a69dad778"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"923ad4dfe055c54fb7d3ba16e1ea4d19acf838cc","unresolved":false,"context_lines":[{"line_number":312,"context_line":"  cleaning up attachments relating to the host the instance was evacuated"},{"line_number":313,"context_line":"  from that was previously assumed to be dead."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"TODO - consider detaching a volume and deleting and instance after it has"},{"line_number":316,"context_line":"been evacuated. There are some nasty edge cases there. Possibly so nasty"},{"line_number":317,"context_line":"we shouldn\u0027t support the host coming back to life, somehow?"},{"line_number":318,"context_line":"Need to double check if we get from migration objects to volume attachments"},{"line_number":319,"context_line":"after the fact, we might need old attachment_id s to live in the migration"},{"line_number":320,"context_line":"record for evacuate? Or maybe just the volume_uuids?"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"* (operator) should the source host never be started, a manual cleanup of"},{"line_number":323,"context_line":"  all orphaned volume attachments should be done. If that is not done, users"}],"source_content_type":"text/x-rst","patch_set":17,"id":"ba2be162_72a3c800","line":320,"range":{"start_line":315,"start_character":0,"end_line":320,"end_character":52},"updated":"2017-03-02 18:08:23.000000000","message":"Today we call terminate_connection to clean up the cinder side of things, in the new world we do that by doing delete attachment.\n\nNow I understand the code better, thats clearly the right thing to do here.","commit_id":"8177ac8a0d49210d32a165644c83a168d7562cff"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":119,"context_line":"  otherwise we fall back to the old detach flow. The new flow is..."},{"line_number":120,"context_line":"* (api) usual checks to see if request is valid"},{"line_number":121,"context_line":"* (compute) detach volume from VM, if fails stop request here"},{"line_number":122,"context_line":"* (compute) call os-brick to disconnect from the volume backend"},{"line_number":123,"context_line":"* (compute) if success, attachment_remove is called."},{"line_number":124,"context_line":"  If there was an error, we add an instance fault"},{"line_number":125,"context_line":"  and set the instance into the error state."}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_60b6ef8b","line":122,"updated":"2017-03-07 17:54:22.000000000","message":"Can we ensure that reboot() will attempt to reconnect an attachment which exists but isn\u0027t connected?\n\nAside: we should really move all of this functionality out of reboot into a new admin-only \u0027try-to-fix-all-the-things\u0027 api call.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"abe94d161fecc49c68f00b5df610681a1a79495b","unresolved":false,"context_lines":[{"line_number":119,"context_line":"  otherwise we fall back to the old detach flow. The new flow is..."},{"line_number":120,"context_line":"* (api) usual checks to see if request is valid"},{"line_number":121,"context_line":"* (compute) detach volume from VM, if fails stop request here"},{"line_number":122,"context_line":"* (compute) call os-brick to disconnect from the volume backend"},{"line_number":123,"context_line":"* (compute) if success, attachment_remove is called."},{"line_number":124,"context_line":"  If there was an error, we add an instance fault"},{"line_number":125,"context_line":"  and set the instance into the error state."}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_8ce023fc","line":122,"in_reply_to":"9a30ddce_60b6ef8b","updated":"2017-03-09 14:45:06.000000000","message":"This seems outside the scope of this spec. Just keep it as today for now, we can improve it I am sure.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":173,"context_line":"Should the live-migration succeed, we will delete attachment 1 (i.e. source"},{"line_number":174,"context_line":"host attachment, host 1) and we are left with just attachment 2"},{"line_number":175,"context_line":"(i.e. destination host attachment, host 2). If there are any failures with"},{"line_number":176,"context_line":"os.brick disconnect on the source host, we put the instance into the ERROR"},{"line_number":177,"context_line":"state and don\u0027t delete the attachment in Cinder."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"If we have any failures in the live-migration such that the instance is still"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_3bd50643","line":176,"range":{"start_line":176,"start_character":40,"end_line":176,"end_character":74},"updated":"2017-03-07 17:54:22.000000000","message":"Might want to check this. Current behaviour seems to be to put the migration into an error state rather than the instance. I\u0027m guessing that in practise this isn\u0027t well tested or very robust, though.\n\nIn practise I doubt this detail is relevant to this spec, as we\u0027ll end up re-using the existing error handling code.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"abe94d161fecc49c68f00b5df610681a1a79495b","unresolved":false,"context_lines":[{"line_number":173,"context_line":"Should the live-migration succeed, we will delete attachment 1 (i.e. source"},{"line_number":174,"context_line":"host attachment, host 1) and we are left with just attachment 2"},{"line_number":175,"context_line":"(i.e. destination host attachment, host 2). If there are any failures with"},{"line_number":176,"context_line":"os.brick disconnect on the source host, we put the instance into the ERROR"},{"line_number":177,"context_line":"state and don\u0027t delete the attachment in Cinder."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"If we have any failures in the live-migration such that the instance is still"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_6cf12f01","line":176,"range":{"start_line":176,"start_character":40,"end_line":176,"end_character":74},"in_reply_to":"9a30ddce_3bd50643","updated":"2017-03-09 14:45:06.000000000","message":"I think here its more important to put the Instance into an ERROR state. Thats needed when admin actions are required to fix things, such as here.\n\nYou should put the migration into error if it failed, so that needs to be error too here. Its just if you have a clean role back you get a migration in the error state, but an instance in the ACTIVE state. That is strictly not the case here.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":179,"context_line":"If we have any failures in the live-migration such that the instance is still"},{"line_number":180,"context_line":"running on host 1, we do the opposite of the above. We attempt os.brick"},{"line_number":181,"context_line":"disconnect on host 2. If success we delete attachment 2, otherwise put the"},{"line_number":182,"context_line":"instance into the ERROR state. If the rollback succeeds we back to one"},{"line_number":183,"context_line":"attachment again, but in this case its attachment 1."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"So in the new approach we make the following calls to Cinder:"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_7b469e24","line":182,"range":{"start_line":182,"start_character":0,"end_line":182,"end_character":29},"updated":"2017-03-07 17:54:22.000000000","message":"Ditto","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* (source) call os-brick to disconnect"},{"line_number":194,"context_line":"* (source) if success, delete the attachment, otherwise put the"},{"line_number":195,"context_line":"  instance into an ERROR state"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"If live-migration rolls back due to an abort or similar:"},{"line_number":198,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_3b0a66d3","line":195,"range":{"start_line":195,"start_character":2,"end_line":195,"end_character":30},"updated":"2017-03-07 17:54:22.000000000","message":"Ditto.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":198,"context_line":""},{"line_number":199,"context_line":"* (destination) call os-brick to disconnect"},{"line_number":200,"context_line":"* (destination) if success, delete the attachment, otherwise put the"},{"line_number":201,"context_line":"  instance into an ERROR state"},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Migrate"},{"line_number":204,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_bb1d7611","line":201,"range":{"start_line":201,"start_character":2,"end_line":201,"end_character":30},"updated":"2017-03-07 17:54:22.000000000","message":"Ditto","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Similar to live-migrate, at the start of the migration we have attachments"},{"line_number":207,"context_line":"for both the source and destination node. On calling confirm resize we do"},{"line_number":208,"context_line":"a detach on source, a call to revert resize and its detach on destination."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Evacuate"},{"line_number":211,"context_line":"--------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_9b3fd224","line":208,"updated":"2017-03-07 17:54:22.000000000","message":"In practise for a migrate/resize we just call cleanup() on the side which needs cleaning up, so we just need to ensure the cleanup code handles the local attachment explicitly.\n\nFor migrate/resize we also don\u0027t need anything in advance because the target doesn\u0027t actually exist, but again this is likely just a detail which will be obvious when we write the code.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"abe94d161fecc49c68f00b5df610681a1a79495b","unresolved":false,"context_lines":[{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Similar to live-migrate, at the start of the migration we have attachments"},{"line_number":207,"context_line":"for both the source and destination node. On calling confirm resize we do"},{"line_number":208,"context_line":"a detach on source, a call to revert resize and its detach on destination."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Evacuate"},{"line_number":211,"context_line":"--------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_2c39f7a4","line":208,"in_reply_to":"9a30ddce_9b3fd224","updated":"2017-03-09 14:45:06.000000000","message":"So it is attached in two places. You effectively have two instances until you either revert or confirm.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":226,"context_line":"  have been evacuated are detected in the usual way (using the migration"},{"line_number":227,"context_line":"  record created when evacuate is called). This may leave some things not"},{"line_number":228,"context_line":"  cleaned up by os.brick, but that is fairly safe, and we are in a no worse"},{"line_number":229,"context_line":"  situation than we are today."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"Shelve"},{"line_number":232,"context_line":"------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_3b650645","line":229,"updated":"2017-03-07 17:54:22.000000000","message":"I like that better. A really robust evacuate is outside of the scope of this spec.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":243,"context_line":"For swap volume, we have one host, one instance, one device path, but"},{"line_number":244,"context_line":"multiple volumes. So the flow is something like this:"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"* (api) add attachment on new volume, like attach"},{"line_number":247,"context_line":"* (compute) update attachment with connector to the new volume"},{"line_number":248,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":249,"context_line":"  deal with this like a failure during detach, and possible delete the"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_91541355","line":246,"updated":"2017-03-07 17:54:22.000000000","message":"This flow is currently smoking way too much crack, and I think this is a good opportunity to put it through rehab. There are 2 different flows here, 1 initiated by cinder, 1 by nova. I don\u0027t personally understand the reason for the existence of the nova one, but I also know we have customers who use it so... whatever, it stays.\n\nThe flow on the nova side is:\n\nWe get swap_volume(vol_a, vol_b)\nWe attach vol_b\nWe copy the contents of vol_a to vol_b\nWe detach vol_a\nWe call cinder\u0027s migrate_volume_completion(vol_a, vol_b)\nWe update the BDM with a new connection_info which we\u0027ve guessed based on the return value of migrate_volume_completion()\n\nOn the cinder side, migrate_volume_completion() checks if there\u0027s a migration record, which means that cinder initiated the call. If there is, it does unnatural things to the volume record until vol_b is actually vol_a in a new location with the wrong name. If not, it does less unnatural things.\n\nIt makes my head hurt when I read this code.\n\nI think we could replace it with an entirely new call which takes 2 attachments instead of 2 volumes.\n\nThe nova-side the flow would be very similar, but all the strangeness related to what the connection_info is supposed to be would go away, because the connection_info of att_a and att_b would be immutable:\n\nCalled with (att_a, att_b)\nConnect to att_b\nCopy att_a to att_b\nDisconnect att_a\nUpdate the BDM to point to att_b\nCall cinder\u0027s migrate_volume_completion(att_a, att_b)\n\nThe nova side never needs to concern itself with whether cinder is going to update the volume id underneath it, because the attachment id won\u0027t change either way.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"abe94d161fecc49c68f00b5df610681a1a79495b","unresolved":false,"context_lines":[{"line_number":243,"context_line":"For swap volume, we have one host, one instance, one device path, but"},{"line_number":244,"context_line":"multiple volumes. So the flow is something like this:"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"* (api) add attachment on new volume, like attach"},{"line_number":247,"context_line":"* (compute) update attachment with connector to the new volume"},{"line_number":248,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":249,"context_line":"  deal with this like a failure during detach, and possible delete the"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_8c5bc3f5","line":246,"in_reply_to":"9a30ddce_91541355","updated":"2017-03-09 14:45:06.000000000","message":"Cool, yeah, let me update that.","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"9f033484004fbcf52e24d32c7b33ab58bc47130b","unresolved":false,"context_lines":[{"line_number":260,"context_line":""},{"line_number":261,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":262,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":263,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Alternatives"},{"line_number":266,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"9a30ddce_915ed343","line":263,"updated":"2017-03-07 17:54:22.000000000","message":"That\u0027s not really a spec :)\n\nI really feel like we can solve this robustly and race-free entirely on the nova side along the lines of https://review.openstack.org/#/c/383859/ .","commit_id":"5c3852bbb90c46379a55c1c46cb6449551790bea"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"414a9e0f65d2219ce063590369c57f17319cc238","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Firstly, we need to decide when it is safe to use the new API. We need to have"},{"line_number":80,"context_line":"the Cinder v3 API configured, and that endpoint should have the micro-version"},{"line_number":81,"context_line":"v3.xx available. In addition we should only use the new API when all of the"},{"line_number":82,"context_line":"nova-compute nodes have been upgraded. We can detect that by looking up the"},{"line_number":83,"context_line":"minimum service version relating to when we add the support for the new"},{"line_number":84,"context_line":"Cinder API. Note, this means we will probably need to increment the service"}],"source_content_type":"text/x-rst","patch_set":19,"id":"3a1ff146_15de3e3f","line":81,"range":{"start_line":81,"start_character":0,"end_line":81,"end_character":5},"updated":"2017-03-15 19:58:01.000000000","message":"3.27","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"414a9e0f65d2219ce063590369c57f17319cc238","unresolved":false,"context_lines":[{"line_number":181,"context_line":"If we have any failures in the live-migration such that the instance is still"},{"line_number":182,"context_line":"running on host 1, we do the opposite of the above. We attempt os.brick"},{"line_number":183,"context_line":"disconnect on host 2. If success we delete attachment 2, otherwise put the"},{"line_number":184,"context_line":"instance into the ERROR state. If the rollback succeeds we back to one"},{"line_number":185,"context_line":"attachment again, but in this case its attachment 1."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"So in the new approach we make the following calls to Cinder:"}],"source_content_type":"text/x-rst","patch_set":19,"id":"3a1ff146_153c7ee1","line":184,"range":{"start_line":184,"start_character":56,"end_line":184,"end_character":63},"updated":"2017-03-15 19:58:01.000000000","message":"we are back","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"414a9e0f65d2219ce063590369c57f17319cc238","unresolved":false,"context_lines":[{"line_number":253,"context_line":"* (api) add attachment on new volume, uuid-new, like attach"},{"line_number":254,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":255,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":256,"context_line":"  deal with this like a failure during detach, and possible delete the"},{"line_number":257,"context_line":"  attachment to the new volume"},{"line_number":258,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":259,"context_line":"  in libvirt this is via a rebase operation"}],"source_content_type":"text/x-rst","patch_set":19,"id":"3a1ff146_00d7de23","line":256,"range":{"start_line":256,"start_character":50,"end_line":256,"end_character":60},"updated":"2017-03-15 19:58:01.000000000","message":"do you mean \u0027possibly\u0027 or \u0027if possible,\u0027","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ff4754450d5e9e1e1fbbea708d3cf7e712376332","unresolved":false,"context_lines":[{"line_number":253,"context_line":"* (api) add attachment on new volume, uuid-new, like attach"},{"line_number":254,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":255,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":256,"context_line":"  deal with this like a failure during detach, and possible delete the"},{"line_number":257,"context_line":"  attachment to the new volume"},{"line_number":258,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":259,"context_line":"  in libvirt this is via a rebase operation"}],"source_content_type":"text/x-rst","patch_set":19,"id":"1a1ced50_e9a3d14d","line":256,"range":{"start_line":256,"start_character":50,"end_line":256,"end_character":60},"in_reply_to":"3a1ff146_00d7de23","updated":"2017-03-16 17:01:40.000000000","message":"not sure, I think I should remove that word.","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"414a9e0f65d2219ce063590369c57f17319cc238","unresolved":false,"context_lines":[{"line_number":271,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":272,"context_line":"  and deleted the attachment to the old volume."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":275,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"},{"line_number":276,"context_line":"case."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Shared Volume Backend Connections"}],"source_content_type":"text/x-rst","patch_set":19,"id":"3a1ff146_20acda9f","line":275,"range":{"start_line":274,"start_character":6,"end_line":275,"end_character":19},"updated":"2017-03-15 19:58:01.000000000","message":"Is it possible to provide some sort of nice message rather than having it fail?","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ff4754450d5e9e1e1fbbea708d3cf7e712376332","unresolved":false,"context_lines":[{"line_number":271,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":272,"context_line":"  and deleted the attachment to the old volume."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":275,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"},{"line_number":276,"context_line":"case."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Shared Volume Backend Connections"}],"source_content_type":"text/x-rst","patch_set":19,"id":"1a1ced50_e9ecb191","line":275,"range":{"start_line":274,"start_character":6,"end_line":275,"end_character":19},"in_reply_to":"3a1ff146_20acda9f","updated":"2017-03-16 17:01:40.000000000","message":"Thats outside the scope of the this spec really, as we don\u0027t support multi-attach at all right now., it should give a nice message in the usual way though.","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"414a9e0f65d2219ce063590369c57f17319cc238","unresolved":false,"context_lines":[{"line_number":291,"context_line":"key alternatives is to add lots of state machine complexity into the API so"},{"line_number":292,"context_line":"the shared connection related locking is handled by Cinder in the API layer."},{"line_number":293,"context_line":"While it makes the clients more complex, it seemed simpler for Nova and other"},{"line_number":294,"context_line":"clients to do the above locking discussed above."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"Nova could look up the attachment uuid rather than store it in the BDM, there"},{"line_number":297,"context_line":"is a period where the host uuid is not set, so it seems safer to store the"}],"source_content_type":"text/x-rst","patch_set":19,"id":"3a1ff146_40863614","line":294,"range":{"start_line":294,"start_character":17,"end_line":294,"end_character":24},"updated":"2017-03-15 19:58:01.000000000","message":"remove","commit_id":"a36eaf57c20051304d237815c65a341fca3b2d54"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":46,"context_line":"* Evacuate, we know the old host is no longer running, and we need to attach"},{"line_number":47,"context_line":"  the volume to a new host. If the old host comes back up ever, it needs to"},{"line_number":48,"context_line":"  delete the old connection, if that old host is never started, the operator"},{"line_number":49,"context_line":"  needs to clean up the old connections in Cinder."},{"line_number":50,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":51,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":52,"context_line":"* Attach/Detach a volume attached to a shelved instance"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_cc57b100","line":49,"updated":"2017-03-20 10:49:37.000000000","message":"nit - `the operator needs to clean up any stale connections on the host` \n\nWe currently kill access to the volume in Cinder via terminate_connection and will do the same in the future by deleting the attachment.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":51,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":52,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":53,"context_line":"* Detach the root volume of an instance (only when instance is powered off)"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"In particular, please note:"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* Volume attachment is specific to a host uuid, instance uuid, and volume uuid"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_ec5aad29","line":54,"updated":"2017-03-20 10:49:37.000000000","message":"nit - if we respin we should list swap volume here.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":102,"context_line":"  connection to the volume backend."},{"line_number":103,"context_line":"* (compute) Before we can actually connect to the volume we need to wait for"},{"line_number":104,"context_line":"  the volume to be ready and fully downloaded. If we timeout waiting for the"},{"line_number":105,"context_line":"  volume to be ready, we fail here and delete the attachment. If this is the"},{"line_number":106,"context_line":"  first boot of the instance, that will put the instance into the ERROR state."},{"line_number":107,"context_line":"  If the volume is ready, we can continue with the attach process."}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_ccb411f4","line":104,"updated":"2017-03-20 10:49:37.000000000","message":"nit - would `provisioned by c-vol` be better here? I just want to make clear that we are not downloading anything to the compute at this point.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9c6ef83c7d77e92f1e6ec10d7a232327c14f352d","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  os-brick to attach the volume backend, and how to attach the VM to that"},{"line_number":102,"context_line":"  connection to the volume backend."},{"line_number":103,"context_line":"* (compute) Before we can actually connect to the volume we need to wait for"},{"line_number":104,"context_line":"  the volume to be ready and fully downloaded. If we timeout waiting for the"},{"line_number":105,"context_line":"  volume to be ready, we fail here and delete the attachment. If this is the"},{"line_number":106,"context_line":"  first boot of the instance, that will put the instance into the ERROR state."},{"line_number":107,"context_line":"  If the volume is ready, we can continue with the attach process."}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_974a2282","line":104,"in_reply_to":"1a1ced50_ccb411f4","updated":"2017-03-20 11:00:06.000000000","message":"provisioned is a much better word, +1","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":110,"context_line":"  (to double check it is fully cleaned up) and then remove the attachment"},{"line_number":111,"context_line":"  in Cinder. If there are any issues in the rollback, put instance into the"},{"line_number":112,"context_line":"  ERROR state."},{"line_number":113,"context_line":"* (compute) now the backend is connected, and the volume is ready, we can"},{"line_number":114,"context_line":"  attach the backend connection to the VM in the usual way."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"For a detach:"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_8c885924","line":113,"updated":"2017-03-20 10:49:37.000000000","message":"nit - You have already called this out in the point above.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":249,"context_line":"user calls our API. Both flows are covered here:"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"* (cinder) creates a new empty volume, uuid-new"},{"line_number":252,"context_line":"* (cinder) calls the API to swap uuid-old with uuid-new"},{"line_number":253,"context_line":"* (api) add attachment on new volume, uuid-new, like attach"},{"line_number":254,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":255,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_cc6df105","line":252,"updated":"2017-03-20 10:49:37.000000000","message":"These are specific to the cinder retype flow, the nova flow uses two pre-existing volumes and doesn\u0027t start with a call to cinder AFAIK.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9c6ef83c7d77e92f1e6ec10d7a232327c14f352d","unresolved":false,"context_lines":[{"line_number":249,"context_line":"user calls our API. Both flows are covered here:"},{"line_number":250,"context_line":""},{"line_number":251,"context_line":"* (cinder) creates a new empty volume, uuid-new"},{"line_number":252,"context_line":"* (cinder) calls the API to swap uuid-old with uuid-new"},{"line_number":253,"context_line":"* (api) add attachment on new volume, uuid-new, like attach"},{"line_number":254,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":255,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_37216eb5","line":252,"in_reply_to":"1a1ced50_cc6df105","updated":"2017-03-20 11:00:06.000000000","message":"oh, this is cinder calling the Nova API, rather than the user calling the Nova API. I should fix that up.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":309,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":310,"context_line":"attachment_id for each host the volume is attached to."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"See the transition plan for more details on how the attachment_id is"},{"line_number":313,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_f77fd663","line":310,"updated":"2017-03-20 10:49:37.000000000","message":"I\u0027m +1 on fetching this from Cinder every time we need to call connect_volume but I think we can stash that in the BDM for later use during disconnect_volume.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9c6ef83c7d77e92f1e6ec10d7a232327c14f352d","unresolved":false,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"When using the new API flow, we no longer need to store the connection_info,"},{"line_number":309,"context_line":"as we don\u0027t need to pass that back to Cinder. Instead we just store the"},{"line_number":310,"context_line":"attachment_id for each host the volume is attached to."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"See the transition plan for more details on how the attachment_id is"},{"line_number":313,"context_line":"populated for existing connections, and how Nova uses this to know if the"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_521ef863","line":310,"in_reply_to":"1a1ced50_f77fd663","updated":"2017-03-20 11:00:06.000000000","message":"I would rather we didn\u0027t and we fetch it for disconnect_volume. That way its Cinders problem keeping that up to date and correct. We just worry about which attachment_id to look at.\n\nThere are all those bugs about disconnect using the stashed thing during migrations, etc. I think we want to just fetch things.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"See the transition plan for more details on how the attachment_id is"},{"line_number":313,"context_line":"populated for existing connections, and how Nova uses this to know if the"},{"line_number":314,"context_line":"old or new flow should be used."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"REST API impact"},{"line_number":317,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_17de326d","line":314,"updated":"2017-03-20 10:49:37.000000000","message":"L129-L130 mean we we can drop this right?","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9c6ef83c7d77e92f1e6ec10d7a232327c14f352d","unresolved":false,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"See the transition plan for more details on how the attachment_id is"},{"line_number":313,"context_line":"populated for existing connections, and how Nova uses this to know if the"},{"line_number":314,"context_line":"old or new flow should be used."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"REST API impact"},{"line_number":317,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_123ba0d2","line":314,"in_reply_to":"1a1ced50_17de326d","updated":"2017-03-20 11:00:06.000000000","message":"Hmm, not quite, but I should re-word it. We only use the new flow when the attachment_id is present.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":322,"context_line":"---------------"},{"line_number":323,"context_line":""},{"line_number":324,"context_line":"Nova no longer needs to store the volume connection information, however it is"},{"line_number":325,"context_line":"now available at any time from the Cinder API."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"Notifications impact"},{"line_number":328,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_972ce24b","line":325,"updated":"2017-03-20 10:49:37.000000000","message":"As above, this makes sense for connect_volume but it might be overkill when calling disconnect_volume tbh.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9c6ef83c7d77e92f1e6ec10d7a232327c14f352d","unresolved":false,"context_lines":[{"line_number":322,"context_line":"---------------"},{"line_number":323,"context_line":""},{"line_number":324,"context_line":"Nova no longer needs to store the volume connection information, however it is"},{"line_number":325,"context_line":"now available at any time from the Cinder API."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"Notifications impact"},{"line_number":328,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_526358dc","line":325,"in_reply_to":"1a1ced50_972ce24b","updated":"2017-03-20 11:00:06.000000000","message":"Seems like a premature optimisation for us to save anything. We can just fetch it from Cinder instead.","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"68ce2c0b72f4093c637b1900a7a8b583effdb90c","unresolved":false,"context_lines":[{"line_number":381,"context_line":"* reboot / rebuild (get connection info from cinder using attachment_id)"},{"line_number":382,"context_line":"* live-migration"},{"line_number":383,"context_line":"* migration"},{"line_number":384,"context_line":"* evacuate"},{"line_number":385,"context_line":"* attach (this means we now expose all the previous features)"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"Note there are more steps before we can support multi-attach, but these are"}],"source_content_type":"text/x-rst","patch_set":20,"id":"1a1ced50_17cf1280","line":384,"updated":"2017-03-20 10:49:37.000000000","message":"nit - swap volume?","commit_id":"3cc80aff15a642d3f56efbda71a6bc467cf4c1e1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":48,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":49,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":50,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":51,"context_line":"* Detach the root volume of an instance (only when instance is powered off)"},{"line_number":52,"context_line":"* Use swap volume to migrate a volume between two different Cinder backends."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_2c0a7889","line":51,"range":{"start_line":51,"start_character":2,"end_line":51,"end_character":75},"updated":"2017-03-27 15:03:05.000000000","message":"Is this referring to https://blueprints.launchpad.net/nova/+spec/detach-boot-volume ? Because if so, that was never implemented and therefore we probably don\u0027t need to account for it in this spec.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":48,"context_line":"* Shelve, we want the volume to stay logically attached to the instance, but"},{"line_number":49,"context_line":"  we also need to detach it from the host when the instance is offloaded."},{"line_number":50,"context_line":"* Attach/Detach a volume attached to a shelved instance"},{"line_number":51,"context_line":"* Detach the root volume of an instance (only when instance is powered off)"},{"line_number":52,"context_line":"* Use swap volume to migrate a volume between two different Cinder backends."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"In particular, please note:"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_0e61b705","line":51,"range":{"start_line":51,"start_character":2,"end_line":51,"end_character":75},"in_reply_to":"ffe62b97_2c0a7889","updated":"2017-03-28 12:21:14.000000000","message":"Yeah, true. Its not really given any special treatment here, just noted for context. I can drop that if you want.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"fa93faeadd1cfe5b6d67d2b48850178b2dd7b28e","unresolved":false,"context_lines":[{"line_number":104,"context_line":"  volume to be ready, we fail here and delete the attachment. If this is the"},{"line_number":105,"context_line":"  first boot of the instance, that will put the instance into the ERROR state."},{"line_number":106,"context_line":"  If the volume is ready, we can continue with the attach process."},{"line_number":107,"context_line":"* (compute) use os.brick to connect to the volume backend."},{"line_number":108,"context_line":"  If there are any errors, attempt to call os.brick disconnect"},{"line_number":109,"context_line":"  (to double check it is fully cleaned up) and then remove the attachment"},{"line_number":110,"context_line":"  in Cinder. If there are any issues in the rollback, put instance into the"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_524d6ac3","line":107,"range":{"start_line":107,"start_character":16,"end_line":107,"end_character":24},"updated":"2017-03-23 21:31:34.000000000","message":"os-brick","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"fa93faeadd1cfe5b6d67d2b48850178b2dd7b28e","unresolved":false,"context_lines":[{"line_number":105,"context_line":"  first boot of the instance, that will put the instance into the ERROR state."},{"line_number":106,"context_line":"  If the volume is ready, we can continue with the attach process."},{"line_number":107,"context_line":"* (compute) use os.brick to connect to the volume backend."},{"line_number":108,"context_line":"  If there are any errors, attempt to call os.brick disconnect"},{"line_number":109,"context_line":"  (to double check it is fully cleaned up) and then remove the attachment"},{"line_number":110,"context_line":"  in Cinder. If there are any issues in the rollback, put instance into the"},{"line_number":111,"context_line":"  ERROR state."}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_92c5220c","line":108,"range":{"start_line":108,"start_character":43,"end_line":108,"end_character":51},"updated":"2017-03-23 21:31:34.000000000","message":"os-brick","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"fa93faeadd1cfe5b6d67d2b48850178b2dd7b28e","unresolved":false,"context_lines":[{"line_number":226,"context_line":"* (operator) should the source host never be started, the instances that"},{"line_number":227,"context_line":"  have been evacuated are detected in the usual way (using the migration"},{"line_number":228,"context_line":"  record created when evacuate is called). This may leave some things not"},{"line_number":229,"context_line":"  cleaned up by os.brick, but that is fairly safe, and we are in a no worse"},{"line_number":230,"context_line":"  situation than we are today."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Shelve"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_9261a214","line":229,"range":{"start_line":229,"start_character":16,"end_line":229,"end_character":24},"updated":"2017-03-23 21:31:34.000000000","message":"os-brick","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Shelve"},{"line_number":233,"context_line":"------"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"When offloading from an old host, we first add a new attachment (with no"},{"line_number":236,"context_line":"connector set) then perform a disconnect of the old attachment in the"},{"line_number":237,"context_line":"usual way. This ensures the volume is still attached to the instance,"},{"line_number":238,"context_line":"but is safely detached from the host we are offloading from. Should that"},{"line_number":239,"context_line":"detach fail, the instance should be moved into an ERROR state."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Swap Volume"},{"line_number":242,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_47291588","line":239,"range":{"start_line":235,"start_character":0,"end_line":239,"end_character":62},"updated":"2017-03-27 15:03:05.000000000","message":"It might be worth talking about what happens during unshelve since that\u0027s a bit of an odd case where we have a volume attachment relating the instance and volume but without any host context (the connector), so on unshelve we need to re-use and update that attachment once we unshelve and build the instance on a new host.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":232,"context_line":"Shelve"},{"line_number":233,"context_line":"------"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"When offloading from an old host, we first add a new attachment (with no"},{"line_number":236,"context_line":"connector set) then perform a disconnect of the old attachment in the"},{"line_number":237,"context_line":"usual way. This ensures the volume is still attached to the instance,"},{"line_number":238,"context_line":"but is safely detached from the host we are offloading from. Should that"},{"line_number":239,"context_line":"detach fail, the instance should be moved into an ERROR state."},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Swap Volume"},{"line_number":242,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_2e3d9bdc","line":239,"range":{"start_line":235,"start_character":0,"end_line":239,"end_character":62},"in_reply_to":"ffe62b97_47291588","updated":"2017-03-28 12:21:14.000000000","message":"Good point, I should add that.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"f6207c64b692d3a0ab1bed2abd9b36e51a8a8426","unresolved":false,"context_lines":[{"line_number":255,"context_line":"      That means cinder has created the new volume, and calls the Nova API on"},{"line_number":256,"context_line":"      the user\u0027s behalf."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_d3172f51","line":258,"range":{"start_line":258,"start_character":12,"end_line":258,"end_character":18},"updated":"2017-03-27 13:08:47.000000000","message":"Is this an update here? The last, summary, bullet point says we created a new attachment to the new volume.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f871f13fb72dbfab09476d6e108284da48ddb049","unresolved":false,"context_lines":[{"line_number":255,"context_line":"      That means cinder has created the new volume, and calls the Nova API on"},{"line_number":256,"context_line":"      the user\u0027s behalf."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_e784a60e","line":258,"range":{"start_line":258,"start_character":12,"end_line":258,"end_character":18},"in_reply_to":"ffe62b97_d3172f51","updated":"2017-03-27 15:10:49.000000000","message":"Also, how do we update an old-style attachment during swap volume if the attachment never existed using the new style flow in the first place? Is this all predicated on bdm.attachment_id being set? If so, I\u0027m missing that important part.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":255,"context_line":"      That means cinder has created the new volume, and calls the Nova API on"},{"line_number":256,"context_line":"      the user\u0027s behalf."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_310bbe24","line":258,"range":{"start_line":258,"start_character":12,"end_line":258,"end_character":18},"in_reply_to":"ffe62b97_e784a60e","updated":"2017-03-28 12:21:14.000000000","message":"That attachment should be created in the API, I missed that out here, oops.\n\nI should be clear, this flow only applies when attachment_id is present in the BDM.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"fa93faeadd1cfe5b6d67d2b48850178b2dd7b28e","unresolved":false,"context_lines":[{"line_number":256,"context_line":"      the user\u0027s behalf."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"},{"line_number":262,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_f6e28801","line":259,"range":{"start_line":259,"start_character":12,"end_line":259,"end_character":20},"updated":"2017-03-23 21:31:34.000000000","message":"os-brick","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"},{"line_number":262,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":263,"context_line":"  in libvirt this is via a rebase operation"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_0742ed10","line":260,"range":{"start_line":260,"start_character":39,"end_line":260,"end_character":45},"updated":"2017-03-27 15:03:05.000000000","message":"s/detach/attach/ ?","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":259,"context_line":"* (compute) os.brick connect the new volume. If there is an error we"},{"line_number":260,"context_line":"  deal with this like a failure during detach, and delete the"},{"line_number":261,"context_line":"  attachment to the new volume"},{"line_number":262,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":263,"context_line":"  in libvirt this is via a rebase operation"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_3124deae","line":260,"range":{"start_line":260,"start_character":39,"end_line":260,"end_character":45},"in_reply_to":"ffe62b97_0742ed10","updated":"2017-03-28 12:21:14.000000000","message":"ah, yes, whoops.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":262,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":263,"context_line":"  in libvirt this is via a rebase operation"},{"line_number":264,"context_line":"* (compute) once the copy is complete, we detach uuid-old from instance"},{"line_number":265,"context_line":"* (compute) update BDM so it has the new attachment_id for uuid-new"},{"line_number":266,"context_line":"* (compute) once the old volume is detached, we do an os.brick disconnect"},{"line_number":267,"context_line":"* (compute) if that worked, we call cinder\u0027s migrate_volume_completion"},{"line_number":268,"context_line":"  with (uuid-new, uuid-old). If disconnect failed, we put the instance into"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_87e5ddaa","line":265,"range":{"start_line":265,"start_character":0,"end_line":265,"end_character":67},"updated":"2017-03-27 15:03:05.000000000","message":"We said the last change in the series was going to be volume attach in the API since that\u0027s when we start setting bdm.attachment_id and that triggers how detach works (or anything that deals with a new style BDM attachment). Since swap volume is sort of the same thing (volume attach), are we going to do that in the same change as the volume attach support? Or can swap volume be done separately?\n\nThe thing I worry about here is we set the attachment_id on the swap volume bdm and all of a sudden the detach volume flow is going to think this is a new style attachment and can detach it the new way - is that going to work? Or should we only set the bdm.attachment_id during swap volume if the cinder API version is new enough?","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":262,"context_line":"* (compute) Nova copies content of volume uuid-old to volume uuid-new,"},{"line_number":263,"context_line":"  in libvirt this is via a rebase operation"},{"line_number":264,"context_line":"* (compute) once the copy is complete, we detach uuid-old from instance"},{"line_number":265,"context_line":"* (compute) update BDM so it has the new attachment_id for uuid-new"},{"line_number":266,"context_line":"* (compute) once the old volume is detached, we do an os.brick disconnect"},{"line_number":267,"context_line":"* (compute) if that worked, we call cinder\u0027s migrate_volume_completion"},{"line_number":268,"context_line":"  with (uuid-new, uuid-old). If disconnect failed, we put the instance into"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_1142fa3e","line":265,"range":{"start_line":265,"start_character":0,"end_line":265,"end_character":67},"in_reply_to":"ffe62b97_87e5ddaa","updated":"2017-03-28 12:21:14.000000000","message":"yeah, we need a parallel path here too.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"3f4281ada7bfe072296189d43c7174b77bb875c3","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  same uuid as the old volume had. If someone called Nova, we get back"},{"line_number":274,"context_line":"  uuid-new, and we update the BDM to reflect the change."},{"line_number":275,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":276,"context_line":"  and deleted the attachment to the old volume."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":279,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_56bf9860","line":276,"updated":"2017-03-27 10:11:23.000000000","message":"This is less of a change than I was hoping for (switching to attachment id at the api level), but I agree we risk any kind of improvement if we try to do everything up front. A swap volume improvement probably needs its own separate spec.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2e67101228ca0f8d0ac71aa3ea15aabd12266599","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  same uuid as the old volume had. If someone called Nova, we get back"},{"line_number":274,"context_line":"  uuid-new, and we update the BDM to reflect the change."},{"line_number":275,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":276,"context_line":"  and deleted the attachment to the old volume."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":279,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_7cbb9d0d","line":276,"in_reply_to":"ffe62b97_56bf9860","updated":"2017-03-27 10:33:16.000000000","message":"Yeah, I think we need to do that thing too, but yeah, lets deal with that later as a \"multi-attach\" enablement thingy.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  same uuid as the old volume had. If someone called Nova, we get back"},{"line_number":274,"context_line":"  uuid-new, and we update the BDM to reflect the change."},{"line_number":275,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":276,"context_line":"  and deleted the attachment to the old volume."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":279,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_a7cc6161","line":276,"in_reply_to":"ffe62b97_7cbb9d0d","updated":"2017-03-27 15:03:05.000000000","message":"I\u0027m glad you were both thinking this, because the steps above really sound like cludging together multiple attachments to a single attachment by updating the single BDM, which seems inefficient and complicated when we could just treat this like a migration kind of (attach new volume on host, if ok, detach old volume from host). I\u0027m not totally sure why we\u0027re not leveraging the new model for swap volume but we will for migrations, but I\u0027m probably missing some reason why this is too complicated to lump in here. It might be worth noting that this is not the idea flow and we want to improve this later (and maybe include notes on what that later looks like).","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2910961d9b299c5241ce23e8084a6f6520bda513","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  same uuid as the old volume had. If someone called Nova, we get back"},{"line_number":274,"context_line":"  uuid-new, and we update the BDM to reflect the change."},{"line_number":275,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":276,"context_line":"  and deleted the attachment to the old volume."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":279,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_15865f14","line":276,"in_reply_to":"ffe62b97_919ccac0","updated":"2017-03-28 14:42:42.000000000","message":"I wrote this before realizing this was all new flow stuff based on if bdm.attachment_id was set. As noted, we should be clear about that.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  same uuid as the old volume had. If someone called Nova, we get back"},{"line_number":274,"context_line":"  uuid-new, and we update the BDM to reflect the change."},{"line_number":275,"context_line":"* so on success we have created a new attachment to the new volume"},{"line_number":276,"context_line":"  and deleted the attachment to the old volume."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Note: it is assumed if a volume is multi-attach, the swap operation will fail"},{"line_number":279,"context_line":"and not be allowed. That will be true in either the Cinder or Nova started"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_919ccac0","line":276,"in_reply_to":"ffe62b97_a7cc6161","updated":"2017-03-28 12:21:14.000000000","message":"This is using the new flow, just like migration. I am confused now.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"773893445e76bf31943bd2e7c43fd77fe0dec90b","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_585172d7","line":288,"updated":"2017-03-21 17:16:39.000000000","message":"Are we going to use the list of attachment_ids returned by cinder in connection_info[\u0027shared_connections_by_attachment\u0027] [1] in order to decide if the connection is shared or leave that up to os-brick to decide as we do today?\n\n[1] https://review.openstack.org/#/c/361512/8/specs/ocata/add-new-attach-apis.rst@108","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"3f4281ada7bfe072296189d43c7174b77bb875c3","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_7644dcb7","line":288,"in_reply_to":"1a1ced50_585172d7","updated":"2017-03-27 10:11:23.000000000","message":"I\u0027m personally convinced we MUST leave this to os-brick, as this is the only place we can do this race-free.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c66643c2449fe52e536e2750b9f0dbe728e4413f","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_8ba8f121","line":288,"in_reply_to":"1a1ced50_585172d7","updated":"2017-03-21 19:59:40.000000000","message":"Probably should drop this bit I guess, now we are punting on it.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2910961d9b299c5241ce23e8084a6f6520bda513","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_b5c21333","line":288,"in_reply_to":"ffe62b97_11de7a6c","updated":"2017-03-28 14:42:42.000000000","message":"\u003e I want os-brick to pass the state to cinder\n\nBut os-brick is stateless, unless I\u0027m misunderstanding, but I\u0027m also OK with punting on this for now if it\u0027s only an issue once we get to supporting multiattach, which it says in here that we aren\u0027t yet. This spec is all about groundwork.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_11de7a6c","line":288,"in_reply_to":"ffe62b97_24bdecd7","updated":"2017-03-28 12:21:14.000000000","message":"Basically we decided to get agreement on moving forward here, if we should not fix the shared volume backend connections as part of this spec.\n\nWe don\u0027t need a global DLM for my suggestion, I believe it still works. Our disagreement is more about who owns the state, I want os-brick to pass the state to cinder, and then pass it back to us when needed, basically it goes in the connector along with everything else. But I there could be something else big that I am missing here.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2e67101228ca0f8d0ac71aa3ea15aabd12266599","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_bcf485d0","line":288,"in_reply_to":"ffe62b97_7644dcb7","updated":"2017-03-27 10:33:16.000000000","message":"So we totally need to catch up on my idea on that, to compare with a pure os-brick solution. Either way, the key bit is it should be well defined solution, and it should actually work. Almost anything that meets that need would keep me happy.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"f6207c64b692d3a0ab1bed2abd9b36e51a8a8426","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_d6f6fdf9","line":288,"in_reply_to":"ffe62b97_bcf485d0","updated":"2017-03-27 13:08:47.000000000","message":"I think so far our main objective against os-brick that it is completely stateless, hence not having all the info to perform what we need. We can bring this up on the weekly meetings if we feel it needs to be further discussed.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Today there are problems where you have a volume backend connection shared"},{"line_number":287,"context_line":"between multiple volumes as you need to ensure you don\u0027t race when deciding"},{"line_number":288,"context_line":"if you need to connect or disconnect to the volume backend."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Alternatives"},{"line_number":291,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_24bdecd7","line":288,"in_reply_to":"ffe62b97_d6f6fdf9","updated":"2017-03-27 15:03:05.000000000","message":"John:\n\n\u003e Probably should drop this bit I guess, now we are punting on it.\n\nWhat does this mean? Originally I think you were planning on doing locks in the compute host during detach to see if it were safe to call disconnect_volume in os-brick only when there was a single connection left in the shared connection case, but I think mdbooth has pointed out some issues with that (lack of global DLM is probably the main one). So what does \u0027punt\u0027 mean here? We\u0027re just going to always call disconnect in os-brick when we detach, regardless of if we have shared connections or not?","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":348,"context_line":"Performance Impact"},{"line_number":349,"context_line":"------------------"},{"line_number":350,"context_line":""},{"line_number":351,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":352,"context_line":"all drivers."},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"Other deployer impact"},{"line_number":355,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_84795830","line":352,"range":{"start_line":351,"start_character":0,"end_line":352,"end_character":12},"updated":"2017-03-27 15:03:05.000000000","message":"We may get more chatty with cinder if we need to get the connection_info from Cinder rather than the BDM, but hopefully that\u0027s not often.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":348,"context_line":"Performance Impact"},{"line_number":349,"context_line":"------------------"},{"line_number":350,"context_line":""},{"line_number":351,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":352,"context_line":"all drivers."},{"line_number":353,"context_line":""},{"line_number":354,"context_line":"Other deployer impact"},{"line_number":355,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_510c02eb","line":352,"range":{"start_line":351,"start_character":0,"end_line":352,"end_character":12},"in_reply_to":"ffe62b97_84795830","updated":"2017-03-28 12:21:14.000000000","message":"I thought it was APIs we had to call anyways, but that might not be true.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":385,"context_line":"The overall strategy is that we implement new style attach last, and all"},{"line_number":386,"context_line":"the other operations depend on the attachment_id being in the BDM, that will"},{"line_number":387,"context_line":"not be true until the attach code is merged."},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"* use Cinder v3 API"},{"line_number":390,"context_line":"* detect if the microversion that includes the new BDM support is present"},{"line_number":391,"context_line":"* detach a new style BDM/volume attach"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_c403e072","line":388,"updated":"2017-03-27 15:03:05.000000000","message":"Shelve/unshelve isn\u0027t in this list.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":385,"context_line":"The overall strategy is that we implement new style attach last, and all"},{"line_number":386,"context_line":"the other operations depend on the attachment_id being in the BDM, that will"},{"line_number":387,"context_line":"not be true until the attach code is merged."},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"* use Cinder v3 API"},{"line_number":390,"context_line":"* detect if the microversion that includes the new BDM support is present"},{"line_number":391,"context_line":"* detach a new style BDM/volume attach"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_d118121f","line":388,"in_reply_to":"ffe62b97_c403e072","updated":"2017-03-28 12:21:14.000000000","message":"oops, yes.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":393,"context_line":"* live-migration"},{"line_number":394,"context_line":"* migration"},{"line_number":395,"context_line":"* evacuate"},{"line_number":396,"context_line":"* swap volume"},{"line_number":397,"context_line":"* attach (this means we now expose all the previous features)"},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Note there are more steps before we can support multi-attach, but these are"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_a4d1fcfd","line":396,"range":{"start_line":396,"start_character":0,"end_line":396,"end_character":13},"updated":"2017-03-27 15:03:05.000000000","message":"As noted above, your steps for doing swap volume include setting the bdm.attachment_id, which is going to make detaching a swapped in volume (uuid-new) go down the new detach flow and I\u0027m not sure if that was intentional.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"773893445e76bf31943bd2e7c43fd77fe0dec90b","unresolved":false,"context_lines":[{"line_number":400,"context_line":"left for future specs:"},{"line_number":401,"context_line":""},{"line_number":402,"context_line":"* migrate old BDMs to the new BDM flow"},{"line_number":403,"context_line":"* add explicit support for shared backend connections"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"},{"line_number":406,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_18f9bac7","line":403,"updated":"2017-03-21 17:16:39.000000000","message":"Ah so shared connections are not something we want to address as part of this spec?","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"3f4281ada7bfe072296189d43c7174b77bb875c3","unresolved":false,"context_lines":[{"line_number":400,"context_line":"left for future specs:"},{"line_number":401,"context_line":""},{"line_number":402,"context_line":"* migrate old BDMs to the new BDM flow"},{"line_number":403,"context_line":"* add explicit support for shared backend connections"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"},{"line_number":406,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_d6604804","line":403,"in_reply_to":"1a1ced50_0bb40180","updated":"2017-03-27 10:11:23.000000000","message":"As I said above, I think shared connections are a driver-level problem. I think we\u0027re good to go with shared connections without changes to this spec.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c66643c2449fe52e536e2750b9f0dbe728e4413f","unresolved":false,"context_lines":[{"line_number":400,"context_line":"left for future specs:"},{"line_number":401,"context_line":""},{"line_number":402,"context_line":"* migrate old BDMs to the new BDM flow"},{"line_number":403,"context_line":"* add explicit support for shared backend connections"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"},{"line_number":406,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":21,"id":"1a1ced50_0bb40180","line":403,"in_reply_to":"1a1ced50_18f9bac7","updated":"2017-03-21 19:59:40.000000000","message":"Yeah, basically, I am punting on them for now.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"3f4281ada7bfe072296189d43c7174b77bb875c3","unresolved":false,"context_lines":[{"line_number":401,"context_line":""},{"line_number":402,"context_line":"* migrate old BDMs to the new BDM flow"},{"line_number":403,"context_line":"* add explicit support for shared backend connections"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"},{"line_number":406,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":407,"context_line":""}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_991d5368","line":404,"updated":"2017-03-27 10:11:23.000000000","message":"The biggest barrier I see to multi-attach is volume migration, and that\u0027s cinder\u0027s problem. TBH I can\u0027t currently think how that would ever be practical. If Nova considers swap-volume to be a single instance operation, it really doesn\u0027t matter (to Nova) if the volume is also attached elsewhere.\n\nI think this problem is effectively solved if cinder volume migration refuses to migrate a volume with multiple attachments, and Nova doesn\u0027t concern itself with the problem at all.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2e67101228ca0f8d0ac71aa3ea15aabd12266599","unresolved":false,"context_lines":[{"line_number":401,"context_line":""},{"line_number":402,"context_line":"* migrate old BDMs to the new BDM flow"},{"line_number":403,"context_line":"* add explicit support for shared backend connections"},{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Dependencies"},{"line_number":406,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":407,"context_line":""}],"source_content_type":"text/x-rst","patch_set":21,"id":"ffe62b97_9c9f815e","line":404,"in_reply_to":"ffe62b97_991d5368","updated":"2017-03-27 10:33:16.000000000","message":"I am thinking the same right now.\n\nMaybe there is a special case that works, MRSW volumes, where cinder knows who the single writer is. its always the writer that does the copy, and the readers get disconnected for the duration of copy maybe. Sometimes there is no writer, so Cinder has to do the copy. (shrugs)","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f26016eff9e84f912698fef97f657854699fd1f0","unresolved":false,"context_lines":[{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."},{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Documentation Impact"},{"line_number":420,"context_line":"\u003d\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":21,"id":"ffe62b97_a4db3ceb","line":417,"range":{"start_line":416,"start_character":0,"end_line":417,"end_character":65},"updated":"2017-03-27 15:03:05.000000000","message":"I didn\u0027t think we were going to have any config for doing the old flow. If you make the attachment with the new flow, you trigger the detach with the new flow too. If the attachment was made with the old flow, then the detach happens with the old flow. I think grenade will cover this for us, as long as we attach a volume to an instance on the old side of grenade and detach it on the new side, we should have this covered. I don\u0027t think we actually do that today though:\n\nhttps://github.com/openstack-dev/grenade/blob/master/projects/60_nova/resources.sh\n\nSo that\u0027s something we\u0027d need to add to grenade. We should make a note of that here.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b8e52f1793a7b672dbac4623328d894783680671","unresolved":false,"context_lines":[{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."},{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Documentation Impact"},{"line_number":420,"context_line":"\u003d\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":21,"id":"ffe62b97_e7cca6bd","line":417,"range":{"start_line":416,"start_character":0,"end_line":417,"end_character":65},"in_reply_to":"ffe62b97_a4db3ceb","updated":"2017-03-27 15:07:30.000000000","message":"Grenade does create a BFV server during the cinder run:\n\nhttps://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resources.sh#L130\n\nBut that\u0027s a bit different since there is no explicit detach on the new side. So I think we still need to add something to grenade to attach a volume to a server on the old side (using old flow) and detach on the new side (using old flow).","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"fe2670167b6b4b18703d4460ddad3ca1fabe79b9","unresolved":false,"context_lines":[{"line_number":413,"context_line":""},{"line_number":414,"context_line":"We need to functionally test both old and new Cinder interactions."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"The will add configuration to always use the old flow, so we can keep testing"},{"line_number":417,"context_line":"both the old a new code paths, until we delete the old code path."},{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Documentation Impact"},{"line_number":420,"context_line":"\u003d\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":21,"id":"ffe62b97_51b3e20a","line":417,"range":{"start_line":416,"start_character":0,"end_line":417,"end_character":65},"in_reply_to":"ffe62b97_e7cca6bd","updated":"2017-03-28 12:21:14.000000000","message":"yeah, this bit hasn\u0027t been updated, I will update that.","commit_id":"304d0cbf375a180f429d0990db6e9df040d933f6"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"044424e5d18500e974f0420387df46d362311f5f","unresolved":false,"context_lines":[{"line_number":268,"context_line":"      the user\u0027s behalf."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"* (api) create new attachment for the volume uuid-new, fail API call if we"},{"line_number":271,"context_line":"  can\u0027t create that attachment"},{"line_number":272,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":273,"context_line":"* (compute) os-brick connect the new volume. If there is an error we"},{"line_number":274,"context_line":"  deal with this like a failure during attach, and delete the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"ffe62b97_e86a037f","line":271,"updated":"2017-03-28 14:05:26.000000000","message":"I think we\u0027d do this even if the existing BDM didn\u0027t have attachment_id, right? If BDM doesn\u0027t have attachment_id, then the detach side of this call will follow the old flow, but I think the attach side would always follow the new flow.","commit_id":"d85e4b58d20cf9acf98c267529425134e64de9b8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6827b44ffb91dd5b2403bc7b6205bbc541359330","unresolved":false,"context_lines":[{"line_number":268,"context_line":"      the user\u0027s behalf."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"* (api) create new attachment for the volume uuid-new, fail API call if we"},{"line_number":271,"context_line":"  can\u0027t create that attachment"},{"line_number":272,"context_line":"* (compute) update cinder attachment with connector for uuid-new"},{"line_number":273,"context_line":"* (compute) os-brick connect the new volume. If there is an error we"},{"line_number":274,"context_line":"  deal with this like a failure during attach, and delete the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"ffe62b97_d553576a","line":271,"in_reply_to":"ffe62b97_e86a037f","updated":"2017-03-28 14:54:38.000000000","message":"That seems reasonable.\n\nOh I see you\u0027re pointing this out because of the new statement about on L256 prompted by my comments in the last patch set. I think you\u0027re right that we can attach with the new flow for the volume we\u0027re swapping TO, and detach with the old flow for the volume we\u0027re swapping FROM. I don\u0027t need a change to the spec though, we can just sort this out in the actual change.\n\n**OR**\n\nMaybe the reason John wrote it this way is if we only do this new flow if the existing attachment has bdm.attachment_id set, then we don\u0027t have to do the swap volume and volume attach API changes at the same time, which would be smart. Then we can plan the changes such that we do swap volume before the very final piece which is volume attach which sets the bdm.attachment_id.","commit_id":"d85e4b58d20cf9acf98c267529425134e64de9b8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6827b44ffb91dd5b2403bc7b6205bbc541359330","unresolved":false,"context_lines":[{"line_number":359,"context_line":""},{"line_number":360,"context_line":"There should be no impact to performance. The focus here is stability across"},{"line_number":361,"context_line":"all drivers. There may slightly more API calls between Nova and Cinder, but it"},{"line_number":362,"context_line":"is not expected to be significantly impact performance."},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"Other deployer impact"},{"line_number":365,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":22,"id":"ffe62b97_b8320af1","line":362,"range":{"start_line":362,"start_character":19,"end_line":362,"end_character":21},"updated":"2017-03-28 14:54:38.000000000","message":"s/be//","commit_id":"d85e4b58d20cf9acf98c267529425134e64de9b8"}]}