)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Sean Mooney \u003csean.k.mooney@intel.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2017-10-02 22:57:37 +0100"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"WIP: Use neutron\u0027s new port binding API"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Need to audit the code for where to switch the calls over."},{"line_number":10,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"7f515b1d_fc500661","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":5},"updated":"2017-10-03 22:55:10.000000000","message":"Remove","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"WIP: Use neutron\u0027s new port binding API"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Need to audit the code for where to switch the calls over."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"blueprint neutron-new-port-binding-api"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"7f515b1d_7ccad61a","line":9,"range":{"start_line":9,"start_character":1,"end_line":9,"end_character":58},"updated":"2017-10-03 22:55:10.000000000","message":"I think we need a proper description","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"321559ca1ed264a9b992683769b2698c8d08fd35","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Use neutron\u0027s new port binding API"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"- This spec address the consumption of neutron\u0027s"},{"line_number":10,"context_line":"  new port binding api in nova."},{"line_number":11,"context_line":"  https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":12,"context_line":"- This proposed change will modify nova to use multiple port binding"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f515b1d_2a5ee211","line":9,"range":{"start_line":9,"start_character":12,"end_line":9,"end_character":19},"updated":"2017-10-06 23:09:22.000000000","message":"addresses","commit_id":"15b5b7fa2a52decceb71564913ae79cca9f49573"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4f7233448630ab278d542b30422294258d3101e9","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Use neutron\u0027s new port binding API"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"- This spec address the consumption of neutron\u0027s"},{"line_number":10,"context_line":"  new port binding api in nova."},{"line_number":11,"context_line":"  https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":12,"context_line":"- This proposed change will modify nova to use multiple port binding"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f515b1d_005d1e46","line":9,"range":{"start_line":9,"start_character":12,"end_line":9,"end_character":19},"in_reply_to":"7f515b1d_2a5ee211","updated":"2017-10-09 14:59:06.000000000","message":"Done","commit_id":"15b5b7fa2a52decceb71564913ae79cca9f49573"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":11,"context_line":"  https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":12,"context_line":"- This proposed change will modify nova to use multiple port binding"},{"line_number":13,"context_line":"  when performing actions that will move a VM between hosts."},{"line_number":14,"context_line":"  e.g. live migration, evacuate, resize ..."},{"line_number":15,"context_line":"- This proposed change will introduce a parallel set of internal APIs"},{"line_number":16,"context_line":"  that map to the action required in each stage of the move operation."},{"line_number":17,"context_line":"  That will allow the old workflow to be left unmodified until"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"7f515b1d_d7690725","line":14,"range":{"start_line":14,"start_character":23,"end_line":14,"end_character":31},"updated":"2017-10-09 20:26:18.000000000","message":"Hmm, during evacuate the source host is presumed dead and fenced, so likely not something we care about as much here.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":11,"context_line":"  https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":12,"context_line":"- This proposed change will modify nova to use multiple port binding"},{"line_number":13,"context_line":"  when performing actions that will move a VM between hosts."},{"line_number":14,"context_line":"  e.g. live migration, evacuate, resize ..."},{"line_number":15,"context_line":"- This proposed change will introduce a parallel set of internal APIs"},{"line_number":16,"context_line":"  that map to the action required in each stage of the move operation."},{"line_number":17,"context_line":"  That will allow the old workflow to be left unmodified until"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"7f515b1d_17d2ffd1","line":14,"range":{"start_line":14,"start_character":33,"end_line":14,"end_character":39},"updated":"2017-10-09 20:26:18.000000000","message":"I don\u0027t think we care as much about this for resize, at least initially, since it\u0027s a cold migration and the user should expect some downtime while the instance is moving.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7dabcfaa0c14b26d87d582d1b2603ae86e7145c2","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Sean Mooney \u003csean.k.mooney@intel.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2017-10-19 14:18:02 +0100"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Use neutron\u0027s new port binding API"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"- This spec addresses the consumption of neutron\u0027s"},{"line_number":10,"context_line":"  new port binding api in nova."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":14,"id":"3f4b6375_74940945","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":34},"updated":"2017-10-19 14:41:39.000000000","message":"Given the confusion with the bw provider spec, we should add \"for live migration\" to the end of this title.","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"}],"specs/ocata/approved/neutron-new-port-binding-api.rst":[{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  live-migration"},{"line_number":24,"context_line":"* In many cases the two hosts need a very different binding on source host"},{"line_number":25,"context_line":"  vs destination host, but thats not possibly today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":28,"context_line":"  possible, its good to get most things ready before the switchover is quite."},{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_69ac478c","line":26,"updated":"2016-10-04 07:53:27.000000000","message":"I think it makes sense to also mention the case, where folks want to migrate from the ovs-hybrid plug (using iptables fw driver) to the ovs normal plug (using new ovs conntrackd fw driver)","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"31f78a04dedb640b2d427b82c0a68e783de8ce65","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  live-migration"},{"line_number":24,"context_line":"* In many cases the two hosts need a very different binding on source host"},{"line_number":25,"context_line":"  vs destination host, but thats not possibly today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":28,"context_line":"  possible, its good to get most things ready before the switchover is quite."},{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_5626face","line":26,"in_reply_to":"1a95cdbc_241173ad","updated":"2016-10-05 16:13:10.000000000","message":"but this will not be enabled by this bp - it falls into the same category with the firewalldriver stuff, cause modifications to the domain xml are required..","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"20998471ee4b2f11ed4a0eff0b956bc1882db2d6","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  live-migration"},{"line_number":24,"context_line":"* In many cases the two hosts need a very different binding on source host"},{"line_number":25,"context_line":"  vs destination host, but thats not possibly today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":28,"context_line":"  possible, its good to get most things ready before the switchover is quite."},{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_241173ad","line":26,"in_reply_to":"1a95cdbc_41ad9630","updated":"2016-10-04 16:00:54.000000000","message":"ok, makes, sense as this is an extra effort!","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  live-migration"},{"line_number":24,"context_line":"* In many cases the two hosts need a very different binding on source host"},{"line_number":25,"context_line":"  vs destination host, but thats not possibly today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":28,"context_line":"  possible, its good to get most things ready before the switchover is quite."},{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_41ad9630","line":26,"in_reply_to":"3a98d1f4_69ac478c","updated":"2016-10-04 14:35:42.000000000","message":"I am really trying to ignore that use case for now, see alternatives.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9673b32b11e78b40cce36b4cfefd140e7690e822","unresolved":false,"context_lines":[{"line_number":25,"context_line":"  vs destination host, but thats not possibly today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":28,"context_line":"  possible, its good to get most things ready before the switchover is quite."},{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"More details can be found in the neutron spec:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa6399be_c1c2cde8","line":28,"updated":"2016-10-14 03:03:02.000000000","message":"broken sentence?","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":29,"context_line":"  We have added a short term hack for DVR, but lets do it properly."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"More details can be found in the neutron spec:"},{"line_number":32,"context_line":"https://review.openstack.org/#/c/309416"},{"line_number":33,"context_line":"TODO - update to the merged link."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"When thinking about this spec, we should be clear on the difference between:"},{"line_number":36,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_0be06125","line":33,"range":{"start_line":32,"start_character":0,"end_line":33,"end_character":33},"updated":"2017-10-03 22:55:10.000000000","message":"This is the merged Neutron spec: https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9673b32b11e78b40cce36b4cfefd140e7690e822","unresolved":false,"context_lines":[{"line_number":62,"context_line":"* Shelve, we want the port to stay logically attached to the instance, but"},{"line_number":63,"context_line":"  we need to detach it from the current host when the instance is offloaded."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Proposed change"},{"line_number":66,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"We decide whether to use the new or old API flow, based on the available"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa6399be_1c150e3f","line":65,"updated":"2016-10-14 03:03:02.000000000","message":"At the mid-cycle we talked about having a versioned object based approach for exchanging vif details over the wire between Nova and Neutron. Are we going to make that a prerequisite for this approach or are we assuming that the Neutron-side API is going to expose vif details the \u0027usual\u0027 way?","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":65,"context_line":"Proposed change"},{"line_number":66,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"We decide whether to use the new or old API flow, based on the available"},{"line_number":69,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"In two cycles time, the old interaction model should removed. We should keep"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_49114b51","line":68,"updated":"2016-10-04 07:53:27.000000000","message":"Not sure if checking for the availability of this exentsion is sufficient. Probably some mechanism drivers won\u0027t support that new flow right from the beginning. In this case, we would need to ask the extension if the configured mech drivers do support the new flow.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":65,"context_line":"Proposed change"},{"line_number":66,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"We decide whether to use the new or old API flow, based on the available"},{"line_number":69,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"In two cycles time, the old interaction model should removed. We should keep"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_a149fa90","line":68,"in_reply_to":"3a98d1f4_49114b51","updated":"2016-10-04 14:35:42.000000000","message":"OK, we need those details in the neutron spec.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9673b32b11e78b40cce36b4cfefd140e7690e822","unresolved":false,"context_lines":[{"line_number":68,"context_line":"We decide whether to use the new or old API flow, based on the available"},{"line_number":69,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":72,"context_line":"this in mind in how the code is structured. Given we are also looking at"},{"line_number":73,"context_line":"removing nova-network, we should see if this can be added as a new set of"},{"line_number":74,"context_line":"network API calls, that are only for neutron, making the exiting calls needed"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa6399be_812a958e","line":71,"updated":"2016-10-14 03:03:02.000000000","message":"I am thinking that the existing portbinding handling code will stay in place, it\u0027s the use of the migrationbinding that will be introduced and used in case it\u0027s available.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9673b32b11e78b40cce36b4cfefd140e7690e822","unresolved":false,"context_lines":[{"line_number":69,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"In two cycles time, the old interaction model should removed. We should keep"},{"line_number":72,"context_line":"this in mind in how the code is structured. Given we are also looking at"},{"line_number":73,"context_line":"removing nova-network, we should see if this can be added as a new set of"},{"line_number":74,"context_line":"network API calls, that are only for neutron, making the exiting calls needed"},{"line_number":75,"context_line":"for nova-network be no-ops for Neutron. We should have an explicit call for"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa6399be_01476577","line":72,"updated":"2016-10-14 03:03:02.000000000","message":"I think the situation here is a bit more thorny. The new API may require backend compliance and that may take longer than 2 cycles in order to happen. If we are this strict we may risk breaking these backends if we drop the old port binding workflow \u0027too soon\u0027. I am not saying we shouldn\u0027t do that, but we can\u0027t give it for granted that all plugins adopt the new API asap.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"20998471ee4b2f11ed4a0eff0b956bc1882db2d6","unresolved":false,"context_lines":[{"line_number":81,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":82,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":83,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":84,"context_line":"the Ocata timeframe, so we release with the new workflow on by default."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Lets consider live-migration and what the calls to neutron will look like:"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_045ab783","line":84,"updated":"2016-10-04 16:00:54.000000000","message":"Wow, I\u0027m not even sure if Neutron is able to finish its implementation in Ocata...","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Lets consider live-migration and what the calls to neutron will look like:"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"* add port binding on destination host, in pre_live_migration phase"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"  * check port binding was a success, if not, fail live-migration"},{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_89d513e6","line":88,"updated":"2016-10-04 07:53:27.000000000","message":"should we state here, that this makes the short time hack using the vif profile for notification of a live migration obsolete?","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Lets consider live-migration and what the calls to neutron will look like:"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"* add port binding on destination host, in pre_live_migration phase"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"  * check port binding was a success, if not, fail live-migration"},{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_215eca45","line":88,"in_reply_to":"3a98d1f4_89d513e6","updated":"2016-10-04 14:35:42.000000000","message":"yeah, good call, we should add that.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_e9a93791","line":94,"updated":"2016-10-04 07:53:27.000000000","message":"need to be careful here, as vif plug event only occurs when ovs-hybrid plug is used. Other plugs, like ovs \"normal\" (with new fw driver), linuxbridge and so on only send that event after the tap device occurred on the system. \n\nThis is already reflected in the Nova code today. Just mentioning this - as this paragraph sounds like it is the general approach for all cases","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"31f78a04dedb640b2d427b82c0a68e783de8ce65","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_d94ddb73","line":94,"in_reply_to":"1a95cdbc_04b0f7dc","updated":"2016-10-05 16:13:10.000000000","message":"Just realized - the vif-plug event thing on migration has still not yet merged :/\n\nhttps://review.openstack.org/246910","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"20998471ee4b2f11ed4a0eff0b956bc1882db2d6","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_04b0f7dc","line":94,"in_reply_to":"1a95cdbc_84316cef","updated":"2016-10-04 16:00:54.000000000","message":"for ovs-hybrid, the \"tap device\" is a veth pair that connects the ovs to the linuxbridge. This gets created during plug operation. the ovs agent starts working and this ribles down to the vif-plugged event. The tap device itself gets created later on by libvirt, but that\u0027s not recognized by the ovs agent anymore...\n\nin the lb case for example, the plug operation does not do anything (or nothing of relevance). there it\u0027s really the creation of the tap device by libvirt that triggers the agent. So we first need to start the migration, before a vif-plug event can occur...\n\nHmm, probably I should start working on the nova-neutron sequence diagram again, that should one day be merged into the neutron devref... it\u0027s laying around since a long time and does not yet contain those details https://review.openstack.org/#/c/274097/","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":91,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_84316cef","line":94,"in_reply_to":"3a98d1f4_e9a93791","updated":"2016-10-04 14:35:42.000000000","message":"hmm, so I am missing a detail here. When does the tap device get created during live-migration? only when the VM goes active on the destination? I should ask the lib-virt folks.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* Start live-migrate as before"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_49930b5b","line":95,"updated":"2016-10-04 07:53:27.000000000","message":"what do you mean by routing for that event could be tricky?","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"20998471ee4b2f11ed4a0eff0b956bc1882db2d6","unresolved":false,"context_lines":[{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* Start live-migrate as before"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_84c40741","line":95,"in_reply_to":"1a95cdbc_040e3c34","updated":"2016-10-04 16:00:54.000000000","message":"I see","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":92,"context_line":"    for the destination VM"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":95,"context_line":"  neutron event to confirm VIF plug has completed. (TODO - routing for that"},{"line_number":96,"context_line":"  event could be tricky?)"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* Start live-migrate as before"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_040e3c34","line":95,"in_reply_to":"3a98d1f4_49930b5b","updated":"2016-10-04 14:35:42.000000000","message":"if we are not careful we send the event to the source host not the destination host compute, because of the current instance.host field, which may not be what we want in this case.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"be48c18cdcf734bab1547f4036f1afd39b5b0982","unresolved":false,"context_lines":[{"line_number":98,"context_line":"* Start live-migrate as before"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* When VM is active on destination (note: tricky for post copy), mark the"},{"line_number":101,"context_line":"  new port binding above as active."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"  * we should not really hit an error here, but if we do, there is no"},{"line_number":104,"context_line":"    rollback, and we just put instance into ERROR state"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a98d1f4_a98acf18","line":101,"updated":"2016-10-04 07:53:27.000000000","message":"Maybe on Neutron side we come to the conclusion, that we will implement a approach where both bindings are active. Technically it would be possible for at least some drivers... I listed that approach in the \"alternatives\" section in the neutron spec","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"20998471ee4b2f11ed4a0eff0b956bc1882db2d6","unresolved":false,"context_lines":[{"line_number":98,"context_line":"* Start live-migrate as before"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* When VM is active on destination (note: tricky for post copy), mark the"},{"line_number":101,"context_line":"  new port binding above as active."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"  * we should not really hit an error here, but if we do, there is no"},{"line_number":104,"context_line":"    rollback, and we just put instance into ERROR state"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_a4ef43af","line":101,"in_reply_to":"1a95cdbc_04739cb2","updated":"2016-10-04 16:00:54.000000000","message":"But that will also be the case with the current approach. We can\u0027t force third party drivers to adapt that quick. I guess we need to give them some time...","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f01506c97c7ca9cb5841d71b364471d514ee1e8a","unresolved":false,"context_lines":[{"line_number":98,"context_line":"* Start live-migrate as before"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* When VM is active on destination (note: tricky for post copy), mark the"},{"line_number":101,"context_line":"  new port binding above as active."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"  * we should not really hit an error here, but if we do, there is no"},{"line_number":104,"context_line":"    rollback, and we just put instance into ERROR state"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a95cdbc_04739cb2","line":101,"in_reply_to":"3a98d1f4_a98acf18","updated":"2016-10-04 14:35:42.000000000","message":"Hmm, I don\u0027t like the \"some drivers\" bit.","commit_id":"9569781eb31c862606b50c8dd335fdcbdef0296e"}],"specs/queens/approved/neutron-new-port-binding-api.rst":[{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* In Mitaka Neutron introduced a contrack based security group driver for"},{"line_number":28,"context_line":"  ovs based backends. live migrating between a host with a different security"},{"line_number":29,"context_line":"  group driver another motivating special case of the more general act of"},{"line_number":30,"context_line":"  live migrating between different ml2 drivers which both require"},{"line_number":31,"context_line":"  different libvirt XML definitions on the source and destination hosts."},{"line_number":32,"context_line":"* To make the switch between source and destination host as quickly as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_3cae9e98","line":29,"range":{"start_line":29,"start_character":15,"end_line":29,"end_character":23},"updated":"2017-10-03 22:55:10.000000000","message":"is another?","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":72,"context_line":"We decide whether to use the new or old API flow, based on the available"},{"line_number":73,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":74,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"},{"line_number":75,"context_line":"layer, above the ml2 driver laye so if the extension is exposed it will be"},{"line_number":76,"context_line":"supported for all ml2 drivers. monolithic plugins will have to implement"},{"line_number":77,"context_line":"the extension separately and will continue to use the old workflow until"},{"line_number":78,"context_line":"their maintainers support the new neutron extension."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_9cb6b2dc","line":75,"range":{"start_line":75,"start_character":28,"end_line":75,"end_character":33},"updated":"2017-10-03 22:55:10.000000000","message":"layer","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":73,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":74,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"},{"line_number":75,"context_line":"layer, above the ml2 driver laye so if the extension is exposed it will be"},{"line_number":76,"context_line":"supported for all ml2 drivers. monolithic plugins will have to implement"},{"line_number":77,"context_line":"the extension separately and will continue to use the old workflow until"},{"line_number":78,"context_line":"their maintainers support the new neutron extension."},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_5cb03ade","line":76,"range":{"start_line":76,"start_character":31,"end_line":76,"end_character":32},"updated":"2017-10-03 22:55:10.000000000","message":"M","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":82,"context_line":"in two cycles. We should keep this in mind in how the code is structured."},{"line_number":83,"context_line":"Given we are also looking at removing nova-network, we should see if this can"},{"line_number":84,"context_line":"be added as a new set of network API calls, that are only for neutron, making"},{"line_number":85,"context_line":"the exiting calls needed for nova-network be no-ops for Neutron. We should"},{"line_number":86,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":87,"context_line":"happen based on the host values passed into the method."},{"line_number":88,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_dcd8aa1f","line":85,"range":{"start_line":85,"start_character":4,"end_line":85,"end_character":11},"updated":"2017-10-03 22:55:10.000000000","message":"existing","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":123,"context_line":"as during resize and migrate."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Evacuate is a special case, where we delete the port binding on the old host,"},{"line_number":126,"context_line":"without knowing if it has had VIFs deleted, as assume the host is dead and"},{"line_number":127,"context_line":"will never be coming back to life."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"With this change live migration between hosts with different"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_7c2e56fb","line":126,"range":{"start_line":126,"start_character":47,"end_line":126,"end_character":53},"updated":"2017-10-03 22:55:10.000000000","message":"we can assume?","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":"Primary assignee:"},{"line_number":197,"context_line":"  Sean Mooney  (sean-k-mooney)"},{"line_number":198,"context_line":"  John Garbutt (johnthetubaguy)"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Other contributors:"},{"line_number":201,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_3c5fbe73","line":198,"range":{"start_line":198,"start_character":2,"end_line":198,"end_character":31},"updated":"2017-10-03 22:55:10.000000000","message":"I don\u0027t think he will be working on this","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":221,"context_line":"  and port creation, to reduce the complexity in the interactions, before"},{"line_number":222,"context_line":"  adding the extra complexity proposed here."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"* Neutron API changes, see spec: https://review.openstack.org/#/c/309416"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Testing"},{"line_number":227,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_dc742a01","line":224,"range":{"start_line":224,"start_character":33,"end_line":224,"end_character":72},"updated":"2017-10-03 22:55:10.000000000","message":"Update to https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"cd4559cdd93640e55948d18319f765c7a34ca6e5","unresolved":false,"context_lines":[{"line_number":241,"context_line":"References"},{"line_number":242,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"* Neutron spec: https://review.openstack.org/#/c/309416"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"History"},{"line_number":247,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f515b1d_9c60f237","line":244,"range":{"start_line":244,"start_character":16,"end_line":244,"end_character":55},"updated":"2017-10-03 22:55:10.000000000","message":"Ditto","commit_id":"5a5f84ba1a686bc61ec40185812da1404403d18c"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"321559ca1ed264a9b992683769b2698c8d08fd35","unresolved":false,"context_lines":[{"line_number":201,"context_line":"Work Items"},{"line_number":202,"context_line":"----------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"TODO - needs more clarity:"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* audit where the old flow needs to be replaced by calls to the new flow,"},{"line_number":207,"context_line":"  in part to ensure there are no edge cases missed in this spec."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f515b1d_4af35e9f","line":204,"range":{"start_line":204,"start_character":0,"end_line":204,"end_character":26},"updated":"2017-10-06 23:09:22.000000000","message":"I think we need to remove this line","commit_id":"15b5b7fa2a52decceb71564913ae79cca9f49573"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4f7233448630ab278d542b30422294258d3101e9","unresolved":false,"context_lines":[{"line_number":201,"context_line":"Work Items"},{"line_number":202,"context_line":"----------"},{"line_number":203,"context_line":""},{"line_number":204,"context_line":"TODO - needs more clarity:"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* audit where the old flow needs to be replaced by calls to the new flow,"},{"line_number":207,"context_line":"  in part to ensure there are no edge cases missed in this spec."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f515b1d_a031aa0d","line":204,"range":{"start_line":204,"start_character":0,"end_line":204,"end_character":26},"in_reply_to":"7f515b1d_4af35e9f","updated":"2017-10-09 14:59:06.000000000","message":"Done","commit_id":"15b5b7fa2a52decceb71564913ae79cca9f49573"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":24,"context_line":"* In many cases the two hosts need a very different binding on source host"},{"line_number":25,"context_line":"  vs destination host, but that\u0027s not possible today. In particular, macvtap"},{"line_number":26,"context_line":"  live migration often needs different libvirt XML on source vs destination."},{"line_number":27,"context_line":"* In Mitaka Neutron introduced a contrack based security group driver for"},{"line_number":28,"context_line":"  ovs based backends. Live migrating between a host with a different security"},{"line_number":29,"context_line":"  group driver, is another motivating special case of the more general act of"},{"line_number":30,"context_line":"  live migrating between different ml2 drivers which both require"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_b7e0cb98","line":27,"range":{"start_line":27,"start_character":33,"end_line":27,"end_character":41},"updated":"2017-10-09 20:26:18.000000000","message":"contract?","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":31,"context_line":"  different libvirt XML definitions on the source and destination hosts."},{"line_number":32,"context_line":"* To make the switch between source and destination host as quickly as"},{"line_number":33,"context_line":"  possible, it\u0027s good to get most things ready before the migration is started."},{"line_number":34,"context_line":"  We have added a short-term hack for DVR, but let\u0027s do it properly."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"More details can be found in the neutron spec:"},{"line_number":37,"context_line":"https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_d78587ae","line":34,"range":{"start_line":34,"start_character":2,"end_line":34,"end_character":41},"updated":"2017-10-09 20:26:18.000000000","message":"Let\u0027s reference https://review.openstack.org/#/c/275073/ here for context.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Use Cases"},{"line_number":51,"context_line":"---------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"We should update all the places where we deal with port bindings, to use"},{"line_number":54,"context_line":"the new API flow. We generally edit the port bindings when a VM is moved."},{"line_number":55,"context_line":"The main API actions to consider are:"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_97526f34","line":53,"updated":"2017-10-09 20:26:18.000000000","message":"nit: This isn\u0027t really a use case. Use cases could be like:\n\nAs an admin, I want live migration to fail early during pre-live migration if it can be detected that network setup on the destination host will not work.\n\nAs a user, I want minimal network downtime while my instance is being live migrated.\n\nAs an operator, I want to start using new ML2 backends but need to live migrate existing instances off of a different backend with minimal network downtime.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":51,"context_line":"---------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"We should update all the places where we deal with port bindings, to use"},{"line_number":54,"context_line":"the new API flow. We generally edit the port bindings when a VM is moved."},{"line_number":55,"context_line":"The main API actions to consider are:"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* Attach a port to an instance, including during spawning an instance"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_37697bf7","line":54,"range":{"start_line":54,"start_character":31,"end_line":54,"end_character":35},"updated":"2017-10-09 20:26:18.000000000","message":"nit: update","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":58,"context_line":"* Detach a port from an instance"},{"line_number":59,"context_line":"* Live-migrate an instance, involves setting up the VIF on the destination"},{"line_number":60,"context_line":"  host, before kicking off the live-migrate, then removing VIFs on source"},{"line_number":61,"context_line":"  host once the live-migrate has completed. Need to notify neutron when"},{"line_number":62,"context_line":"  traffic needs to start going to the destination host."},{"line_number":63,"context_line":"* Migrate and resize are very similar to live-migrate"},{"line_number":64,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":65,"context_line":"  old connection, and attach the port on the new host."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_173c3fdf","line":62,"range":{"start_line":61,"start_character":44,"end_line":62,"end_character":55},"updated":"2017-10-09 20:26:18.000000000","message":"And this would be when we activate the dest host port binding and deactivate the source host port binding during post-live migration.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  host once the live-migrate has completed. Need to notify neutron when"},{"line_number":62,"context_line":"  traffic needs to start going to the destination host."},{"line_number":63,"context_line":"* Migrate and resize are very similar to live-migrate"},{"line_number":64,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":65,"context_line":"  old connection, and attach the port on the new host."},{"line_number":66,"context_line":"* Shelve, we want the port to stay logically attached to the instance, but"},{"line_number":67,"context_line":"  we need to detach it from the current host when the instance is offloaded."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_1a0a261f","line":65,"range":{"start_line":64,"start_character":2,"end_line":65,"end_character":54},"updated":"2017-10-09 20:26:18.000000000","message":"So for evacuate, I guess this means just deleting the port binding for the source host and creating a new active port binding for the destination host.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  host once the live-migrate has completed. Need to notify neutron when"},{"line_number":62,"context_line":"  traffic needs to start going to the destination host."},{"line_number":63,"context_line":"* Migrate and resize are very similar to live-migrate"},{"line_number":64,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":65,"context_line":"  old connection, and attach the port on the new host."},{"line_number":66,"context_line":"* Shelve, we want the port to stay logically attached to the instance, but"},{"line_number":67,"context_line":"  we need to detach it from the current host when the instance is offloaded."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_5626d4b9","line":65,"range":{"start_line":64,"start_character":2,"end_line":65,"end_character":54},"in_reply_to":"7f515b1d_1a0a261f","updated":"2017-10-10 15:34:36.000000000","message":"yes basically. when we activate the new host binding it should deactivate the old binding and if the neutron agent or sdn controller is able to still manage the host we evauted from it should tear down the connectivity on the source host such as delete acl rules if installed by neutron.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":65,"context_line":"  old connection, and attach the port on the new host."},{"line_number":66,"context_line":"* Shelve, we want the port to stay logically attached to the instance, but"},{"line_number":67,"context_line":"  we need to detach it from the current host when the instance is offloaded."},{"line_number":68,"context_line":""},{"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"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_5a041e15","line":67,"range":{"start_line":67,"start_character":45,"end_line":67,"end_character":76},"updated":"2017-10-09 20:26:18.000000000","message":"We do call cleanup_instance_network_on_host but it\u0027s a no-op for our neutron implementation. I guess this would deactivate the port binding? Why wouldn\u0027t we just delete the port binding at that point? Maybe we would. I\u0027ll continue reading.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* Evacuate, we know the old host is dead, we want to kill any record of that"},{"line_number":65,"context_line":"  old connection, and attach the port on the new host."},{"line_number":66,"context_line":"* Shelve, we want the port to stay logically attached to the instance, but"},{"line_number":67,"context_line":"  we need to detach it from the current host when the instance is offloaded."},{"line_number":68,"context_line":""},{"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"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_b69aa8c2","line":67,"range":{"start_line":67,"start_character":45,"end_line":67,"end_character":76},"in_reply_to":"7f515b1d_5a041e15","updated":"2017-10-10 15:34:36.000000000","message":"this was from johns original spec.\ni will reword this but i would envion that yes\nwe would just delete the binding on shelve which is what i think he originally ment by detack it for the current host e.g. unbind the port in the db.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"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":"We decide whether to use the new or old API flow, based on the available"},{"line_number":73,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":74,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"},{"line_number":75,"context_line":"layer, above the ml2 driver layer so if the extension is exposed it will be"},{"line_number":76,"context_line":"supported for all ml2 drivers. Monolithic plugins will have to implement"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_fa3bcacd","line":73,"range":{"start_line":73,"start_character":24,"end_line":73,"end_character":71},"updated":"2017-10-09 20:26:18.000000000","message":"I assume this is the \"usual way\":\n\nhttps://github.com/openstack/nova/blob/de90377721435f5ddc7e64915f41477562daac07/nova/network/neutronv2/api.py#L1037","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"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":"We decide whether to use the new or old API flow, based on the available"},{"line_number":73,"context_line":"Neutron API extensions, and we cache that information in the usual way."},{"line_number":74,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"},{"line_number":75,"context_line":"layer, above the ml2 driver layer so if the extension is exposed it will be"},{"line_number":76,"context_line":"supported for all ml2 drivers. Monolithic plugins will have to implement"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_d65084d7","line":73,"range":{"start_line":73,"start_character":24,"end_line":73,"end_character":71},"in_reply_to":"7f515b1d_fa3bcacd","updated":"2017-10-10 15:34:36.000000000","message":"yes","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":86,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":87,"context_line":"happen based on the host values passed into the method."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":90,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":91,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":92,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_1a58e62e","line":89,"range":{"start_line":89,"start_character":0,"end_line":89,"end_character":4},"updated":"2017-10-09 20:26:18.000000000","message":"There","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":87,"context_line":"happen based on the host values passed into the method."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":90,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":91,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":92,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":93,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":94,"context_line":"the Queens timeframe, so we release with the new workflow on by default."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Let\u0027s consider live-migration and what the calls to neutron will look like:"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_5aa09ef4","line":94,"range":{"start_line":90,"start_character":0,"end_line":94,"end_character":72},"updated":"2017-10-09 20:26:18.000000000","message":"I\u0027m not sure about this. I think about this more like how we\u0027re doing multiple volume attachments with the new Cinder 3.27 API now.\n\nEverything is plumbed from the bottom up, so it gets \"turned on\" when we start creating these new port bindings. For volumes, that means when the API starts attaching volumes using the new API and setting the BlockDeviceMapping.attachment_id field. The rest of the code is keyed off that being None or not. If it\u0027s None, it\u0027s old flow, if it\u0027s not None, it\u0027s new flow.\n\nSo for ports, that would be something like, new ports are created/attached with a port binding and that binding information (binding_id?) is set in the VIF model info cache on the instance. When we move the instance, we check to see if the port was created with the new style port binding stuff and if so, we do the source/dest port binding dance. If the port doesn\u0027t have an existing source node port binding, we either do the old flow, or we could try and fill the gap then by creating a port binding for the source host during pre-live migration. That would also give us the benefit of an online data migration for older instances/ports as instances get moved.\n\nHowever, you have to consider that we support live migrating instances between mixed version computes, so if your instance is on a queens compute with this new code, it could be live migrating to a pike compute without any of this code. That\u0027s why for the volume attachment stuff, we have a check in the API that all computes are upgraded with the latest code before we start setting BDM.attachment_id which is the conditional for the new code flow. I think we might want to do similar for the port binding stuff, unless you just plan on storing the port binding ID in the database (info cache) and looking it up each time to tell you what you can do.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":87,"context_line":"happen based on the host values passed into the method."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"This is no additional configuration for deployers, long term."},{"line_number":90,"context_line":"To aid testing, similar to glance v2, we will merge this support for the"},{"line_number":91,"context_line":"new workflow, and have it turned off by default. Once we get suitable"},{"line_number":92,"context_line":"functional testing in place, we can turn it on by default, and deprecate the"},{"line_number":93,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":94,"context_line":"the Queens timeframe, so we release with the new workflow on by default."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Let\u0027s consider live-migration and what the calls to neutron will look like:"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_47397c3f","line":94,"range":{"start_line":90,"start_character":0,"end_line":94,"end_character":72},"in_reply_to":"7f515b1d_5aa09ef4","updated":"2017-10-10 15:34:36.000000000","message":"thanks, i am happy to change this to reflect a workflow similar ot that of multiple volume attachmets.\n\nthis section of the spec is a direct port of the ocata version which i belive predates that work so ill update this with your feedback. We will always have a source portbinding as with the port will already be bound if we are migrating it but we may not have a destination port binding so in the event we are moving from a new to old node we will have to update the port binding and activate it before calling the old node.\n\nfor old to new we will have to create the destination port binding and activate on the destination node.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":93,"context_line":"configuration option to turn on the old flow. We aim to do all this within"},{"line_number":94,"context_line":"the Queens timeframe, so we release with the new workflow on by default."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Let\u0027s consider live-migration and what the calls to neutron will look like:"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* add port binding on destination host, in pre_live_migration phase"},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_5aee5e22","line":96,"updated":"2017-10-09 20:26:18.000000000","message":"OK keeping the flows in mind using:\n\nhttps://docs.openstack.org/nova/latest/reference/live-migration.html","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* add port binding on destination host, in pre_live_migration phase"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"  * check port binding was a success, if not, fail live-migration and retry"},{"line_number":101,"context_line":"    with a new host."},{"line_number":102,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":103,"context_line":"    for the destination VM"},{"line_number":104,"context_line":"  * note this obsoletes the workaround required for DVR today."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_5ac1be53","line":101,"range":{"start_line":100,"start_character":66,"end_line":101,"end_character":20},"updated":"2017-10-09 20:26:18.000000000","message":"If you\u0027re going to do this in pre_live_migration, you\u0027ve already cast from conductor and you\u0027re not doing any retries - unless you\u0027re going to add all of that retry logic into the compute / conductor flows, but that\u0027s out of scope here. If pre_live_migration (which is an rpc call from the source compute) fails, you\u0027re kind of screwed and have to just mark the migration as a failure:\n\nhttps://github.com/openstack/nova/blob/de90377721435f5ddc7e64915f41477562daac07/nova/compute/manager.py#L5617","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"  * check port binding was a success, if not, fail live-migration and retry"},{"line_number":101,"context_line":"    with a new host."},{"line_number":102,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":103,"context_line":"    for the destination VM"},{"line_number":104,"context_line":"  * note this obsoletes the workaround required for DVR today."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_1a858607","line":103,"range":{"start_line":102,"start_character":4,"end_line":103,"end_character":26},"updated":"2017-10-09 20:26:18.000000000","message":"Would you also put something into the LiveMigrateData object that is being passed around the various methods during live migration? That\u0027s your data blob that can help you know if you\u0027re talking to backlevel compute services or not during the live migration, because a pike compute won\u0027t be doing this port binding stuff on the dest host during pre_live_migration.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"  * check port binding was a success, if not, fail live-migration and retry"},{"line_number":101,"context_line":"    with a new host."},{"line_number":102,"context_line":"  * if success, store info needed to update domain XML (or equivalent),"},{"line_number":103,"context_line":"    for the destination VM"},{"line_number":104,"context_line":"  * note this obsoletes the workaround required for DVR today."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_6d6fb7c5","line":103,"range":{"start_line":102,"start_character":4,"end_line":103,"end_character":26},"in_reply_to":"7f515b1d_1a858607","updated":"2017-10-10 15:34:36.000000000","message":"yes we could alter it to carry a marker or other data to track which work flow we intend to execute. if we do the api check in the condocutor we could do the port binding for the destination before calling the old node.\n\ni will capture this in the alternatives section though i believe we can also do this in the _do_live_migration in\nfrom the source node before calling pre_live_migration via rpc.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":103,"context_line":"    for the destination VM"},{"line_number":104,"context_line":"  * note this obsoletes the workaround required for DVR today."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":107,"context_line":"  neutron event to confirm VIF plug has completed."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Start live-migrate as before"},{"line_number":110,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_3a7f22e0","line":107,"range":{"start_line":106,"start_character":2,"end_line":107,"end_character":50},"updated":"2017-10-09 20:26:18.000000000","message":"If this happens in pre_live_migration on the destination host, this is going to be a problem, since pre_live_migration is on the dest node, called (via RPC) from _do_live_migration on the source node. The VIF plugging timeout is by default 5 minutes, and the default rpc_response_timeout is 1 minute, so we can likely have an RPC messaging timeout here and then the live migration fails.\n\nA couple of options:\n\n1. The dest host could thread out the wait for vif plugged event and the source host could poll something to know when the vif is plugged.\n\n2. The source host could pass a timeout override when calling pre_live_migration on the dest host so it doesn\u0027t hit the default rpc timeout (maybe specify the vif plug + rpc timeout so by default the source host waits 6 minutes).","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":103,"context_line":"    for the destination VM"},{"line_number":104,"context_line":"  * note this obsoletes the workaround required for DVR today."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* VIF plug happens on destination host (after binding is updated), wait for"},{"line_number":107,"context_line":"  neutron event to confirm VIF plug has completed."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Start live-migrate as before"},{"line_number":110,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_0df5e3cb","line":107,"range":{"start_line":106,"start_character":2,"end_line":107,"end_character":50},"in_reply_to":"7f515b1d_3a7f22e0","updated":"2017-10-10 15:34:36.000000000","message":"i think the override would be the least invasive option however we actually don\u0027t need to wait for neutron here on the destination node. \nwe can complete the rpc once os-vif has plugged the nic and wait for then neutron event on the source node and then make a second rpc to start the instance when neutron notifies use it has wired up the port.\n\nthe ordering is a little wronge here as we need to actully have started the vm in a paused state on the destination before we call plug","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Start live-migrate as before"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"* When VM is active on destination (note: tricky for post copy), mark the"},{"line_number":112,"context_line":"  new port binding above as active."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  * we should not really hit an error here, but if we do, there is no"},{"line_number":115,"context_line":"    rollback and we just put instance into the ERROR state"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_1ab90678","line":112,"range":{"start_line":111,"start_character":65,"end_line":112,"end_character":35},"updated":"2017-10-09 20:26:18.000000000","message":"How is this atomic with Neutron so that we make the source host port binding inactive and the dest host port binding active within a single atomic operation? Does Neutron handle that with a PUT /ports call?","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Start live-migrate as before"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"* When VM is active on destination (note: tricky for post copy), mark the"},{"line_number":112,"context_line":"  new port binding above as active."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  * we should not really hit an error here, but if we do, there is no"},{"line_number":115,"context_line":"    rollback and we just put instance into the ERROR state"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_6d3a17e8","line":112,"range":{"start_line":111,"start_character":65,"end_line":112,"end_character":35},"in_reply_to":"7f515b1d_1ab90678","updated":"2017-10-10 15:34:36.000000000","message":"we have an api call to set binding as active on a specific host which automatically set all other binding as inactive.\nwe could move this to before i activate the","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  associated with the source host. Should the operation get interrupted,"},{"line_number":119,"context_line":"  there is enough information in the binding to ensure manual cleanup is"},{"line_number":120,"context_line":"  feasible."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"},{"line_number":123,"context_line":"as during resize and migrate."},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_9a7976c6","line":121,"updated":"2017-10-09 20:26:18.000000000","message":"What happens if the live migration is aborted? You should make sure to think through that. The flow is basically the admin aborts the in-progress live migration and the virt driver will call the rollback method, so you\u0027d have to be sure to clean up anything from the dest host at that point (maybe we just delete the dest host port binding?). The port binding on the source host should already be active so I don\u0027t think we\u0027d have to update anything on the source.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":118,"context_line":"  associated with the source host. Should the operation get interrupted,"},{"line_number":119,"context_line":"  there is enough information in the binding to ensure manual cleanup is"},{"line_number":120,"context_line":"  feasible."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"},{"line_number":123,"context_line":"as during resize and migrate."},{"line_number":124,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_e8ab9572","line":121,"in_reply_to":"7f515b1d_9a7976c6","updated":"2017-10-10 15:34:36.000000000","message":"i dont think we do this correctly today but yes we shoudl think this through.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":175,"context_line":"Other deployer impact"},{"line_number":176,"context_line":"---------------------"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Long term, there should be no extra configuration."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Once enabled by default, this flow should always be used in production in"},{"line_number":181,"context_line":"preference to the older flow."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_7a311a0b","line":178,"range":{"start_line":178,"start_character":0,"end_line":178,"end_character":50},"updated":"2017-10-09 20:26:18.000000000","message":"What is the short term configuration?","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":175,"context_line":"Other deployer impact"},{"line_number":176,"context_line":"---------------------"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Long term, there should be no extra configuration."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Once enabled by default, this flow should always be used in production in"},{"line_number":181,"context_line":"preference to the older flow."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_fc5fda0b","line":178,"range":{"start_line":178,"start_character":0,"end_line":178,"end_character":50},"in_reply_to":"7f515b1d_7a311a0b","updated":"2017-10-10 15:34:36.000000000","message":"it was a flag to explictly enable the fuctionalyt that\nwas intended to be removed before the queens release.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Long term, there should be no extra configuration."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Once enabled by default, this flow should always be used in production in"},{"line_number":181,"context_line":"preference to the older flow."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Developer impact"},{"line_number":184,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_5a1f7e6b","line":181,"range":{"start_line":180,"start_character":0,"end_line":181,"end_character":29},"updated":"2017-10-09 20:26:18.000000000","message":"I know there is a vague reference to glance v2 and such above, but as noted I think that\u0027s the wrong model here, and we should be following what we\u0027re doing to multiple volume attachments for live migration, which is:\n\nhttps://review.openstack.org/#/c/463987/","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"599be6cfb855d34e23285fd5c22ae80fa3bf15ee","unresolved":false,"context_lines":[{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Long term, there should be no extra configuration."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Once enabled by default, this flow should always be used in production in"},{"line_number":181,"context_line":"preference to the older flow."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Developer impact"},{"line_number":184,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f4e5783_7ca9aadd","line":181,"range":{"start_line":180,"start_character":0,"end_line":181,"end_character":29},"in_reply_to":"7f515b1d_5a1f7e6b","updated":"2017-10-10 15:34:36.000000000","message":"yes ill remove this section based on your feedback.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":207,"context_line":"* Turn old flow into a no-op, add appropriate calls to the new"},{"line_number":208,"context_line":"  binding update flow"},{"line_number":209,"context_line":"* Get functional tests in place and stable using the new flow"},{"line_number":210,"context_line":"* Deprecate configuration, and make the new flow the default"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_d55fbf0c","line":210,"range":{"start_line":210,"start_character":2,"end_line":210,"end_character":60},"updated":"2017-10-09 20:26:18.000000000","message":"I\u0027d remove this too. If we make the new flow conditional on some flag we\u0027re storing with the instance port/VIF information in the info_cache, then we know when to do the old/new thing.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Dependencies"},{"line_number":214,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"* Neutron v2 API refactoring. Must ensure we have good unit"},{"line_number":217,"context_line":"  test of the existing behaviour, and a clear separation between port binding"},{"line_number":218,"context_line":"  and port creation, to reduce the complexity in the interactions, before"},{"line_number":219,"context_line":"  adding the extra complexity proposed here."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Neutron API changes, see spec: https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":222,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_b55c4319","line":219,"range":{"start_line":216,"start_character":2,"end_line":219,"end_character":44},"updated":"2017-10-09 20:26:18.000000000","message":"I think this is already done and could be removed?","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":218,"context_line":"  and port creation, to reduce the complexity in the interactions, before"},{"line_number":219,"context_line":"  adding the extra complexity proposed here."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"* Neutron API changes, see spec: https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html"},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Testing"},{"line_number":224,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_1598b7bd","line":221,"updated":"2017-10-09 20:26:18.000000000","message":"Do we also have neutronclient changes that we need for the portbinding API?","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":223,"context_line":"Testing"},{"line_number":224,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Need functional tests for the old and new path. There will be a temporary"},{"line_number":227,"context_line":"configuration option to allow the old flow to be the default until we get"},{"line_number":228,"context_line":"tests in place for the new flow. Once we are happy we can switch the default"},{"line_number":229,"context_line":"over to the new flow, and deprecate the old configuration option, and schedule"},{"line_number":230,"context_line":"the removal of the old flow."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Documentation Impact"},{"line_number":233,"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":5,"id":"7f515b1d_b58a0361","line":230,"range":{"start_line":226,"start_character":0,"end_line":230,"end_character":28},"updated":"2017-10-09 20:26:18.000000000","message":"same thing about config here","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c07a96b33f8e69ba7cb937cea931d379bcd9e91","unresolved":false,"context_lines":[{"line_number":243,"context_line":"History"},{"line_number":244,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"Optional section intended to be used each time the spec is updated"},{"line_number":247,"context_line":"to describe the new design, API or any database schema updated."},{"line_number":248,"context_line":"Useful to let reader understand"},{"line_number":249,"context_line":"what\u0027s happened along the time."},{"line_number":250,"context_line":""},{"line_number":251,"context_line":".. list-table:: Revisions"},{"line_number":252,"context_line":"   :header-rows: 1"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f515b1d_35f4d3f0","line":249,"range":{"start_line":246,"start_character":0,"end_line":249,"end_character":31},"updated":"2017-10-09 20:26:18.000000000","message":"Remove this template text.","commit_id":"4e4aa0590be71a5295d69cec2ceac67744ff328f"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"781afbdd7ca9f3654f5fd71e18826c8a2f53b2c8","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"* Start live-migrate"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Before unpaseing destenation instance plug vif on destination host"},{"line_number":140,"context_line":"  wait for os-vif retrun."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"Note: mlavalle will this work or do we have to activate the port bining before/during"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_7dd99b81","line":139,"range":{"start_line":139,"start_character":9,"end_line":139,"end_character":30},"updated":"2017-10-11 03:26:16.000000000","message":"unpausing destination","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"781afbdd7ca9f3654f5fd71e18826c8a2f53b2c8","unresolved":false,"context_lines":[{"line_number":137,"context_line":"* Start live-migrate"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Before unpaseing destenation instance plug vif on destination host"},{"line_number":140,"context_line":"  wait for os-vif retrun."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"Note: mlavalle will this work or do we have to activate the port bining before/during"},{"line_number":143,"context_line":"pluging the vif for neutron to sent the event confirming the port is"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_9dcfb77e","line":140,"range":{"start_line":140,"start_character":18,"end_line":140,"end_character":24},"updated":"2017-10-11 03:26:16.000000000","message":"return","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fc4a2dffbc1231cfa93a04959f4e9d1ff978e582","unresolved":false,"context_lines":[{"line_number":139,"context_line":"* Before unpaseing destenation instance plug vif on destination host"},{"line_number":140,"context_line":"  wait for os-vif retrun."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"Note: mlavalle will this work or do we have to activate the port bining before/during"},{"line_number":143,"context_line":"pluging the vif for neutron to sent the event confirming the port is"},{"line_number":144,"context_line":"plugged on the neutron side?"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":147,"context_line":"  and mark the new port binding as active and unpasue destination vm"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_d213e7b7","line":144,"range":{"start_line":142,"start_character":0,"end_line":144,"end_character":28},"updated":"2017-10-10 16:39:06.000000000","message":"ill remove this a rev based on the response.\n\nif neutron will wire up the port without the binding active then ill just delete else I will move the activation to the end of the port plug on the destination node.","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"781afbdd7ca9f3654f5fd71e18826c8a2f53b2c8","unresolved":false,"context_lines":[{"line_number":139,"context_line":"* Before unpaseing destenation instance plug vif on destination host"},{"line_number":140,"context_line":"  wait for os-vif retrun."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"Note: mlavalle will this work or do we have to activate the port bining before/during"},{"line_number":143,"context_line":"pluging the vif for neutron to sent the event confirming the port is"},{"line_number":144,"context_line":"plugged on the neutron side?"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":147,"context_line":"  and mark the new port binding as active and unpasue destination vm"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_0b45b8b3","line":144,"range":{"start_line":142,"start_character":0,"end_line":144,"end_character":28},"in_reply_to":"5f4e5783_d213e7b7","updated":"2017-10-11 03:26:16.000000000","message":"Yes, we will wire up the port without the binding being active","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fc4a2dffbc1231cfa93a04959f4e9d1ff978e582","unresolved":false,"context_lines":[{"line_number":161,"context_line":"* if the admin abort a live migrations the rollback actions vary depending on"},{"line_number":162,"context_line":"  what pahse of the migration we are curently in."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"* if we are in the pre_live_migration and have not started the migration"},{"line_number":165,"context_line":"  we simply delete the destination port binding."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"* if we are migrating to a old compute we rebind the port to the source host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_52a2579c","line":164,"range":{"start_line":164,"start_character":37,"end_line":164,"end_character":38},"updated":"2017-10-10 16:39:06.000000000","message":"phase","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fc4a2dffbc1231cfa93a04959f4e9d1ff978e582","unresolved":false,"context_lines":[{"line_number":168,"context_line":""},{"line_number":169,"context_line":"* if we have started the vm on the remote node and plugged the interface but not"},{"line_number":170,"context_line":"  unpased the instance. we unplug the instance, delete the destation binding"},{"line_number":171,"context_line":"  activate the source binding if require"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"},{"line_number":174,"context_line":"as during resize and migrate."}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f4e5783_72b673dc","line":171,"range":{"start_line":171,"start_character":33,"end_line":171,"end_character":40},"updated":"2017-10-10 16:39:06.000000000","message":"required.","commit_id":"b9dcbc29ba27d635cba24f1a392699d02a1a432e"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"8210fb2874b0690e7e935aca3149e763666961b7","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* if we are migrating to a old compute we rebind the port to the source host."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"* if we have started the vm on the remote node and plugged the interface but not"},{"line_number":166,"context_line":"  unpased the instance. we unplug the instance, delete the destation binding"},{"line_number":167,"context_line":"  activate the source binding if required."},{"line_number":168,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"5f4e5783_77ca734e","line":165,"range":{"start_line":165,"start_character":77,"end_line":165,"end_character":80},"updated":"2017-10-13 19:25:07.000000000","message":"This line has 80 characters and is tripping Jenkins","commit_id":"5504dee141c97b6e6e78e5361438158b6b2a3e4d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":97,"context_line":"layer, above the ml2 driver layer so if the extension is exposed it will be"},{"line_number":98,"context_line":"supported for all ml2 drivers. Monolithic plugins will have to implement"},{"line_number":99,"context_line":"the extension separately and will continue to use the old workflow until"},{"line_number":100,"context_line":"their maintainers support the new neutron extension."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"The old interaction model should be removed when sufficient time has elapsed"},{"line_number":103,"context_line":"for all neutron backend to support this model with an aim of completing this"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_818580d1","line":100,"updated":"2017-10-16 16:36:23.000000000","message":"I presume this means the new flow is only used if all plugins in use in a particular cloud make use of the new flow. i.e. we don\u0027t have source vs destination nodes with plugins that support vs don\u0027t support the new flow?","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":97,"context_line":"layer, above the ml2 driver layer so if the extension is exposed it will be"},{"line_number":98,"context_line":"supported for all ml2 drivers. Monolithic plugins will have to implement"},{"line_number":99,"context_line":"the extension separately and will continue to use the old workflow until"},{"line_number":100,"context_line":"their maintainers support the new neutron extension."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"The old interaction model should be removed when sufficient time has elapsed"},{"line_number":103,"context_line":"for all neutron backend to support this model with an aim of completing this"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_d07a23ef","line":100,"in_reply_to":"5f4e5783_818580d1","updated":"2017-10-16 17:31:23.000000000","message":"correct\nwith neutron you can either load a singel monolithic core\nplugin or you can load the community provided ml2 core plugin which allows multiple vendor drivers to work in parallel. so if you use ml2 then it will work for all drivers. if you use a custom  monolitic core plugin then only that one can be used for the entire cloud.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":108,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":109,"context_line":"happen based on the host values passed into the method."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"There is no additional configuration for deployers, long term."},{"line_number":112,"context_line":"The use of multiple binding will be enabled automatically if both nodes"},{"line_number":113,"context_line":"support this feature. As we have to support any combination of"},{"line_number":114,"context_line":"old and new compute nodes the compute node API version will be checked in"},{"line_number":115,"context_line":"pre_live_migration."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Migration across mixed software versions."},{"line_number":118,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_e14d549a","line":115,"range":{"start_line":111,"start_character":0,"end_line":115,"end_character":19},"updated":"2017-10-16 16:36:23.000000000","message":"I am not clear what this means. Is this saying we do a check of the minimum service version to ensure everyone has been upgrade before we start using the new flow?","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":108,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":109,"context_line":"happen based on the host values passed into the method."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"There is no additional configuration for deployers, long term."},{"line_number":112,"context_line":"The use of multiple binding will be enabled automatically if both nodes"},{"line_number":113,"context_line":"support this feature. As we have to support any combination of"},{"line_number":114,"context_line":"old and new compute nodes the compute node API version will be checked in"},{"line_number":115,"context_line":"pre_live_migration."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Migration across mixed software versions."},{"line_number":118,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_b09b2716","line":115,"range":{"start_line":111,"start_character":0,"end_line":115,"end_character":19},"in_reply_to":"5f4e5783_e14d549a","updated":"2017-10-16 17:31:23.000000000","message":"this is a effect of removing the config option you originally had and trying to support the mixed mode below.\n\ni intended to say no configuration would be require and we would enable the fetarure if 1 or both of the compute nodes were queens.\n\nif we just dont support mixed mode this becomes,\nwe will use the new flow if neutron has the extention loaded and both compute nodes are are queens. otherwise we use the old workflow.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":127,"context_line":"* Both compute nodes are queens or newer. in this case the new workflow"},{"line_number":128,"context_line":"  will be used as described below."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"* old source compute node and new destination. Taking libvirt as an example,"},{"line_number":131,"context_line":"  as the migration XML generation is done by the source node if the new"},{"line_number":132,"context_line":"  destination compute node detects that an XML change would be required it"},{"line_number":133,"context_line":"  should fail the migration. This changes existing behaviour where"},{"line_number":134,"context_line":"  live migration may complete successfully but result in no network"},{"line_number":135,"context_line":"  connectivity."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"* new source compute node and old destination."},{"line_number":138,"context_line":"  In this case, the source node can create the port binding and update"},{"line_number":139,"context_line":"  the xml. There are 2 options with regard to activating the binding for"},{"line_number":140,"context_line":"  the destination host. the source node can activate the binding before"},{"line_number":141,"context_line":"  starting the live migration or after it succeeds. pre-activating the"},{"line_number":142,"context_line":"  binding will lead to more work should the migration fail, were as"},{"line_number":143,"context_line":"  activating the binding after migration success could increase network"},{"line_number":144,"context_line":"  downtime. the option chosen is left to the review of the"},{"line_number":145,"context_line":"  implementation to define and will be documented as a update to the"},{"line_number":146,"context_line":"  existing live migration devref."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Let\u0027s consider live-migration and what the calls to neutron will look like."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_81a10049","line":146,"range":{"start_line":130,"start_character":0,"end_line":146,"end_character":33},"updated":"2017-10-16 16:36:23.000000000","message":"This all seems super complicated, and hard to test.\n\nCan we just go for using the new flow once all nodes are upgraded?\n\nI guess what we loose is the ability to switch neutron plugin during this initial upgrade to queens. I know this isn\u0027t ideal, but it seems the best trade off on our ability to get this merged and tested. This stuff is messy to start with, I don\u0027t fancy making it harder than it needs to be.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":127,"context_line":"* Both compute nodes are queens or newer. in this case the new workflow"},{"line_number":128,"context_line":"  will be used as described below."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"* old source compute node and new destination. Taking libvirt as an example,"},{"line_number":131,"context_line":"  as the migration XML generation is done by the source node if the new"},{"line_number":132,"context_line":"  destination compute node detects that an XML change would be required it"},{"line_number":133,"context_line":"  should fail the migration. This changes existing behaviour where"},{"line_number":134,"context_line":"  live migration may complete successfully but result in no network"},{"line_number":135,"context_line":"  connectivity."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"* new source compute node and old destination."},{"line_number":138,"context_line":"  In this case, the source node can create the port binding and update"},{"line_number":139,"context_line":"  the xml. There are 2 options with regard to activating the binding for"},{"line_number":140,"context_line":"  the destination host. the source node can activate the binding before"},{"line_number":141,"context_line":"  starting the live migration or after it succeeds. pre-activating the"},{"line_number":142,"context_line":"  binding will lead to more work should the migration fail, were as"},{"line_number":143,"context_line":"  activating the binding after migration success could increase network"},{"line_number":144,"context_line":"  downtime. the option chosen is left to the review of the"},{"line_number":145,"context_line":"  implementation to define and will be documented as a update to the"},{"line_number":146,"context_line":"  existing live migration devref."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Let\u0027s consider live-migration and what the calls to neutron will look like."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_10055b14","line":146,"range":{"start_line":130,"start_character":0,"end_line":146,"end_character":33},"in_reply_to":"5f4e5783_81a10049","updated":"2017-10-16 17:31:23.000000000","message":"i am fine with only supporting the simple case.\n\neffectively the upgrade flow will be\n\nupgrade neutron server\nupgrade nova\n\nat this point we can live migrate workloads with new workflow\n\nupgrade neutron backends on compute nodes.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":156,"context_line":"* if the remote node support the new API"},{"line_number":157,"context_line":"    * add port binding on destination host, in pre_live_migration phase"},{"line_number":158,"context_line":"* else"},{"line_number":159,"context_line":"    * create the destination port binding and activate it"},{"line_number":160,"context_line":"      in _do_live_migration before calling pre_live_migration on the"},{"line_number":161,"context_line":"      destination compute node."},{"line_number":162,"context_line":"* check port binding was a success, if not, fail live-migration."}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_70a7ef0c","line":159,"updated":"2017-10-16 16:36:23.000000000","message":"Don\u0027t we technically need information from os-vif to perform the port binding call? So long term we will want that to happen on the destination host? I am not sure.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":156,"context_line":"* if the remote node support the new API"},{"line_number":157,"context_line":"    * add port binding on destination host, in pre_live_migration phase"},{"line_number":158,"context_line":"* else"},{"line_number":159,"context_line":"    * create the destination port binding and activate it"},{"line_number":160,"context_line":"      in _do_live_migration before calling pre_live_migration on the"},{"line_number":161,"context_line":"      destination compute node."},{"line_number":162,"context_line":"* check port binding was a success, if not, fail live-migration."}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_936dd5cd","line":159,"in_reply_to":"5f4e5783_70a7ef0c","updated":"2017-10-16 17:31:23.000000000","message":"long term yes we want the list of plugins supported by the destination so we can pass that to neutron.\nlong term we also want want nova to do some filtering on the host_info object returned by os-vif based on thinks like is your vif model virtio or did you request hugepages. so yes we really want this to happen on the compute node however old nova does neither of the above so doing it on the source node is not worse.\n\nthis complexity goes away if we dont support mixed version migration with the new flows.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":164,"context_line":"  in the migration data."},{"line_number":165,"context_line":"  note this obsoletes the workaround required for DVR today."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":168,"context_line":"  this may require the default rpc timeout to be overridden to"},{"line_number":169,"context_line":"  account for the vif_plug timeout."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Start live-migrate"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":174,"context_line":"  and mark the new port binding as active and unpause destination VM"},{"line_number":175,"context_line":"  and tear down the source."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* we should not really hit an error here, but if we do, there is no"},{"line_number":178,"context_line":"  rollback and we just put instance into the ERROR state"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_3c5ef343","line":175,"range":{"start_line":167,"start_character":0,"end_line":175,"end_character":27},"updated":"2017-10-16 16:36:23.000000000","message":"So Nova doesn\u0027t control when to pause/unpause the VM, its all libvirt (maybe its all qemu actually, not sure). So we can\u0027t do this.\n\nWhat I think you need here, sadly, is:\n\n* plug-vif\n* wait for event\n* start live-migration\n* wait for qemu event on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED, so we know the VM has just been paused by libvirt, so at that point we can updatie the binding.\n\nThe last bit around events, there is this patch which may help some:\nhttps://review.openstack.org/#/c/434870/\nI am very ++ we move towards using the qemu events for this stuff.\n\nThe alternative is only marking the port active after we find out the live-migration has completed, but clearly that is too late really. We could do that for the scope of this spec though.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"56c3b8e5910a3111a460b4b2bab60d2ede4e01b0","unresolved":false,"context_lines":[{"line_number":164,"context_line":"  in the migration data."},{"line_number":165,"context_line":"  note this obsoletes the workaround required for DVR today."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":168,"context_line":"  this may require the default rpc timeout to be overridden to"},{"line_number":169,"context_line":"  account for the vif_plug timeout."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Start live-migrate"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":174,"context_line":"  and mark the new port binding as active and unpause destination VM"},{"line_number":175,"context_line":"  and tear down the source."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* we should not really hit an error here, but if we do, there is no"},{"line_number":178,"context_line":"  rollback and we just put instance into the ERROR state"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3f4b6375_143275f2","line":175,"range":{"start_line":167,"start_character":0,"end_line":175,"end_character":27},"in_reply_to":"5f4e5783_3393c15d","updated":"2017-10-19 14:30:34.000000000","message":"There is a rollback livemigration on destination call that is responsible for doing those clean ups.\n\nI would bet they have not been implemented correctly, but the hook is there for exactly that reason.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":164,"context_line":"  in the migration data."},{"line_number":165,"context_line":"  note this obsoletes the workaround required for DVR today."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":168,"context_line":"  this may require the default rpc timeout to be overridden to"},{"line_number":169,"context_line":"  account for the vif_plug timeout."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"* Start live-migrate"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":174,"context_line":"  and mark the new port binding as active and unpause destination VM"},{"line_number":175,"context_line":"  and tear down the source."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* we should not really hit an error here, but if we do, there is no"},{"line_number":178,"context_line":"  rollback and we just put instance into the ERROR state"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_3393c15d","line":175,"range":{"start_line":167,"start_character":0,"end_line":175,"end_character":27},"in_reply_to":"5f4e5783_3c5ef343","updated":"2017-10-16 17:31:23.000000000","message":"ya as i was looking through the code that was becoming apparent. i do not think neutron will send an event to signal it has wired up a port untill we activate the binding for that host. if it did im not sure what and active binding would mean at the dataplane level vs inactive.\n\nBy the way calling plug-vif before starting the vm on the destination host is not always safe if we dont clean it up on failure correctly. i dont think we always do today.\n\nit does work but taking vhost-user where qemu is the server as an example from the time you call add-port br-int to the time qemu create the unix socket for vhost-user the vswtich is doing 1 of 2 things. 1) using poll or an inotify file handel to be interupted when the socket is create or 2)  it is spawing a thread to busy poll for the socket. \n\nso if we fail to boot and dont call unplug we will either effectivly leak filehandels or threads befause we failed to delete the ovs port.\n\nso plug should really be after the vm start but then we will have a network interruption so we cant do that either.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ecafe482010c8d987a2426e9926129ae2abe9cde","unresolved":false,"context_lines":[{"line_number":175,"context_line":"  and tear down the source."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* we should not really hit an error here, but if we do, there is no"},{"line_number":178,"context_line":"  rollback and we just put instance into the ERROR state"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"* run post_live_migration"},{"line_number":181,"context_line":"  After cleaning up VIFs on the source host, we remove the old port binding"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_5cd1af22","line":178,"updated":"2017-10-16 16:36:23.000000000","message":"You can have the live-migration timeout, so it gets aborted. Although you cover this a little in the aborts section.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3574b69538c5793dab5c6daa37fee527583e2c75","unresolved":false,"context_lines":[{"line_number":221,"context_line":"between different Neutron plugins, and allowing live-migrate for macvtap"},{"line_number":222,"context_line":"attached SR-IOV, but this is not in scope for this change."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"we could declare live migration between mixed compute nodes out of scope and"},{"line_number":225,"context_line":"always fallback to the old workflow in that case."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Data model impact"},{"line_number":228,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f4e5783_d390ed45","line":225,"range":{"start_line":224,"start_character":0,"end_line":225,"end_character":49},"updated":"2017-10-16 17:31:23.000000000","message":"so  i think for simplicity im just going to make this the proposal and move the current mixed mode language to here as an alternitive instead.","commit_id":"ef462d113e68a1319a819835f27f21e728a7863e"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":83,"context_line":"to live migrate existing instances off of a different backend"},{"line_number":84,"context_line":"with minimal network downtime."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"AS an operator, I want to leverage new security group implementations"},{"line_number":87,"context_line":"and need to be able to live migrate existing instances from my"},{"line_number":88,"context_line":"legacy hosts."},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_4739aed4","line":86,"range":{"start_line":86,"start_character":0,"end_line":86,"end_character":2},"updated":"2017-10-17 21:46:52.000000000","message":"nit: As","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":91,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"if both compute nodes support this feature We decide whether to use"},{"line_number":96,"context_line":"the new or old API flow, based on the available Neutron API extensions,"},{"line_number":97,"context_line":"and we cache that information in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_a75502fc","line":95,"range":{"start_line":94,"start_character":57,"end_line":95,"end_character":2},"updated":"2017-10-17 21:46:52.000000000","message":", if ?","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"if both compute nodes support this feature We decide whether to use"},{"line_number":96,"context_line":"the new or old API flow, based on the available Neutron API extensions,"},{"line_number":97,"context_line":"and we cache that information in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_8758c630","line":95,"range":{"start_line":95,"start_character":35,"end_line":95,"end_character":42},"updated":"2017-10-17 21:46:52.000000000","message":"feature. ?","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":91,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"if both compute nodes support this feature We decide whether to use"},{"line_number":96,"context_line":"the new or old API flow, based on the available Neutron API extensions,"},{"line_number":97,"context_line":"and we cache that information in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_d59d1b67","line":95,"range":{"start_line":94,"start_character":57,"end_line":95,"end_character":2},"in_reply_to":"5f4e5783_a75502fc","updated":"2017-10-18 15:56:55.000000000","message":"ill reword this slightly to be more clear but i intend to say we would enable this automatically. Then the next sentence describes how we do that.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":112,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":113,"context_line":"happen based on the host values passed into the method."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Migration across mixed software versions."},{"line_number":116,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"},{"line_number":117,"context_line":"neutron to consider. if an old neutron is present then"},{"line_number":118,"context_line":"the existing workflow will be followed regardless of the compute node version."}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_c77b5e89","line":115,"range":{"start_line":115,"start_character":0,"end_line":115,"end_character":41},"updated":"2017-10-17 21:46:52.000000000","message":"nit: maybe make this bold if you wanted to highlight it as a sub-section.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":113,"context_line":"happen based on the host values passed into the method."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Migration across mixed software versions."},{"line_number":116,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"},{"line_number":117,"context_line":"neutron to consider. if an old neutron is present then"},{"line_number":118,"context_line":"the existing workflow will be followed regardless of the compute node version."},{"line_number":119,"context_line":"Where a new neutron is deployed that supports this feature the following"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_a7a3c2ff","line":116,"range":{"start_line":116,"start_character":10,"end_line":116,"end_character":50},"updated":"2017-10-17 21:46:52.000000000","message":"You don\u0027t really go into the 4 combinations below, you just said we do the new thing once all computes are upgraded to queens.\n\nThe 4 combos would be:\n\n1. old -\u003e old\n2. old -\u003e new\n3. new -\u003e old\n4. new -\u003e new\n\nBut if those don\u0027t matter, it\u0027s probably not worth mentioning.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":113,"context_line":"happen based on the host values passed into the method."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Migration across mixed software versions."},{"line_number":116,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"},{"line_number":117,"context_line":"neutron to consider. if an old neutron is present then"},{"line_number":118,"context_line":"the existing workflow will be followed regardless of the compute node version."},{"line_number":119,"context_line":"Where a new neutron is deployed that supports this feature the following"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_b5a85f77","line":116,"range":{"start_line":116,"start_character":10,"end_line":116,"end_character":50},"in_reply_to":"5f4e5783_a7a3c2ff","updated":"2017-10-18 15:56:55.000000000","message":"ah i deleted 2 of them when i moved them to the alternitives section. ill fix this.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Migration across mixed software versions."},{"line_number":116,"context_line":"There are 4 possible combinations of compute nodes and 2 combinations of"},{"line_number":117,"context_line":"neutron to consider. if an old neutron is present then"},{"line_number":118,"context_line":"the existing workflow will be followed regardless of the compute node version."},{"line_number":119,"context_line":"Where a new neutron is deployed that supports this feature the following"},{"line_number":120,"context_line":"configurations are possible."}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_a76e22c6","line":117,"range":{"start_line":117,"start_character":21,"end_line":117,"end_character":23},"updated":"2017-10-17 21:46:52.000000000","message":"If","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Where a new neutron is deployed that supports this feature the following"},{"line_number":120,"context_line":"configurations are possible."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* Both compute nodes are queens or newer. in this case the new workflow"},{"line_number":123,"context_line":"  will be used as described below."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"* In all other cases the old workflow is used"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_47676eea","line":122,"range":{"start_line":122,"start_character":42,"end_line":122,"end_character":44},"updated":"2017-10-17 21:46:52.000000000","message":"In","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Going forward the workflow will be altered as follows:"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"* check feature support on both hosts and fallback if not supported."},{"line_number":135,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":136,"context_line":"* check port binding was a success, if not, fail live-migration."},{"line_number":137,"context_line":"* if success, store info needed to update domain XML (or equivalent),"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_877fa664","line":134,"range":{"start_line":134,"start_character":2,"end_line":134,"end_character":68},"updated":"2017-10-17 21:46:52.000000000","message":"Not sure about this - a pike compute host won\u0027t have any code to check if this is supported.\n\nMaybe you are thinking of some kind of up-front check in conductor before the process starts?","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Going forward the workflow will be altered as follows:"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"* check feature support on both hosts and fallback if not supported."},{"line_number":135,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":136,"context_line":"* check port binding was a success, if not, fail live-migration."},{"line_number":137,"context_line":"* if success, store info needed to update domain XML (or equivalent),"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_30d59dba","line":134,"range":{"start_line":134,"start_character":2,"end_line":134,"end_character":68},"in_reply_to":"5f4e5783_877fa664","updated":"2017-10-18 15:56:55.000000000","message":"hum i guess this would have to be in the conductor.\ni guess we would inject that check after \ncheck_can_live_migrate_destination returns before we cast to the source node to live_migrate.\n\nif both node support the new flow the i can cast to a \n\"live_migrateV2\" rpc endpoint instead of live_migrate.\n\nthat means I can leave the legacy live_migrate functions unmodified and replicate a v2 which will only support the old flow.\n\nthat will also make testing and deprecation much easier i was assuming we woudl do that anyway for the compute manager down but its easy to move this up one level.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":138,"context_line":"  in the migration data."},{"line_number":139,"context_line":"  Note: this obsoletes the workaround required for DVR today."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":142,"context_line":"  This may require the default RPC timeout to be overridden to"},{"line_number":143,"context_line":"  account for the vif_plug timeout."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_c7eebe20","line":143,"range":{"start_line":141,"start_character":2,"end_line":143,"end_character":35},"updated":"2017-10-17 21:46:52.000000000","message":"Could maybe use some more detail here about which method on the source node is doing an rpc call to the dest node to do the vif plug; the source node would be the one that would have to wait for the vif plug notification though since the API routes that event to the instance.host compute, which is the source until the instance moves.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ec98466722f6a83bc583cadea61ec32a334a3aba","unresolved":false,"context_lines":[{"line_number":138,"context_line":"  in the migration data."},{"line_number":139,"context_line":"  Note: this obsoletes the workaround required for DVR today."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":142,"context_line":"  This may require the default RPC timeout to be overridden to"},{"line_number":143,"context_line":"  account for the vif_plug timeout."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_2002e5b5","line":143,"range":{"start_line":141,"start_character":2,"end_line":143,"end_character":35},"in_reply_to":"3f4b6375_b6b746d9","updated":"2017-10-18 21:31:41.000000000","message":"I\u0027m not really following. If you plan on plugging VIFs in pre_live_migration and waiting for the vif-plugged event from neutron, the event is going to get processed on the source host because that\u0027s where the instance.host points to and that\u0027s where the API is going to route the request:\n\nhttps://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_external_events.py#L122\n\nhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L4117\n\nAlso, if you\u0027re waiting for VIFs to be plugged in pre_live_migration on the dest host, that\u0027s going to cause the RPC call to timeout potentially because the source host live_migration is doing the RPC call to pre_live_migration on the dest host.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":138,"context_line":"  in the migration data."},{"line_number":139,"context_line":"  Note: this obsoletes the workaround required for DVR today."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"* plug vif on destination host and wait for os-vif return."},{"line_number":142,"context_line":"  This may require the default RPC timeout to be overridden to"},{"line_number":143,"context_line":"  account for the vif_plug timeout."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_b6b746d9","line":143,"range":{"start_line":141,"start_character":2,"end_line":143,"end_character":35},"in_reply_to":"5f4e5783_c7eebe20","updated":"2017-10-18 15:56:55.000000000","message":"this is actually done as part of the \nself.driver.pre_live_migration call on the destination so this should be combined with the previous items.\nill update this. and remove the reference to overriding the timeout as this should be already accounted for in the existing code. \n\nthe difference here is that the the real difference here is that we are using the port binding for the destination instead of the source when plugging because the creation of the new binding earlier in this call.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":142,"context_line":"  This may require the default RPC timeout to be overridden to"},{"line_number":143,"context_line":"  account for the vif_plug timeout."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"* wait for neutron event to confirm VIF plug has completed"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Start live-migrate"},{"line_number":148,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_67df0a69","line":145,"range":{"start_line":145,"start_character":11,"end_line":145,"end_character":24},"updated":"2017-10-17 21:46:52.000000000","message":"on the source host","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Start live-migrate"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* wait for qemu event on the source host called"},{"line_number":150,"context_line":"  EVENT_LIFECYCLE_MIGRATION_COMPLETED,so we know the VM has"},{"line_number":151,"context_line":"  just been paused by libvirt and mark the new port binding as active"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* we should only hit an error here if the migration times out."},{"line_number":154,"context_line":"  If we hit any other error, there is no rollback and we just"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_07e05625","line":151,"range":{"start_line":149,"start_character":2,"end_line":151,"end_character":69},"updated":"2017-10-17 21:46:52.000000000","message":"umm, this might be ok for libvirt, but what about other virt drivers like hyperv and xen?","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ec98466722f6a83bc583cadea61ec32a334a3aba","unresolved":false,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Start live-migrate"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* wait for qemu event on the source host called"},{"line_number":150,"context_line":"  EVENT_LIFECYCLE_MIGRATION_COMPLETED,so we know the VM has"},{"line_number":151,"context_line":"  just been paused by libvirt and mark the new port binding as active"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* we should only hit an error here if the migration times out."},{"line_number":154,"context_line":"  If we hit any other error, there is no rollback and we just"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_c032f1a7","line":151,"range":{"start_line":149,"start_character":2,"end_line":151,"end_character":69},"in_reply_to":"3f4b6375_30123db3","updated":"2017-10-18 21:31:41.000000000","message":"hyperv and xenapi are both capable of listening for vif-plugged events and already do so when spawning an instance.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Start live-migrate"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* wait for qemu event on the source host called"},{"line_number":150,"context_line":"  EVENT_LIFECYCLE_MIGRATION_COMPLETED,so we know the VM has"},{"line_number":151,"context_line":"  just been paused by libvirt and mark the new port binding as active"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* we should only hit an error here if the migration times out."},{"line_number":154,"context_line":"  If we hit any other error, there is no rollback and we just"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_30123db3","line":151,"range":{"start_line":149,"start_character":2,"end_line":151,"end_character":69},"in_reply_to":"5f4e5783_07e05625","updated":"2017-10-18 15:56:55.000000000","message":"good point. for other virt drivers it they dont have a similar event framework i guess we can activate on live_migrations sucess or imidetly before starting the migration after plugging the vif.\n\nboth will have a slightly longer network output to the event based approch.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":169,"context_line":"* if we are in the pre_live_migration phase and have not started the migration"},{"line_number":170,"context_line":"  we simply delete the destination port binding."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* if we are migrating to an old compute node we rebind the port to the"},{"line_number":173,"context_line":"  source host or delete the destination binding if not activated yet."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* if we have started the VM on the remote node and plugged the interface but"},{"line_number":176,"context_line":"  not unpaused the instance. we unplug the instance, delete the destination"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_87cd66b8","line":173,"range":{"start_line":172,"start_character":2,"end_line":173,"end_character":69},"updated":"2017-10-17 21:46:52.000000000","message":"I thought we weren\u0027t dealing with mixed version computes for this?","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":169,"context_line":"* if we are in the pre_live_migration phase and have not started the migration"},{"line_number":170,"context_line":"  we simply delete the destination port binding."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"* if we are migrating to an old compute node we rebind the port to the"},{"line_number":173,"context_line":"  source host or delete the destination binding if not activated yet."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* if we have started the VM on the remote node and plugged the interface but"},{"line_number":176,"context_line":"  not unpaused the instance. we unplug the instance, delete the destination"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_b6ef4686","line":173,"range":{"start_line":172,"start_character":2,"end_line":173,"end_character":69},"in_reply_to":"5f4e5783_87cd66b8","updated":"2017-10-18 15:56:55.000000000","message":"right ill delete this i forgot to remove it","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":173,"context_line":"  source host or delete the destination binding if not activated yet."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* if we have started the VM on the remote node and plugged the interface but"},{"line_number":176,"context_line":"  not unpaused the instance. we unplug the instance, delete the destination"},{"line_number":177,"context_line":"  binding activates the source binding if required."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_8742060e","line":176,"range":{"start_line":176,"start_character":19,"end_line":176,"end_character":28},"updated":"2017-10-17 21:46:52.000000000","message":"instance,","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* if we have started the VM on the remote node and plugged the interface but"},{"line_number":176,"context_line":"  not unpaused the instance. we unplug the instance, delete the destination"},{"line_number":177,"context_line":"  binding activates the source binding if required."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"},{"line_number":180,"context_line":"as during resize and migrate."}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_e739baa3","line":177,"range":{"start_line":177,"start_character":10,"end_line":177,"end_character":19},"updated":"2017-10-17 21:46:52.000000000","message":"which activates","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":174,"context_line":""},{"line_number":175,"context_line":"* if we have started the VM on the remote node and plugged the interface but"},{"line_number":176,"context_line":"  not unpaused the instance. we unplug the instance, delete the destination"},{"line_number":177,"context_line":"  binding activates the source binding if required."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"We can follow this pattern wherever there are VIFs present on two hosts, such"},{"line_number":180,"context_line":"as during resize and migrate."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_96c20ae9","line":177,"range":{"start_line":177,"start_character":10,"end_line":177,"end_character":19},"in_reply_to":"5f4e5783_e739baa3","updated":"2017-10-18 15:56:55.000000000","message":"i dont think it will do it automatically so we will have to activite the source binding if required and then delete the destination binding if it exists.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":199,"context_line":"between different Neutron plugins, and allowing live-migrate for macvtap"},{"line_number":200,"context_line":"attached SR-IOV, but this is not in scope for this change."},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"we could support live migration between mixed compute nodes."},{"line_number":203,"context_line":"In this case assuming the neutron supported the new flow, the"},{"line_number":204,"context_line":"following behaviour would be introduced."},{"line_number":205,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_275352e4","line":202,"range":{"start_line":202,"start_character":0,"end_line":202,"end_character":2},"updated":"2017-10-17 21:46:52.000000000","message":"We","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":221,"context_line":"  implementation to define and will be documented as a update to the"},{"line_number":222,"context_line":"  existing live migration devref."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"This has not been suppoted due to complexity of code and testing required."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_c7659eb6","line":224,"range":{"start_line":224,"start_character":18,"end_line":224,"end_character":26},"updated":"2017-10-17 21:46:52.000000000","message":"supported","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c97a7834ea4511a376b36b9a56ca9b1b7942ae5","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Data model impact"},{"line_number":228,"context_line":"-----------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"The migration_data object will be extended with a list of VIF"},{"line_number":231,"context_line":"object to model the port binding for each guest interface."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"REST API impact"},{"line_number":234,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"5f4e5783_076736b9","line":231,"range":{"start_line":230,"start_character":0,"end_line":231,"end_character":58},"updated":"2017-10-17 21:46:52.000000000","message":"The live migration data object isn\u0027t actually persisted, so putting this in \u0027data model impact\u0027 isn\u0027t quite accurate. Just mention it in the proposed change somewhere.","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9d4f95f9d88f22120120da1de8ca7b1769218b54","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Data model impact"},{"line_number":228,"context_line":"-----------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"The migration_data object will be extended with a list of VIF"},{"line_number":231,"context_line":"object to model the port binding for each guest interface."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"REST API impact"},{"line_number":234,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3f4b6375_99647dbb","line":231,"range":{"start_line":230,"start_character":0,"end_line":231,"end_character":58},"in_reply_to":"5f4e5783_076736b9","updated":"2017-10-18 15:56:55.000000000","message":"ok ill remove this is already mentioned in the proposed change so ill just set this to none","commit_id":"9c767e5fa4775bc55f13693e46bab6b8b72769a3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"482d2fc14371ed5c03490e9c21a434a58c8ccd33","unresolved":false,"context_lines":[{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and  based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extention support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_80ebd9ae","line":96,"range":{"start_line":96,"start_character":24,"end_line":96,"end_character":26},"updated":"2017-10-18 21:40:21.000000000","message":"s/  / /","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and  based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extention support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."},{"line_number":99,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_637a1525","line":96,"range":{"start_line":96,"start_character":24,"end_line":96,"end_character":26},"in_reply_to":"3f4b6375_80ebd9ae","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"482d2fc14371ed5c03490e9c21a434a58c8ccd33","unresolved":false,"context_lines":[{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and  based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extention support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_a0e6d5e7","line":97,"range":{"start_line":97,"start_character":9,"end_line":97,"end_character":18},"updated":"2017-10-18 21:40:21.000000000","message":"extension","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and  based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extention support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_4377193c","line":97,"range":{"start_line":97,"start_character":9,"end_line":97,"end_character":18},"in_reply_to":"3f4b6375_a0e6d5e7","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b6cdcb822d05c7b3543e836bbfc5641a24f4ce6","unresolved":false,"context_lines":[{"line_number":104,"context_line":"their maintainers support the new neutron extension."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"The old interaction model should be removed when sufficient time has elapsed"},{"line_number":107,"context_line":"for all neutron backend to support this model with an aim of completing this"},{"line_number":108,"context_line":"in two cycles. We should keep this in mind in how the code is structured."},{"line_number":109,"context_line":"Given we are also looking at removing nova-network, we should see if this can"},{"line_number":110,"context_line":"be added as a new set of network API calls, that are only for neutron, making"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_1e56162b","line":107,"range":{"start_line":107,"start_character":16,"end_line":107,"end_character":23},"updated":"2017-10-19 14:00:35.000000000","message":"backends","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e0be6aa731ce02f1ef9961ea2b0fb255e7ab449","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* check feature support on both hosts and fallback if not supported."},{"line_number":134,"context_line":"  This will be done in the conductor after check_can_live_migrate_destination."},{"line_number":135,"context_line":"  If the new flow is supported the conductor will cast to the source node"},{"line_number":136,"context_line":"  by calling live_migrateV2 else it will fallback to casting to live_migrate."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":"  * check port binding was a successful, if not, fail live-migration."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_93833105","line":136,"range":{"start_line":136,"start_character":13,"end_line":136,"end_character":27},"updated":"2017-10-18 22:16:42.000000000","message":"I\u0027m not sure how much this is going to buy us. We\u0027re still going to have a lot of the same pre/post type methods in the compute manager and the virt driver, and we don\u0027t plan on duplicating all of those just for this.\n\nThe way the new-style volume attachment stuff works, the BlockDeviceMapping object representing a volume either has an attachment_id set or it doesn\u0027t. The attachment_id being set triggers new flows during live migration.\n\nSo what if check_can_live_migrate_destination created the dest host port binding and puts whatever information about that in the migrate_data object? That gets passed back to conductor which sends it to live_migration on the source host.\n\nThe thing would be, a pike node wouldn\u0027t create the dest host port binding in check_can_live_migrate_destination because it doesn\u0027t have the code to do it. And if check_can_live_migrate_destination on a queens node does it, a pike source node wouldn\u0027t know anything about the dest host port binding.\n\nSo, rather than have check_can_live_migrate_destination create the dest host port binding pre-migration, we could have conductor create the dest host port binding and put that into the migrate_data object sent to live_migration - but conductor would only create the dest host port binding iff the source and dest nodes were both queens, so they\u0027d know to check the migrate_data object for the port binding information.\n\nThat would also help somewhat with the big blocker on not allowing this at all until all computes are upgraded - you could at least have a shot of live migrating with this new code for computes that are already upgraded, while you\u0027re still rolling through older computes, maybe in another cell that\u0027s still running pike computes.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b6cdcb822d05c7b3543e836bbfc5641a24f4ce6","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* check feature support on both hosts and fallback if not supported."},{"line_number":134,"context_line":"  This will be done in the conductor after check_can_live_migrate_destination."},{"line_number":135,"context_line":"  If the new flow is supported the conductor will cast to the source node"},{"line_number":136,"context_line":"  by calling live_migrateV2 else it will fallback to casting to live_migrate."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":"  * check port binding was a successful, if not, fail live-migration."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_f927d4b5","line":136,"range":{"start_line":136,"start_character":13,"end_line":136,"end_character":27},"in_reply_to":"3f4b6375_93833105","updated":"2017-10-19 14:00:35.000000000","message":"So instead of calculating the minimum compute version and just gating this feature until everything is upgraded, you\u0027d check the specific versions of each and make a call? I guess that would work as long as you don\u0027t need any other RPC changes for this. If you do, then you\u0027re going to be pinned at the pike version during this process anyway.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":136,"context_line":"  by calling live_migrateV2 else it will fallback to casting to live_migrate."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":"  * check port binding was a successful, if not, fail live-migration."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"  * if successful, store info needed to update domain XML (or equivalent),"},{"line_number":142,"context_line":"    in the migration_data object."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_a05b7585","line":139,"updated":"2017-10-18 22:04:45.000000000","message":"nit: I think you need a blank line before this for the sub-bullets to render properly.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"bb67312ec09808fa59ef42d371ef10b7d4471eb0","unresolved":false,"context_lines":[{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":"  * check port binding was a successful, if not, fail live-migration."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"  * if successful, store info needed to update domain XML (or equivalent),"},{"line_number":142,"context_line":"    in the migration_data object."},{"line_number":143,"context_line":"    Note: this obsoletes the workaround required for DVR today."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_33d91d83","line":142,"range":{"start_line":141,"start_character":19,"end_line":142,"end_character":33},"updated":"2017-10-18 22:07:44.000000000","message":"At what point is this stored domain xml information used? During the live migration on the source? I\u0027m guessing somewhere in here?\n\nhttps://github.com/openstack/nova/blob/5a52d86185045127bf1da8391bd307900804d6d5/nova/virt/libvirt/driver.py#L6320","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":"  * check port binding was a successful, if not, fail live-migration."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"  * if successful, store info needed to update domain XML (or equivalent),"},{"line_number":142,"context_line":"    in the migration_data object."},{"line_number":143,"context_line":"    Note: this obsoletes the workaround required for DVR today."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_23a9bd7a","line":142,"range":{"start_line":141,"start_character":19,"end_line":142,"end_character":33},"in_reply_to":"3f4b6375_33d91d83","updated":"2017-10-19 13:16:55.000000000","message":"yes it is used there.\ni will need to add a fucntion to specificlaly update the network interfaces in get_updated_guest_xml","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":142,"context_line":"    in the migration_data object."},{"line_number":143,"context_line":"    Note: this obsoletes the workaround required for DVR today."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* wait for neutron event on the source host to confirm VIF plug has completed."},{"line_number":148,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_60da1dea","line":145,"range":{"start_line":145,"start_character":33,"end_line":145,"end_character":39},"updated":"2017-10-18 22:04:45.000000000","message":"using","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":142,"context_line":"    in the migration_data object."},{"line_number":143,"context_line":"    Note: this obsoletes the workaround required for DVR today."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* wait for neutron event on the source host to confirm VIF plug has completed."},{"line_number":148,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_2373fd17","line":145,"range":{"start_line":145,"start_character":33,"end_line":145,"end_character":39},"in_reply_to":"3f4b6375_60da1dea","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* wait for neutron event on the source host to confirm VIF plug has completed."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_20e425ac","line":147,"updated":"2017-10-18 22:04:45.000000000","message":"https://review.openstack.org/#/c/497457/ might be useful for thoughts on how to handle this. That change isn\u0027t doing it correctly, but there is discussion in there about waiting for vif plugging during live migration.\n\nAlso, why is it that live migration today doesn\u0027t wait for the vif to be plugged on the destination host before starting the live migration? Do we just get lucky that by the time the live migration is complete and we switch over to the destination host and teardown on the source during post_live_migration, the vif is plugged?","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* wait for neutron event on the source host to confirm VIF plug has completed."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_6369f523","line":147,"in_reply_to":"3f4b6375_20e425ac","updated":"2017-10-19 13:16:55.000000000","message":"the vif is plugged in pre_live_migrate so we dont have to aith in live_migrate because its already done.\n\nthe plugging is the call to os-vif  what we are waiting for here is the event for neutron to say i have wired up this interface.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b6cdcb822d05c7b3543e836bbfc5641a24f4ce6","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"  * plug vif on destination host useing the new port binding."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* wait for neutron event on the source host to confirm VIF plug has completed."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_5966e8ef","line":147,"in_reply_to":"3f4b6375_6369f523","updated":"2017-10-19 14:00:35.000000000","message":"This bullet should be indented under pre_love_migration then, right? So we know that we\u0027re holding up that phase waiting for the results of the plug?","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b6cdcb822d05c7b3543e836bbfc5641a24f4ce6","unresolved":false,"context_lines":[{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_39632cdf","line":151,"range":{"start_line":151,"start_character":30,"end_line":151,"end_character":40},"updated":"2017-10-19 14:00:35.000000000","message":"hypervisors","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_80ee3986","line":151,"range":{"start_line":151,"start_character":9,"end_line":151,"end_character":17},"updated":"2017-10-18 22:04:45.000000000","message":"involves","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_e3cba51b","line":151,"range":{"start_line":151,"start_character":9,"end_line":151,"end_character":17},"in_reply_to":"3f4b6375_80ee3986","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_40004135","line":152,"range":{"start_line":152,"start_character":4,"end_line":152,"end_character":11},"updated":"2017-10-18 22:04:45.000000000","message":"s/migrate//","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":149,"context_line":"* Start live-migrate"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_c3d0a9cc","line":152,"range":{"start_line":152,"start_character":4,"end_line":152,"end_character":11},"in_reply_to":"3f4b6375_40004135","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_6088ddc5","line":154,"range":{"start_line":154,"start_character":29,"end_line":154,"end_character":36},"updated":"2017-10-18 22:04:45.000000000","message":"?","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":151,"context_line":"  * This invovles calling the hyperviors to live migrate"},{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_a3d5adbb","line":154,"range":{"start_line":154,"start_character":29,"end_line":154,"end_character":36},"in_reply_to":"3f4b6375_6088ddc5","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_f33145ee","line":155,"range":{"start_line":155,"start_character":30,"end_line":155,"end_character":65},"updated":"2017-10-18 22:04:45.000000000","message":"VIR_DOMAIN_JOB_COMPLETED?\n\nhttps://github.com/openstack/nova/blob/5a52d86185045127bf1da8391bd307900804d6d5/nova/virt/libvirt/driver.py#L6631","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":152,"context_line":"    migrate the instance and then activating the port binding."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_c39e6906","line":155,"range":{"start_line":155,"start_character":30,"end_line":155,"end_character":65},"in_reply_to":"3f4b6375_f33145ee","updated":"2017-10-19 13:16:55.000000000","message":"this was the one John suggested based on https://review.openstack.org/#/c/434870/ but reading it i think he ment VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY as it is emited when the source vm is paused and we are about to resume it on the destination.\n\nVIR_DOMAIN_JOB_COMPLETED happen later an would increase the network downtime if used.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_20ab051e","line":157,"range":{"start_line":157,"start_character":4,"end_line":157,"end_character":26},"updated":"2017-10-18 22:04:45.000000000","message":"So every virt driver will have to call back into the networking API to activate the port binding? That seems less than good - can\u0027t the compute manager handle activating the port? Also, to be clear, is this activating the destination host port binding from the source host?\n\nFor libvirt, once we get this event:\n\nhttps://github.com/openstack/nova/blob/5a52d86185045127bf1da8391bd307900804d6d5/nova/virt/libvirt/driver.py#L6631\n\nThe driver calls _post_live_migration which runs on the source node. That calls the \"migrate_instance_start\" network API method which today is a no-op for neutron - couldn\u0027t we use that to activate the port binding on the dest host before the source calls post_live_migration_at_destination? Or do the dest host port binding activation from post_live_migration_at_destination when it calls nova.network.neutronv2.api.API.migrate_instance_finish which updates the port binding for the instance to point at the dest host?\n\nI just really don\u0027t like the idea of the virt driver having to call things in the network API, that should be handled in the compute manager code and we already have hooks to do it.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b6cdcb822d05c7b3543e836bbfc5641a24f4ce6","unresolved":false,"context_lines":[{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_39b8cc28","line":157,"range":{"start_line":157,"start_character":4,"end_line":157,"end_character":26},"in_reply_to":"3f4b6375_20ab051e","updated":"2017-10-19 14:00:35.000000000","message":"And what about drivers that don\u0027t get this type of event in the same place as libvirt? Can you add a generic \"or when $thing completes\"? We\u0027d want to make sure that this only happens once and not when the libvirt event comes, and then again when live migration exits because that\u0027s where we\u0027d need it for other drivers.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":154,"context_line":"  * In the example of libvirt  the  we will wait for qemu event"},{"line_number":155,"context_line":"    on the source host called EVENT_LIFECYCLE_MIGRATION_COMPLETED,"},{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_4380398c","line":157,"range":{"start_line":157,"start_character":4,"end_line":157,"end_character":26},"in_reply_to":"3f4b6375_20ab051e","updated":"2017-10-19 13:16:55.000000000","message":"ideally no, i would like to do it in the compute manager and not have the virt driver call into the networking api.\n\ni dont know how to make this generic for all virt drives with out making it there responciblity though while not also leantening the time between the vm resuming on the destination and activating the binding.\n\nwe really want to activate the port binding after\nVIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY and before\nVIR_DOMAIN_EVENT_RESUMED_POSTCOPY to have 0 down time.","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_00a8091d","line":159,"range":{"start_line":159,"start_character":31,"end_line":159,"end_character":38},"updated":"2017-10-18 22:04:45.000000000","message":"decisions","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":156,"context_line":"    so we know the VM has just been paused by libvirt and mark the new"},{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_1eb5f631","line":159,"range":{"start_line":159,"start_character":31,"end_line":159,"end_character":38},"in_reply_to":"3f4b6375_00a8091d","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"},{"line_number":163,"context_line":"    them to reduce the network downtime."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_e0628d16","line":160,"range":{"start_line":160,"start_character":29,"end_line":160,"end_character":32},"updated":"2017-10-18 22:04:45.000000000","message":"They","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":157,"context_line":"    port binding as active"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"},{"line_number":163,"context_line":"    them to reduce the network downtime."}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_fe833a55","line":160,"range":{"start_line":160,"start_character":29,"end_line":160,"end_character":32},"in_reply_to":"3f4b6375_e0628d16","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"},{"line_number":163,"context_line":"    them to reduce the network downtime."},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_c0679125","line":161,"range":{"start_line":161,"start_character":21,"end_line":161,"end_character":30},"updated":"2017-10-18 22:04:45.000000000","message":"immediately","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * For other virt drivers the desions of when to activate the port"},{"line_number":160,"context_line":"    binding is left to them. The may serialise the calls by activating"},{"line_number":161,"context_line":"    the port binding imedietly before or after migrating the instance"},{"line_number":162,"context_line":"    or they may concurrently wait for an event if the hypervior emits"},{"line_number":163,"context_line":"    them to reduce the network downtime."},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_5e948e8b","line":161,"range":{"start_line":161,"start_character":21,"end_line":161,"end_character":30},"in_reply_to":"3f4b6375_c0679125","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"642162807ae70496b65d8ce4d9495c2676e1795b","unresolved":false,"context_lines":[{"line_number":230,"context_line":"  implementation to define and will be documented as a update to the"},{"line_number":231,"context_line":"  existing live migration devref."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"This has not been suppoted due to complexity of code and testing required."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_4073a1e8","line":233,"range":{"start_line":233,"start_character":18,"end_line":233,"end_character":26},"updated":"2017-10-18 22:04:45.000000000","message":"supported","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17955eac563c5c7523f29f337091be50d03fe88b","unresolved":false,"context_lines":[{"line_number":230,"context_line":"  implementation to define and will be documented as a update to the"},{"line_number":231,"context_line":"  existing live migration devref."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"This has not been suppoted due to complexity of code and testing required."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":13,"id":"3f4b6375_deed1e26","line":233,"range":{"start_line":233,"start_character":18,"end_line":233,"end_character":26},"in_reply_to":"3f4b6375_4073a1e8","updated":"2017-10-19 13:16:55.000000000","message":"Done","commit_id":"fc56a3e3b37f1039ddca5753b12a14281db70709"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":91,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extensions support in the usual way utilising the existing"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_fa13430c","line":94,"range":{"start_line":94,"start_character":20,"end_line":94,"end_character":27},"updated":"2017-10-19 15:18:53.000000000","message":"bindings","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"There is no additional configuration for deployers."},{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extensions support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_7aff53aa","line":95,"range":{"start_line":95,"start_character":53,"end_line":95,"end_character":58},"updated":"2017-10-19 15:18:53.000000000","message":"if *all the* compute nodes, I guess ?","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":94,"context_line":"The use of multiple binding will be enabled automatically."},{"line_number":95,"context_line":"We decide whether to use the new or old API flow, if both compute nodes"},{"line_number":96,"context_line":"support this feature and based on the available Neutron API extensions."},{"line_number":97,"context_line":"We cache extensions support in the usual way utilising the existing"},{"line_number":98,"context_line":"neutron_extensions_cache."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Note: The new neutron API extension will be implemented in the ml2 plugin"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_1a0f3fe2","line":97,"range":{"start_line":97,"start_character":45,"end_line":97,"end_character":54},"updated":"2017-10-19 15:18:53.000000000","message":"\"utilizing\" I guess","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":106,"context_line":"The old interaction model should be removed when sufficient time has elapsed"},{"line_number":107,"context_line":"for all neutron backend to support this model with an aim of completing this"},{"line_number":108,"context_line":"in two cycles. We should keep this in mind in how the code is structured."},{"line_number":109,"context_line":"Given we are also looking at removing nova-network, we should see if this can"},{"line_number":110,"context_line":"be added as a new set of network API calls, that are only for neutron, making"},{"line_number":111,"context_line":"the existing calls needed for nova-network be no-ops for Neutron. We should"},{"line_number":112,"context_line":"have an explicit call for each step, rather than interpret what needs to"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_1addff41","line":109,"range":{"start_line":109,"start_character":0,"end_line":109,"end_character":50},"updated":"2017-10-19 15:18:53.000000000","message":"well, cellsv1 FTW for sure, but honestly, should we say that n-net is still there ?","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":118,"context_line":"regardless of the compute node version. Where a new neutron is deployed"},{"line_number":119,"context_line":"that supports this feature the following behaviour will be implemented."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* If both compute nodes are queens or newer. In this case the new workflow"},{"line_number":122,"context_line":"  will be used as described below."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* In all other cases the old workflow is used"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_faba23dc","line":121,"range":{"start_line":121,"start_character":5,"end_line":121,"end_character":9},"updated":"2017-10-19 15:18:53.000000000","message":"I\u0027m not a native English speaker, so I guess \"both\" means \"all of\" but meh.","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89a7a9c0327231fc4ba3e82078e3f23ade2b8205","unresolved":false,"context_lines":[{"line_number":118,"context_line":"regardless of the compute node version. Where a new neutron is deployed"},{"line_number":119,"context_line":"that supports this feature the following behaviour will be implemented."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* If both compute nodes are queens or newer. In this case the new workflow"},{"line_number":122,"context_line":"  will be used as described below."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* In all other cases the old workflow is used"}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_97709d74","line":121,"range":{"start_line":121,"start_character":5,"end_line":121,"end_character":9},"in_reply_to":"3f4b6375_faba23dc","updated":"2017-10-19 22:29:03.000000000","message":"Actually no, we explicitly want to be able to do the new thing if both the source and dest hosts are new enough to understand the new flow and what we cram into the migrate_data object. Then we don\u0027t have to make upgrading the entire deployment something that is necessary for this.","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0cb75811a7cc44de7d561f587a991ead3fd0b665","unresolved":false,"context_lines":[{"line_number":133,"context_line":"* check feature support on both hosts and fallback if not supported."},{"line_number":134,"context_line":"  This will be done in the conductor after check_can_live_migrate_destination."},{"line_number":135,"context_line":"  If the new flow is supported the conductor will cast to the source node"},{"line_number":136,"context_line":"  by calling live_migrateV2 else it will fallback to casting to live_migrate."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"* add a port binding on the destination host, in pre_live_migration phase"},{"line_number":139,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"3f4b6375_ba914b55","line":136,"updated":"2017-10-19 15:18:53.000000000","message":"Dan made a good upgrade point in the previous PS, I\u0027ll leave it explain it.","commit_id":"6d74ff8def89746503be391f885c7c01d148ed12"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89a7a9c0327231fc4ba3e82078e3f23ade2b8205","unresolved":false,"context_lines":[{"line_number":108,"context_line":"in two cycles. We should keep this in mind in how the code is structured."},{"line_number":109,"context_line":"Given we are also looking at removing nova-network, we should see if this can"},{"line_number":110,"context_line":"be added as a new set of network API calls, that are only for neutron, making"},{"line_number":111,"context_line":"the existing calls needed for nova-network be no-ops for Neutron. We should"},{"line_number":112,"context_line":"have an explicit call for each step, rather than interpret what needs to"},{"line_number":113,"context_line":"happen based on the host values passed into the method."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Migration across mixed software versions."},{"line_number":116,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3f4b6375_57746535","line":113,"range":{"start_line":111,"start_character":66,"end_line":113,"end_character":55},"updated":"2017-10-19 22:29:03.000000000","message":"This contradicts what we\u0027re doing now and makes it confusing, so let\u0027s just remove it.","commit_id":"782f9df72081ad77b7620b028fd5e9fb1f3ae494"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89a7a9c0327231fc4ba3e82078e3f23ade2b8205","unresolved":false,"context_lines":[{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* In pre_live_migration on destination"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"  * Check if migration_data contains new VIFs attribute, if not,"},{"line_number":182,"context_line":"    fail live-migration."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"  * If successful, plug vif on destination host using the new port bindings."},{"line_number":185,"context_line":"    else fall back to old workflow and plug vif with old vif bindings."}],"source_content_type":"text/x-rst","patch_set":15,"id":"3f4b6375_97e3fd05","line":182,"range":{"start_line":181,"start_character":4,"end_line":182,"end_character":24},"updated":"2017-10-19 22:29:03.000000000","message":"This is wrong - it should be fallback to the old way.","commit_id":"782f9df72081ad77b7620b028fd5e9fb1f3ae494"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89a7a9c0327231fc4ba3e82078e3f23ade2b8205","unresolved":false,"context_lines":[{"line_number":308,"context_line":"Other deployer impact"},{"line_number":309,"context_line":"---------------------"},{"line_number":310,"context_line":""},{"line_number":311,"context_line":"As mixed mode migration is out of scope, if you wish to upgrade to"},{"line_number":312,"context_line":"Queens and change network backends or security group drivers this must"},{"line_number":313,"context_line":"be done in two steps. First upgrade all compute nodes and the neutron"},{"line_number":314,"context_line":"server to queens. Second upgrade the neutron backend and/or security"},{"line_number":315,"context_line":"group driver. Once step one is complete it will be possible for you"},{"line_number":316,"context_line":"to use this feature to live migrate across different neutron backends."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Developer impact"},{"line_number":319,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3f4b6375_97cd3d5f","line":316,"range":{"start_line":311,"start_character":0,"end_line":316,"end_character":70},"updated":"2017-10-19 22:29:03.000000000","message":"This is invalid now since we said as long as the source and dest are upgraded we should be OK.","commit_id":"782f9df72081ad77b7620b028fd5e9fb1f3ae494"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89a7a9c0327231fc4ba3e82078e3f23ade2b8205","unresolved":false,"context_lines":[{"line_number":318,"context_line":"Developer impact"},{"line_number":319,"context_line":"----------------"},{"line_number":320,"context_line":""},{"line_number":321,"context_line":"This new flow should make explicit the state relationship between Nova"},{"line_number":322,"context_line":"and Neutron during a live-migration. This should help with the transition away"},{"line_number":323,"context_line":"from the nova-network dominated interaction patterns."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":"Implementation"},{"line_number":326,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3f4b6375_97f65d8f","line":323,"range":{"start_line":321,"start_character":0,"end_line":323,"end_character":53},"updated":"2017-10-19 22:29:03.000000000","message":"This arguably not going to be the case, since we\u0027re not doing brand new check/pre/live/post/rollback methods here, just putting stuff in the migrate_data object and checking it in the existing methods.","commit_id":"782f9df72081ad77b7620b028fd5e9fb1f3ae494"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e7594e9113aaeb8384a1050bc1f56ce685aa8232","unresolved":false,"context_lines":[{"line_number":164,"context_line":"            \u0027host_id\u0027: fields.StringField(),"},{"line_number":165,"context_line":"            \u0027vnic_type\u0027: fields.StringField(),  # could be enum"},{"line_number":166,"context_line":"            \u0027vif_type\u0027: fields.StringField(),"},{"line_number":167,"context_line":"            \u0027vif_details\u0027: fields.DictOfStringsField(),"},{"line_number":168,"context_line":"        }"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"    During implementation we will try to restrict the ``vif_details``"}],"source_content_type":"text/x-rst","patch_set":16,"id":"3f4b6375_b724b9c7","line":167,"range":{"start_line":167,"start_character":12,"end_line":167,"end_character":55},"updated":"2017-10-19 22:31:07.000000000","message":"This isn\u0027t what we said during the call today, but there is a hedge in the paragraph below. This object is also missing a vif_profile entry which I thought was needed, but I don\u0027t want to get too far into the implementation weeds.","commit_id":"58f73b1320e1afac33d12db494e74ccd3b127a7e"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e4bee6d6d244a760759c4b337b71fbfcdfa5905a","unresolved":false,"context_lines":[{"line_number":168,"context_line":"        }"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"    During implementation we will try to restrict the ``vif_details``"},{"line_number":171,"context_line":"    field to the subset of vif_details required by nova to generate"},{"line_number":172,"context_line":"    the updated domain xml and plug the vif. This is to avoid random"},{"line_number":173,"context_line":"    ML2 backend-specific data from changing behavior in our versioned"},{"line_number":174,"context_line":"    object. In the future this object will be replaced by one defined"},{"line_number":175,"context_line":"    by os-vif."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"* In pre_live_migration on destination:"}],"source_content_type":"text/x-rst","patch_set":16,"id":"3f4b6375_da74fc9b","line":174,"range":{"start_line":171,"start_character":45,"end_line":174,"end_character":11},"updated":"2017-10-19 22:38:57.000000000","message":"Also known as \"being upgrade clean\". I don\u0027t really agree with this statement but we can argue in the implementation.","commit_id":"58f73b1320e1afac33d12db494e74ccd3b127a7e"}]}