)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Closes-Bug: #1414559"},{"line_number":21,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"7f287b81_dd169ba8","line":18,"range":{"start_line":14,"start_character":18,"end_line":18,"end_character":16},"updated":"2017-09-27 16:39:04.000000000","message":"Could you reword this? I don\u0027t understand","commit_id":"07745757472cbeb58f72a139e328766a7da8210e"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7990d767be06312d4ce6f8a70133e8dfd7c439b3","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f287b81_56b768f6","line":15,"range":{"start_line":14,"start_character":55,"end_line":15,"end_character":10},"updated":"2018-01-10 11:11:50.000000000","message":"this is not specific to the linux bridge i also effect ovs.","commit_id":"3aa0599a0454817fad15c3fd4e1bc9b1dcdaead7"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"f1d8c27e8d3a4be00e76667a1c52fc4521f698e8","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f96bb07_011eec0b","line":15,"range":{"start_line":14,"start_character":55,"end_line":15,"end_character":10},"in_reply_to":"7f287b81_56b768f6","updated":"2018-01-10 16:01:44.000000000","message":"hhmm. But the code is only listening to linuxbridge events, isn\u0027t it?","commit_id":"3aa0599a0454817fad15c3fd4e1bc9b1dcdaead7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"08e4f166cace19a8f7a72e627b5372e71848c2b6","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f96bb07_61efb087","line":15,"range":{"start_line":14,"start_character":55,"end_line":15,"end_character":10},"in_reply_to":"7f96bb07_011eec0b","updated":"2018-01-10 16:22:04.000000000","message":"https://review.openstack.org/#/c/246898/22 modifed the ml2 rpc layer to notify nova on port change, this is not specific to are ml2 driver used so you should get the same notifiction when the ovs mech driver finish plugging the interface on the destination also. ill copy this to the latest revision as i did not intend this to by on pathset 4","commit_id":"3aa0599a0454817fad15c3fd4e1bc9b1dcdaead7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7990d767be06312d4ce6f8a70133e8dfd7c439b3","unresolved":false,"context_lines":[{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Closes-Bug: #1414559"},{"line_number":21,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"7f287b81_3695fc40","line":18,"range":{"start_line":17,"start_character":27,"end_line":18,"end_character":16},"updated":"2018-01-10 11:11:50.000000000","message":"this also effect vhost-user.","commit_id":"3aa0599a0454817fad15c3fd4e1bc9b1dcdaead7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2017-09-13 06:29:12 -0400"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"libvirt: slowly live-migration to ensure network is ready"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In Neutron, the commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58"},{"line_number":10,"context_line":"introduced events sent during a live migration where the VIFs are well"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_721752ef","line":7,"range":{"start_line":7,"start_character":9,"end_line":7,"end_character":15},"updated":"2017-09-13 13:48:03.000000000","message":"slow","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"libvirt: slowly live-migration to ensure network is ready"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In Neutron, the commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58"},{"line_number":10,"context_line":"introduced events sent during a live migration where the VIFs are well"},{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_329f8ab5","line":9,"range":{"start_line":9,"start_character":0,"end_line":9,"end_character":22},"updated":"2017-09-13 13:48:03.000000000","message":"In Neutron, commit","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":7,"context_line":"libvirt: slowly live-migration to ensure network is ready"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In Neutron, the commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58"},{"line_number":10,"context_line":"introduced events sent during a live migration where the VIFs are well"},{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_b2937aa3","line":10,"range":{"start_line":10,"start_character":47,"end_line":10,"end_character":52},"updated":"2017-09-13 13:48:03.000000000","message":"when","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":10,"context_line":"introduced events sent during a live migration where the VIFs are well"},{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_52ea160f","line":13,"range":{"start_line":13,"start_character":52,"end_line":13,"end_character":59},"updated":"2017-09-13 13:48:03.000000000","message":"wait","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_12f48ef1","line":14,"range":{"start_line":14,"start_character":7,"end_line":14,"end_character":16},"updated":"2017-09-13 13:48:03.000000000","message":"completing","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":11,"context_line":"plugged on destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_5238d69e","line":15,"range":{"start_line":14,"start_character":55,"end_line":15,"end_character":10},"updated":"2017-09-13 13:48:03.000000000","message":"the linux bridge agent is not used in the hybrid plug case this is fixing. the linux bridge that is created in hybrid plug is created by os-vif and the neutron ovs l2 agent is runnig on the platform.","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_12292e37","line":16,"range":{"start_line":15,"start_character":66,"end_line":16,"end_character":19},"updated":"2017-09-13 13:48:03.000000000","message":"veth pair is attached to ovs.","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":13,"context_line":"This commit takes care of making the live migration waiting for events"},{"line_number":14,"context_line":"before to finish. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Closes-Bug: #1414559"},{"line_number":21,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":6,"id":"5f2577a7_d2228652","line":18,"range":{"start_line":16,"start_character":19,"end_line":18,"end_character":16},"updated":"2017-09-13 13:48:03.000000000","message":"This process cannot be started before libvirt has created the tap device for the vm.","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":7,"context_line":"libvirt: slow live-migration to ensure network is ready"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In Neutron, commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58 introduced"},{"line_number":10,"context_line":"events sent during a live migration whene the VIFs are well plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration wait for events"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"7f515b1d_19324960","line":10,"range":{"start_line":10,"start_character":55,"end_line":10,"end_character":59},"updated":"2017-09-27 16:39:04.000000000","message":"Drop this?","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":7,"context_line":"libvirt: slow live-migration to ensure network is ready"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In Neutron, commit b7c303ee0a16a05c1fdb476dc7f4c7ca623a3f58 introduced"},{"line_number":10,"context_line":"events sent during a live migration whene the VIFs are well plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration wait for events"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"7f515b1d_b9fb3577","line":10,"range":{"start_line":10,"start_character":36,"end_line":10,"end_character":41},"updated":"2017-09-27 16:39:04.000000000","message":"when","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":10,"context_line":"events sent during a live migration whene the VIFs are well plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This commit takes care of making the live migration wait for events"},{"line_number":14,"context_line":"before completing. It\u0027s important to note that, because Linux Bridge"},{"line_number":15,"context_line":"agent mech is detecting new networks on destination only when the TAP"},{"line_number":16,"context_line":"devices are created we can\u0027t make this process before to have called"},{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Depends-of: https://review.openstack.org/#/c/506182/"},{"line_number":21,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"7f515b1d_d9ba716c","line":18,"range":{"start_line":13,"start_character":0,"end_line":18,"end_character":16},"updated":"2017-09-27 16:39:04.000000000","message":"The Linux bridge agent mechanism driver is detecting new networks on the destination host only when the TAP devices are created, and these tap devices are only created when libvirt starts the migration. As a result, we must actually start the migration and then slow it as we wait for the neutron events.\n\nThis change ensures we wait for these events.","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Depends-of: https://review.openstack.org/#/c/506182/"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: #1414559"},{"line_number":23,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"7f515b1d_99263915","line":20,"range":{"start_line":20,"start_character":0,"end_line":20,"end_character":52},"updated":"2017-09-27 16:39:04.000000000","message":"I don\u0027t think this is the correct syntax (also, typo). Do you really want to wait on the merge for this to go in?\n\n  Depends-On: Icb039ae2d465e3822ab07ae4f9bc405c1362afba","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"36ff61fb7a6bce480902261143aa70af7a27d7fa","unresolved":false,"context_lines":[{"line_number":17,"context_line":"libvirt to start migration (since libvirt is responsible of creating"},{"line_number":18,"context_line":"the TAP devices)"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Depends-of: https://review.openstack.org/#/c/506182/"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: #1414559"},{"line_number":23,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"7f515b1d_69711aa8","line":20,"range":{"start_line":20,"start_character":0,"end_line":20,"end_character":52},"in_reply_to":"7f515b1d_99263915","updated":"2017-10-02 10:14:14.000000000","message":"Yes, if we don\u0027t wait for that fix, Nova will never receive the events and so we are going to hurt the Timeout each time.","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e2ec08e97b9a582155f8db81da69a14ec840f21","unresolved":false,"context_lines":[{"line_number":10,"context_line":"events sent during a live migration when the VIFs are plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"The Linux bridge agent mechanism driver is detecting new networks on"},{"line_number":14,"context_line":"the destination host only when the TAP devices are created, and these"},{"line_number":15,"context_line":"tap devices are only created when libvirt starts the migration. As a"},{"line_number":16,"context_line":"result, we must actually start the migration and then slow it as we"},{"line_number":17,"context_line":"wait for the neutron events."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"This change ensures we wait for these events."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":16,"id":"7f96bb07_01734ce9","line":17,"range":{"start_line":13,"start_character":0,"end_line":17,"end_character":28},"updated":"2018-01-10 16:30:16.000000000","message":"the new notification sent by neutron is emited in the update_device_up rpc call in the ml2 plugin not be the linux bridge mech driver so it will be emited for all ml2 backend not just linux bridge when neutron set the port as active.","commit_id":"67259a6d19af5606784703bfda1ae0301cf52300"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"7cd044e577eb0e6135881aa34a41dcc828ecd630","unresolved":false,"context_lines":[{"line_number":10,"context_line":"events sent during a live migration when the VIFs are plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"The Linux bridge agent mechanism driver is detecting new networks on"},{"line_number":14,"context_line":"the destination host only when the TAP devices are created, and these"},{"line_number":15,"context_line":"tap devices are only created when libvirt starts the migration. As a"},{"line_number":16,"context_line":"result, we must actually start the migration and then slow it as we"},{"line_number":17,"context_line":"wait for the neutron events."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"This change ensures we wait for these events."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":16,"id":"7f96bb07_c2d22935","line":17,"range":{"start_line":13,"start_character":0,"end_line":17,"end_character":28},"in_reply_to":"7f96bb07_01734ce9","updated":"2018-01-11 15:06:31.000000000","message":"Context of this patch is for linux-bridge. handling ovs would need more changes since we setup the bridge on destination node in pre-live-migration step.","commit_id":"67259a6d19af5606784703bfda1ae0301cf52300"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5d6f6959a42e0dc5db05fb6cb19ec5bfd740cfa9","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Depends-On: Icb039ae2d465e3822ab07ae4f9bc405c1362afba"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Closes-Bug: #1414559"},{"line_number":24,"context_line":"Signed-off-by: Sahid Orentino Ferdjaoui \u003csahid.ferdjaoui@redhat.com\u003e"},{"line_number":25,"context_line":"Change-Id: I407034374fe17c4795762aa32575ba72d3a46fe8"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":17,"id":"7f96bb07_c26f86c3","line":23,"range":{"start_line":23,"start_character":0,"end_line":23,"end_character":11},"updated":"2018-01-11 16:41:25.000000000","message":"this should be Related-Bug since that bug is specificaly for ovs not linux bridge which is the scope of this patch","commit_id":"3b222a18cacd43c12e48dc55a95e660fee67e86d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":14,"context_line":"the destination host only when the TAP devices are created, and these"},{"line_number":15,"context_line":"tap devices are only created when libvirt starts the migration. As a"},{"line_number":16,"context_line":"result, we must actually start the migration and then slow it as we"},{"line_number":17,"context_line":"wait for the neutron events."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"This change ensures we wait for these events."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":18,"id":"5f93b717_a25e6a73","line":17,"updated":"2018-01-31 14:15:14.000000000","message":"Can you explain more about the logic here? Why do we need to slow it down until we get those events and then speed it back up regardless of whether or not they come in?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"19ea6a1ce98424a029130afda23483b4f688e000","unresolved":false,"context_lines":[{"line_number":10,"context_line":"events sent during a live migration when the VIFs are plugged on"},{"line_number":11,"context_line":"destination node."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"The Linux bridge agent mechanism driver is detecting new networks on"},{"line_number":14,"context_line":"the destination host only when the TAP devices are created, and these"},{"line_number":15,"context_line":"tap devices are only created when libvirt starts the migration. As a"},{"line_number":16,"context_line":"result, we must actually start the migration and then slow it as we"},{"line_number":17,"context_line":"wait for the neutron events."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"This change ensures we wait for these events."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":27,"id":"df7087c5_936ef8fd","line":17,"range":{"start_line":13,"start_character":0,"end_line":17,"end_character":28},"updated":"2018-03-15 20:37:44.000000000","message":"This seems eerily similar to the issues that resulted in this patch to *not* wait for vif plug events during a hard reboot because the linuxbridge agent couldn\u0027t be relied upon to send those events after we unplugged and then re-plugged the vifs:\n\nhttps://review.openstack.org/#/c/540168/\n\nMaybe there is a subtle difference between hard reboot and live migration though, because with the former we don\u0027t change the port host binding, but with live migration we will.\n\nAnd with https://review.openstack.org/#/c/553035/ yesterday I\u0027m a bit shy about these types of changes now, especially when we don\u0027t have a multi-node linuxbridge job running live migration against this patch.\n\nI\u0027ll once again poke around our CI system to see if I can whip together a patch to run a multinode linuxbridge job that depends on this patch and then we can see that it\u0027s working as expected in a real environment.","commit_id":"98d2584685c781c546a0fc0fb7f09beecd157540"}],"nova/tests/unit/virt/libvirt/test_driver.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":8794,"context_line":"        vdmock \u003d self.mox.CreateMock(fakelibvirt.virDomain)"},{"line_number":8795,"context_line":"        guest \u003d libvirt_guest.Guest(vdmock)"},{"line_number":8796,"context_line":"        self.mox.StubOutWithMock(vdmock, \"migrateToURI2\")"},{"line_number":8797,"context_line":"        _bandwidth \u003d 1"},{"line_number":8798,"context_line":"        vdmock.XMLDesc(flags\u003dfakelibvirt.VIR_DOMAIN_XML_MIGRATABLE).AndReturn("},{"line_number":8799,"context_line":"                initial_xml)"},{"line_number":8800,"context_line":"        vdmock.migrateToURI2(drvr._live_migration_uri(\u0027dest\u0027),"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_7e8729b8","line":8797,"range":{"start_line":8797,"start_character":21,"end_line":8797,"end_character":22},"updated":"2018-03-19 15:42:14.000000000","message":"nit: could use the MIN_MIGRATION_SPEED_BW constant here.","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":10512,"context_line":"        instance \u003d objects.Instance(**self.test_instance)"},{"line_number":10513,"context_line":"        instance.info_cache \u003d objects.InstanceInfoCache("},{"line_number":10514,"context_line":"            network_info\u003dnetwork_model.NetworkInfo(["},{"line_number":10515,"context_line":"                network_model.VIF(id\u003d\u00271\u0027,"},{"line_number":10516,"context_line":"                                  type\u003dnetwork_model.VIF_TYPE_BRIDGE)]))"},{"line_number":10517,"context_line":""},{"line_number":10518,"context_line":"        dom \u003d fakelibvirt.Domain(drvr._get_connection(),"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_1e506d32","line":10515,"range":{"start_line":10515,"start_character":38,"end_line":10515,"end_character":39},"updated":"2018-03-19 15:42:14.000000000","message":"nit: normally this is a uuid for a port id, but it\u0027s not enforced.","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":10561,"context_line":"            self.context, instance, guest, \"fakehost\","},{"line_number":10562,"context_line":"            fake_post, fake_recover, True,"},{"line_number":10563,"context_line":"            migrate_data, AnyEventletEvent(), disks_to_copy[0])"},{"line_number":10564,"context_line":"        guest.migrate_configure_max_speed.assert_called_once_with(0)"},{"line_number":10565,"context_line":""},{"line_number":10566,"context_line":"        prepare.assert_has_calls(["},{"line_number":10567,"context_line":"            mock.call(instance, \u0027network-vif-plugged-1\u0027)])"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_be12a161","line":10564,"range":{"start_line":10564,"start_character":66,"end_line":10564,"end_character":67},"updated":"2018-03-19 15:42:14.000000000","message":"nit: probably best to use the config option here.","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":10565,"context_line":""},{"line_number":10566,"context_line":"        prepare.assert_has_calls(["},{"line_number":10567,"context_line":"            mock.call(instance, \u0027network-vif-plugged-1\u0027)])"},{"line_number":10568,"context_line":"        for event in generated_events:"},{"line_number":10569,"context_line":"            event.wait.assert_called_once_with()"},{"line_number":10570,"context_line":""},{"line_number":10571,"context_line":"    @mock.patch.object(host.Host, \"get_connection\")"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_5e034510","line":10568,"range":{"start_line":10568,"start_character":21,"end_line":10568,"end_character":37},"updated":"2018-03-19 15:42:14.000000000","message":"nit: should probably assert the length of this is what you expect.","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":10619,"context_line":"            self.context, instance, guest, \"fakehost\","},{"line_number":10620,"context_line":"            fake_post, fake_recover, True,"},{"line_number":10621,"context_line":"            migrate_data, AnyEventletEvent(), disks_to_copy[0])"},{"line_number":10622,"context_line":"        self.assertEqual(0, guest.migrate_configure_max_speed.called)"},{"line_number":10623,"context_line":""},{"line_number":10624,"context_line":"    @mock.patch.object(host.Host, \"get_connection\")"},{"line_number":10625,"context_line":"    @mock.patch.object(utils, \"spawn\")"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_4934edde","line":10622,"range":{"start_line":10622,"start_character":8,"end_line":10622,"end_character":69},"updated":"2018-03-19 15:42:14.000000000","message":"This should either be comparing to a boolean if using \u0027called\u0027 or it should be using \u0027call_count\u0027.\n\nhttps://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.called\n\nhttps://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.call_count\n\nor just: guest.migrate_configure_max_speed.assert_not_called()","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":10675,"context_line":"            self.context, instance, guest, \"fakehost\","},{"line_number":10676,"context_line":"            fake_post, fake_recover, True,"},{"line_number":10677,"context_line":"            migrate_data, AnyEventletEvent(), disks_to_copy[0])"},{"line_number":10678,"context_line":"        self.assertEqual(0, guest.migrate_configure_max_speed.called)"},{"line_number":10679,"context_line":""},{"line_number":10680,"context_line":"    def _do_test_create_images_and_backing(self, disk_type):"},{"line_number":10681,"context_line":"        instance \u003d objects.Instance(**self.test_instance)"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_c9555dfc","line":10678,"range":{"start_line":10678,"start_character":8,"end_line":10678,"end_character":69},"updated":"2018-03-19 15:42:14.000000000","message":"same as above","commit_id":"46548078e03d1c14a495b019045b539cc498616a"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6708,"context_line":""},{"line_number":6709,"context_line":"        # Before to continue process of live migration we have to"},{"line_number":6710,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6711,"context_line":"        LOG.debug(\"Slowly the migration process (Pausing) until to receive \""},{"line_number":6712,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6713,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6714,"context_line":"        guest.migrate_configure_max_speed(1)"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_efa2394b","line":6711,"range":{"start_line":6711,"start_character":19,"end_line":6711,"end_character":24},"updated":"2017-09-13 13:48:03.000000000","message":"Slow","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6708,"context_line":""},{"line_number":6709,"context_line":"        # Before to continue process of live migration we have to"},{"line_number":6710,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6711,"context_line":"        LOG.debug(\"Slowly the migration process (Pausing) until to receive \""},{"line_number":6712,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6713,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6714,"context_line":"        guest.migrate_configure_max_speed(1)"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_2fc281ea","line":6711,"range":{"start_line":6711,"start_character":64,"end_line":6711,"end_character":74},"updated":"2017-09-13 13:48:03.000000000","message":"nova receives","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6711,"context_line":"        LOG.debug(\"Slowly the migration process (Pausing) until to receive \""},{"line_number":6712,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6713,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6714,"context_line":"        guest.migrate_configure_max_speed(1)"},{"line_number":6715,"context_line":""},{"line_number":6716,"context_line":"        opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6717,"context_line":"                                     context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_2f672128","line":6714,"range":{"start_line":6714,"start_character":8,"end_line":6714,"end_character":44},"updated":"2017-09-13 13:48:03.000000000","message":"what units i this in? MB/s GB/s ?","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6731,"context_line":"        # Let eventlet schedule the new thread right away"},{"line_number":6732,"context_line":"        time.sleep(0)"},{"line_number":6733,"context_line":""},{"line_number":6734,"context_line":"        # In case of OVS hybrid, during pre-live-migration Nova"},{"line_number":6735,"context_line":"        # created on destination node the bridges which the Neutron"},{"line_number":6736,"context_line":"        # agent should detect. Then receiving the events from Neutron"},{"line_number":6737,"context_line":"        # is ensuring that everything is well configured."}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_8f817592","line":6734,"range":{"start_line":6734,"start_character":21,"end_line":6734,"end_character":31},"updated":"2017-09-13 13:48:03.000000000","message":"OVS_HYBRID_PLUG\u003dTrue","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6734,"context_line":"        # In case of OVS hybrid, during pre-live-migration Nova"},{"line_number":6735,"context_line":"        # created on destination node the bridges which the Neutron"},{"line_number":6736,"context_line":"        # agent should detect. Then receiving the events from Neutron"},{"line_number":6737,"context_line":"        # is ensuring that everything is well configured."},{"line_number":6738,"context_line":"        #"},{"line_number":6739,"context_line":"        # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6740,"context_line":"        # devices on destination node which they are going to be"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_921d1e68","line":6737,"range":{"start_line":6737,"start_character":10,"end_line":6737,"end_character":12},"updated":"2017-09-13 13:48:03.000000000","message":"will","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6737,"context_line":"        # is ensuring that everything is well configured."},{"line_number":6738,"context_line":"        #"},{"line_number":6739,"context_line":"        # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6740,"context_line":"        # devices on destination node which they are going to be"},{"line_number":6741,"context_line":"        # created by libvirt at the very beginning of the"},{"line_number":6742,"context_line":"        # live-migration process. Then receiving the events from"},{"line_number":6743,"context_line":"        # Neutron is ensuring that everything is well configured."}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_3251ca0f","line":6740,"range":{"start_line":6740,"start_character":37,"end_line":6740,"end_character":48},"updated":"2017-09-13 13:48:03.000000000","message":"\" which they\" -\u003e \". They\"","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"        # devices on destination node which they are going to be"},{"line_number":6741,"context_line":"        # created by libvirt at the very beginning of the"},{"line_number":6742,"context_line":"        # live-migration process. Then receiving the events from"},{"line_number":6743,"context_line":"        # Neutron is ensuring that everything is well configured."},{"line_number":6744,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6745,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6746,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_12712eaa","line":6743,"range":{"start_line":6743,"start_character":49,"end_line":6743,"end_character":64},"updated":"2017-09-13 13:48:03.000000000","message":"configured correctly.","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0ad022e9c92add3b47313ed0c61f91b4665900d4","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"        # devices on destination node which they are going to be"},{"line_number":6741,"context_line":"        # created by libvirt at the very beginning of the"},{"line_number":6742,"context_line":"        # live-migration process. Then receiving the events from"},{"line_number":6743,"context_line":"        # Neutron is ensuring that everything is well configured."},{"line_number":6744,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6745,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6746,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":6,"id":"5f2577a7_327aea87","line":6743,"range":{"start_line":6743,"start_character":18,"end_line":6743,"end_character":29},"updated":"2017-09-13 13:48:03.000000000","message":"will ensure","commit_id":"7d7e8158e4209a926b49af319da5da6e36be0873"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"738c972d3e5c233d681f5117b62aca038290e72e","unresolved":false,"context_lines":[{"line_number":6756,"context_line":"            bandwidth \u003d CONF.libvirt.live_migration_bandwidth"},{"line_number":6757,"context_line":"            LOG.debug(\u0027VIFs events received, continuing migration, \u0027"},{"line_number":6758,"context_line":"                      \u0027bandwidth: %d\u0027, bandwidth, instance\u003dinstance)"},{"line_number":6759,"context_line":"            guest.migrate_configure_max_speed(bandwidth)"},{"line_number":6760,"context_line":""},{"line_number":6761,"context_line":"        try:"},{"line_number":6762,"context_line":"            LOG.debug(\"Starting monitoring of live migration\","}],"source_content_type":"text/x-python","patch_set":7,"id":"bf57530f_6eaa1986","line":6759,"updated":"2017-09-20 13:45:54.000000000","message":"I should probably make this in a finally so even if a timeout happen we re-set the migration bw as normal","commit_id":"94497f8967efd2b9886e5b9b39c80860ac0890b3"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":6755,"context_line":"            LOG.debug(\u0027VIFs events received, continuing migration, \u0027"},{"line_number":6756,"context_line":"                      \u0027bandwidth: %d\u0027, CONF.libvirt.live_migration_bandwidth,"},{"line_number":6757,"context_line":"                      instance\u003dinstance)"},{"line_number":6758,"context_line":"        finally:"},{"line_number":6759,"context_line":"            # Even if quit \u0027wait_for_instance_event\u0027 with a timeout or"},{"line_number":6760,"context_line":"            # events received we should reconfigure QEMU to use the"},{"line_number":6761,"context_line":"            # maximun bandwidth."}],"source_content_type":"text/x-python","patch_set":10,"id":"7f515b1d_8bc49c60","line":6758,"range":{"start_line":6758,"start_character":8,"end_line":6758,"end_character":16},"updated":"2017-09-27 16:39:04.000000000","message":"Yeah, we want this in case a different exception than \u0027eventlet.timeout.Timeout\u0027 is raised","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c654a990724e748b0315a84f9223818a0d3482c2","unresolved":false,"context_lines":[{"line_number":6758,"context_line":"        finally:"},{"line_number":6759,"context_line":"            # Even if quit \u0027wait_for_instance_event\u0027 with a timeout or"},{"line_number":6760,"context_line":"            # events received we should reconfigure QEMU to use the"},{"line_number":6761,"context_line":"            # maximun bandwidth."},{"line_number":6762,"context_line":"            guest.migrate_configure_max_speed("},{"line_number":6763,"context_line":"                CONF.libvirt.live_migration_bandwidth)"},{"line_number":6764,"context_line":""}],"source_content_type":"text/x-python","patch_set":10,"id":"7f515b1d_3965051f","line":6761,"range":{"start_line":6761,"start_character":14,"end_line":6761,"end_character":21},"updated":"2017-09-27 16:39:04.000000000","message":"maximum","commit_id":"07f6bf44fb40b8db80f180806a1dfc5c921e7b0c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aef87a53fda831e598f24c9ae2ef8049f3a8aa1a","unresolved":false,"context_lines":[{"line_number":5191,"context_line":"        # anything that might be stale (cache-wise) assume it\u0027s"},{"line_number":5192,"context_line":"        # already up so we don\u0027t block on it."},{"line_number":5193,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5194,"context_line":"                for vif in network_info if vif.get(\u0027active\u0027, True) is False]"},{"line_number":5195,"context_line":""},{"line_number":5196,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5197,"context_line":"        # Neutron should send to Nova events indicating that the VIFs"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_d4bcd36a","line":5194,"range":{"start_line":5194,"start_character":40,"end_line":5194,"end_character":75},"updated":"2017-10-11 14:02:47.000000000","message":"You don\u0027t care about filtering out VIFs that are inactive during live migration?","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"41ff156d7d2354277bf2c3f564c9bd4bbc8d9caa","unresolved":false,"context_lines":[{"line_number":6709,"context_line":"            disk_paths, device_names \u003d self._live_migration_copy_disk_paths("},{"line_number":6710,"context_line":"                context, instance, guest)"},{"line_number":6711,"context_line":""},{"line_number":6712,"context_line":"        # Before to continue process of live migration we have to"},{"line_number":6713,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6714,"context_line":"        LOG.debug(\"Slow the migration process (Pausing) until Nova receives \""},{"line_number":6715,"context_line":"                  \"network events indicating everything is setup. \""}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_0f8ff22a","line":6712,"range":{"start_line":6712,"start_character":10,"end_line":6712,"end_character":28},"updated":"2017-10-11 14:11:18.000000000","message":"s/to/we/ ?","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aef87a53fda831e598f24c9ae2ef8049f3a8aa1a","unresolved":false,"context_lines":[{"line_number":6713,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6714,"context_line":"        LOG.debug(\"Slow the migration process (Pausing) until Nova receives \""},{"line_number":6715,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6716,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6717,"context_line":"        guest.migrate_configure_max_speed(1)"},{"line_number":6718,"context_line":""},{"line_number":6719,"context_line":"        opthread \u003d utils.spawn(self._live_migration_operation,"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_74807f8c","line":6716,"range":{"start_line":6716,"start_character":48,"end_line":6716,"end_character":72},"updated":"2017-10-11 14:02:47.000000000","message":"The config option help on this says:\n\n\"Some hypervisors\ndo not support this feature and will return an error if bandwidth is not 0.\nPlease refer to the libvirt documentation for further details.\"\n\nSo should we only be doing this for kvm/qemu? Could this fail for others like xen or parallels?\n\nhttps://libvirt.org/html/libvirt-libvirt-domain.html#VIR_MIGRATE_PARAM_BANDWIDTH\n\nI guess the docs don\u0027t say.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"41ff156d7d2354277bf2c3f564c9bd4bbc8d9caa","unresolved":false,"context_lines":[{"line_number":6713,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6714,"context_line":"        LOG.debug(\"Slow the migration process (Pausing) until Nova receives \""},{"line_number":6715,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6716,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6717,"context_line":"        guest.migrate_configure_max_speed(1)"},{"line_number":6718,"context_line":""},{"line_number":6719,"context_line":"        opthread \u003d utils.spawn(self._live_migration_operation,"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_8f91a255","line":6716,"range":{"start_line":6716,"start_character":48,"end_line":6716,"end_character":72},"in_reply_to":"5f4e5783_74807f8c","updated":"2017-10-11 14:11:18.000000000","message":"Presumably this effectively breaks live migration under nova-network, right? While we care less and less, we do need a functional handover release between cellsv1/n-net and cellsv2/neutron.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fad78b7cb7bd3ffc5d2bc9c253a65f0db0ee9557","unresolved":false,"context_lines":[{"line_number":6713,"context_line":"        # ensure the VIFs on destination node are ready."},{"line_number":6714,"context_line":"        LOG.debug(\"Slow the migration process (Pausing) until Nova receives \""},{"line_number":6715,"context_line":"                  \"network events indicating everything is setup. \""},{"line_number":6716,"context_line":"                  \"(default: %d)\", CONF.libvirt.live_migration_bandwidth)"},{"line_number":6717,"context_line":"        guest.migrate_configure_max_speed(1)"},{"line_number":6718,"context_line":""},{"line_number":6719,"context_line":"        opthread \u003d utils.spawn(self._live_migration_operation,"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_0a1fe06c","line":6716,"range":{"start_line":6716,"start_character":48,"end_line":6716,"end_character":72},"in_reply_to":"5f4e5783_8f91a255","updated":"2017-10-11 14:55:25.000000000","message":"Right, because nova-network would never raise the neutron event. Damn it.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aef87a53fda831e598f24c9ae2ef8049f3a8aa1a","unresolved":false,"context_lines":[{"line_number":6734,"context_line":"        # Let eventlet schedule the new thread right away"},{"line_number":6735,"context_line":"        time.sleep(0)"},{"line_number":6736,"context_line":""},{"line_number":6737,"context_line":"        # In case of OVS hybrid plug, during pre-live-migration Nova"},{"line_number":6738,"context_line":"        # created on destination node the bridges which the Neutron"},{"line_number":6739,"context_line":"        # agent should detect. Then receiving the events from Neutron"},{"line_number":6740,"context_line":"        # will ensure that everything is configured correclty."}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_6f1c266a","line":6737,"range":{"start_line":6737,"start_character":10,"end_line":6737,"end_character":36},"updated":"2017-10-11 14:02:47.000000000","message":"Could we avoid doing this wait for all other types of VIFs?","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"41e4427de42faa4a2f3084a559b92cfedab3770f","unresolved":false,"context_lines":[{"line_number":6734,"context_line":"        # Let eventlet schedule the new thread right away"},{"line_number":6735,"context_line":"        time.sleep(0)"},{"line_number":6736,"context_line":""},{"line_number":6737,"context_line":"        # In case of OVS hybrid plug, during pre-live-migration Nova"},{"line_number":6738,"context_line":"        # created on destination node the bridges which the Neutron"},{"line_number":6739,"context_line":"        # agent should detect. Then receiving the events from Neutron"},{"line_number":6740,"context_line":"        # will ensure that everything is configured correclty."}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_4a5158d8","line":6737,"range":{"start_line":6737,"start_character":10,"end_line":6737,"end_character":36},"in_reply_to":"5f4e5783_6f1c266a","updated":"2017-11-13 13:17:53.000000000","message":"I would say yes. That Neutron part has been designed for","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aef87a53fda831e598f24c9ae2ef8049f3a8aa1a","unresolved":false,"context_lines":[{"line_number":6743,"context_line":"        # devices on destination node. They are going to be created by"},{"line_number":6744,"context_line":"        # libvirt at the very beginning of the live-migration"},{"line_number":6745,"context_line":"        # process. Then receiving the events from Neutron will ensure"},{"line_number":6746,"context_line":"        # that everything is configured correclty."},{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_4f472a4d","line":6746,"range":{"start_line":6746,"start_character":40,"end_line":6746,"end_character":49},"updated":"2017-10-11 14:02:47.000000000","message":"correctly","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aef87a53fda831e598f24c9ae2ef8049f3a8aa1a","unresolved":false,"context_lines":[{"line_number":6744,"context_line":"        # libvirt at the very beginning of the live-migration"},{"line_number":6745,"context_line":"        # process. Then receiving the events from Neutron will ensure"},{"line_number":6746,"context_line":"        # that everything is configured correclty."},{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_ef40160a","line":6747,"range":{"start_line":6747,"start_character":23,"end_line":6747,"end_character":55},"updated":"2017-10-11 14:02:47.000000000","message":"nit: we now have instance.get_network_info() which handles the case that the info_cache is empty for some reason. I\u0027m not sure why it would be here though.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b494ae33b2121063a319f6cd4804563251aff1f5","unresolved":false,"context_lines":[{"line_number":6745,"context_line":"        # process. Then receiving the events from Neutron will ensure"},{"line_number":6746,"context_line":"        # that everything is configured correclty."},{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6751,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_e540370a","line":6748,"updated":"2017-10-11 15:07:34.000000000","message":"Looking at one of the live migration job runs, we have 0 events to wait for - why? We should at least have one vif per instance:\n\nhttp://logs.openstack.org/57/497457/11/check/legacy-tempest-dsvm-multinode-live-migration/9cd842e/logs/screen-n-cpu.txt.gz#_Oct_02_11_04_06_172675","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"911e99efcae392387a53da3b18715e2f96b5f39c","unresolved":false,"context_lines":[{"line_number":6745,"context_line":"        # process. Then receiving the events from Neutron will ensure"},{"line_number":6746,"context_line":"        # that everything is configured correclty."},{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6751,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_3637a1e6","line":6748,"in_reply_to":"5f4e5783_85cd035f","updated":"2017-10-11 19:50:06.000000000","message":"https://review.openstack.org/#/c/511283/ should get us testing live migration with actual networking setup on the instances.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14c46cd2ab3b739f2ff222c85b1c39ecaabecf60","unresolved":false,"context_lines":[{"line_number":6745,"context_line":"        # process. Then receiving the events from Neutron will ensure"},{"line_number":6746,"context_line":"        # that everything is configured correclty."},{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6751,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_85cd035f","line":6748,"in_reply_to":"5f4e5783_e540370a","updated":"2017-10-11 15:29:26.000000000","message":"Apparently the servers created in the live migration tests don\u0027t have a tenant network setup, I\u0027m not sure why.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"41ff156d7d2354277bf2c3f564c9bd4bbc8d9caa","unresolved":false,"context_lines":[{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6751,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6752,"context_line":"                LOG.debug(\"Waiting for VIFs plugged events: %s\","},{"line_number":6753,"context_line":"                          events, instance\u003dinstance)"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_6f48a6cb","line":6750,"updated":"2017-10-11 14:11:18.000000000","message":"This is a race, because this is not how this context manager is supposed to work. This sets up an event future and yields. You\u0027re supposed to do whatever thing would trigger the event _inside_ the context manager body so that we\u0027re already listening for it.\n\nIf we start the migration and then don\u0027t get to this line until after the event comes, we\u0027ll hang here until we timeout, log an error, etc.\n\nYou need to be using this context manager around the whole operation that starts the process and could generate the event. This was designed to operate this way so that we can reliably receive messages from another system in this way. Note how this is used in the spawn case.","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fad78b7cb7bd3ffc5d2bc9c253a65f0db0ee9557","unresolved":false,"context_lines":[{"line_number":6747,"context_line":"        network_info \u003d instance.info_cache.network_info"},{"line_number":6748,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(network_info)"},{"line_number":6749,"context_line":"        try:"},{"line_number":6750,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6751,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6752,"context_line":"                LOG.debug(\"Waiting for VIFs plugged events: %s\","},{"line_number":6753,"context_line":"                          events, instance\u003dinstance)"}],"source_content_type":"text/x-python","patch_set":11,"id":"5f4e5783_0a512037","line":6750,"in_reply_to":"5f4e5783_6f48a6cb","updated":"2017-10-11 14:55:25.000000000","message":"I wasn\u0027t aware that this  was how this context manager worked. Sorry for missing it :(","commit_id":"d62b917349fb850748fb98cee361498c74a3f8e2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0ab0836a082516c29232ca3fc9292dd8cb213839","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":6741,"context_line":"            events \u003d []"},{"line_number":6742,"context_line":"        try:"},{"line_number":6743,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6744,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6745,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6746,"context_line":"                                       context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":13,"id":"1f485f77_76d77ac1","line":6743,"updated":"2017-11-11 17:46:41.000000000","message":"I don\u0027t think this is doing what you expect. Looking at the logs in a live migration CI run, I see the waiting debug message above and then immediately after that I see the \u0027VIFs events received\u0027 message, with nothing in between about the actual processing of the VIF events from neutron, so I don\u0027t think we\u0027re really waiting for them.","commit_id":"2284f2be5fd40bd301a9c14ead62186c66cb7909"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f996f30ca4ad06c38364be9b7bffe7a67d071e9f","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":6741,"context_line":"            events \u003d []"},{"line_number":6742,"context_line":"        try:"},{"line_number":6743,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6744,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6745,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6746,"context_line":"                                       context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":13,"id":"1f485f77_919e64b6","line":6743,"in_reply_to":"1f485f77_2b6aa1b2","updated":"2017-11-13 15:38:47.000000000","message":"OK, maybe I can rig something together to run the live migration job with LB and make it depend on this patch to test it in our CI.","commit_id":"2284f2be5fd40bd301a9c14ead62186c66cb7909"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"e4c9164289dad18972e8421b291f8fb5b2458020","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":6741,"context_line":"            events \u003d []"},{"line_number":6742,"context_line":"        try:"},{"line_number":6743,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6744,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6745,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6746,"context_line":"                                       context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":13,"id":"1f485f77_2b6aa1b2","line":6743,"in_reply_to":"1f485f77_2c8abc1a","updated":"2017-11-13 14:19:51.000000000","message":"Oh I see, you are using ovs-hybrid on CI, please see line 5201, we are waiting for events only for LB.","commit_id":"2284f2be5fd40bd301a9c14ead62186c66cb7909"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"41e4427de42faa4a2f3084a559b92cfedab3770f","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":6741,"context_line":"            events \u003d []"},{"line_number":6742,"context_line":"        try:"},{"line_number":6743,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6744,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6745,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6746,"context_line":"                                       context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":13,"id":"1f485f77_2c8abc1a","line":6743,"in_reply_to":"1f485f77_76d77ac1","updated":"2017-11-13 13:17:53.000000000","message":"I need to investigate more on that, I\u0027m making tests locally and everything seemed to work","commit_id":"2284f2be5fd40bd301a9c14ead62186c66cb7909"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"debaee338711977b1262ab90eaf82698a505e621","unresolved":false,"context_lines":[{"line_number":6740,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":6741,"context_line":"            events \u003d []"},{"line_number":6742,"context_line":"        try:"},{"line_number":6743,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6744,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6745,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6746,"context_line":"                                       context, instance, dest,"}],"source_content_type":"text/x-python","patch_set":13,"id":"1f485f77_d01cbb6b","line":6743,"in_reply_to":"1f485f77_919e64b6","updated":"2017-11-14 12:57:34.000000000","message":"Yes, if you can have CI to also run live-migration with LB that would be perfect","commit_id":"2284f2be5fd40bd301a9c14ead62186c66cb7909"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"24a717d12524f9ecb481d3e58d73c57b77087d31","unresolved":false,"context_lines":[{"line_number":6743,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6744,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6745,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6746,"context_line":"            guest.migrate_configure_max_speed(1)"},{"line_number":6747,"context_line":""},{"line_number":6748,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6749,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":15,"id":"df87a7cf_dbf60164","line":6746,"updated":"2017-12-08 16:15:34.000000000","message":"So what does this magic number \"1\" mean? Is it really pausing the migration or is it just slowing down? the comment above is ambiguous. \n\nSo 2 things - the magic number and the ambiguous comment...","commit_id":"473e8c46acfa77256ab98834ce8d5b91c383d1d1"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7990d767be06312d4ce6f8a70133e8dfd7c439b3","unresolved":false,"context_lines":[{"line_number":6743,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6744,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6745,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6746,"context_line":"            guest.migrate_configure_max_speed(1)"},{"line_number":6747,"context_line":""},{"line_number":6748,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6749,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":15,"id":"9f91af0f_f90acdcf","line":6746,"in_reply_to":"9f91af0f_daf6dcd7","updated":"2018-01-10 11:11:50.000000000","message":"so yes as sahid said this is configuring the minium bandwith that can be used of 1 MiB/s\n\nto you second point re (pausing) technically it should be throttling as the migration still contiues just at a much reduced rate.\n\nSince the migration is never really paused, technically it is possible that it could complete before the networking is configured on the destination host but unless all you do is migrate lots of 64mb nano flavors instances all day long i highly doubt you will be able to tell the difference between actually pausing and throttling to 1 MiB/s","commit_id":"473e8c46acfa77256ab98834ce8d5b91c383d1d1"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"bbf76f43793162d71b5e34ac2f1644448cfb916a","unresolved":false,"context_lines":[{"line_number":6743,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6744,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6745,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6746,"context_line":"            guest.migrate_configure_max_speed(1)"},{"line_number":6747,"context_line":""},{"line_number":6748,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6749,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":15,"id":"7f96bb07_e172e07c","line":6746,"in_reply_to":"9f91af0f_f90acdcf","updated":"2018-01-10 15:59:45.000000000","message":"Ok, got it, thanks.\n\nSo I recommend to remove the verb \"pausing\" everywhere and use \"throttling\" instead. I also suggest to use a constant for 1, e.g. MIN_LIVE_MIGRATION_BANDWITH or similar.","commit_id":"473e8c46acfa77256ab98834ce8d5b91c383d1d1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"260ee9ced8b455fff2b375228d631951d9f25838","unresolved":false,"context_lines":[{"line_number":6743,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6744,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6745,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6746,"context_line":"            guest.migrate_configure_max_speed(1)"},{"line_number":6747,"context_line":""},{"line_number":6748,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6749,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":15,"id":"9f91af0f_daf6dcd7","line":6746,"in_reply_to":"df87a7cf_dbf60164","updated":"2018-01-10 09:41:02.000000000","message":"It configures the migration bw.\n\nhttps://review.openstack.org/#/c/497456/7/nova/virt/libvirt/guest.py","commit_id":"473e8c46acfa77256ab98834ce8d5b91c383d1d1"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"c7882d311c0185bb9e328c82a3340c0bd9e78078","unresolved":false,"context_lines":[{"line_number":6759,"context_line":"        try:"},{"line_number":6760,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6761,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6762,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6763,"context_line":"                                       context, instance, dest,"},{"line_number":6764,"context_line":"                                       block_migration,"},{"line_number":6765,"context_line":"                                       migrate_data, guest,"}],"source_content_type":"text/x-python","patch_set":15,"id":"df87a7cf_fee1739c","line":6762,"updated":"2017-12-08 16:47:41.000000000","message":"this all works as this is an asynchronous operation? Cause my guess is, that the wait_for_instance_event will only start waiting after the yield [1], which will happen once this line is executed - but my understanding might be wrong here. Double checking it might make sense...\n\n[1] https://github.com/openstack/nova/blob/476e7b534a161ee0855b8b765961b6417f95fb24/nova/compute/manager.py#L476","commit_id":"473e8c46acfa77256ab98834ce8d5b91c383d1d1"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1e2ec08e97b9a582155f8db81da69a14ec840f21","unresolved":false,"context_lines":[{"line_number":5193,"context_line":""},{"line_number":5194,"context_line":"        # TODO(sahid): Currenlty we only use the mechanism of waiting"},{"line_number":5195,"context_line":"        # neutron events during live-migration for linux-bridge."},{"line_number":5196,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5197,"context_line":"                for vif in network_info if ("},{"line_number":5198,"context_line":"                        vif.get(\u0027type\u0027) \u003d\u003d network_model.VIF_TYPE_BRIDGE)]"},{"line_number":5199,"context_line":""},{"line_number":5200,"context_line":"    def _cleanup_failed_start(self, context, instance, network_info,"},{"line_number":5201,"context_line":"                              block_device_info, guest, destroy_disks):"}],"source_content_type":"text/x-python","patch_set":16,"id":"7f96bb07_842c4a9a","line":5198,"range":{"start_line":5196,"start_character":8,"end_line":5198,"end_character":74},"updated":"2018-01-10 16:30:16.000000000","message":"Andreas was your comment about this only applying to libvirt due to the filtering we are doing here?\n\nif so why are we filtering to just linux brdige.\nwould it not make sense to to also do this for vif_type ovs when hybrid_plug\u003dno as libvirt creates the tap in this case also?","commit_id":"67259a6d19af5606784703bfda1ae0301cf52300"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"a197558e9e18435dda857e18509c956d4aa000f1","unresolved":false,"context_lines":[{"line_number":5193,"context_line":""},{"line_number":5194,"context_line":"        # TODO(sahid): Currenlty we only use the mechanism of waiting"},{"line_number":5195,"context_line":"        # neutron events during live-migration for linux-bridge."},{"line_number":5196,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5197,"context_line":"                for vif in network_info if ("},{"line_number":5198,"context_line":"                        vif.get(\u0027type\u0027) \u003d\u003d network_model.VIF_TYPE_BRIDGE)]"},{"line_number":5199,"context_line":""},{"line_number":5200,"context_line":"    def _cleanup_failed_start(self, context, instance, network_info,"},{"line_number":5201,"context_line":"                              block_device_info, guest, destroy_disks):"}],"source_content_type":"text/x-python","patch_set":16,"id":"7f96bb07_b5bde469","line":5198,"range":{"start_line":5196,"start_character":8,"end_line":5198,"end_character":74},"in_reply_to":"7f96bb07_842c4a9a","updated":"2018-01-11 08:05:33.000000000","message":"Yes that was my point. We\u0027re filtering for vif_type_bridge only (which is linuxbridge, isn\u0027t it?).\n\nAnd yes, in the case of ovs hybrid_plug\u003dno libvirt is also creating the tap. So it might make sense to extend it to this as well...\n\nI don\u0027t know how the vhostuser support works..but if it works the same way, that it might make sense as well..","commit_id":"67259a6d19af5606784703bfda1ae0301cf52300"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"17ab454289e20e0138073ad66d9da5df1a1ac83a","unresolved":false,"context_lines":[{"line_number":5193,"context_line":""},{"line_number":5194,"context_line":"        # TODO(sahid): Currenlty we only use the mechanism of waiting"},{"line_number":5195,"context_line":"        # neutron events during live-migration for linux-bridge."},{"line_number":5196,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5197,"context_line":"                for vif in network_info if ("},{"line_number":5198,"context_line":"                        vif.get(\u0027type\u0027) \u003d\u003d network_model.VIF_TYPE_BRIDGE)]"},{"line_number":5199,"context_line":""},{"line_number":5200,"context_line":"    def _cleanup_failed_start(self, context, instance, network_info,"},{"line_number":5201,"context_line":"                              block_device_info, guest, destroy_disks):"}],"source_content_type":"text/x-python","patch_set":16,"id":"7f96bb07_44a962dd","line":5198,"range":{"start_line":5196,"start_character":8,"end_line":5198,"end_character":74},"in_reply_to":"7f96bb07_842c4a9a","updated":"2018-01-10 16:33:13.000000000","message":"i also think it might be wise to do for vif type vhost-user\nwhen VHOST_USER_OVS_PLUG\u003dTrue.\n\nin both cases we want to wait for the vif to be added tothe backend before completing the migration so that the RARP are not lost and mac learning can happen.","commit_id":"67259a6d19af5606784703bfda1ae0301cf52300"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":5191,"context_line":"        # Neutron should send to Nova events indicating that the VIFs"},{"line_number":5192,"context_line":"        # are well plugged on destination host."},{"line_number":5193,"context_line":""},{"line_number":5194,"context_line":"        # TODO(sahid): Currenlty we only use the mechanism of waiting"},{"line_number":5195,"context_line":"        # neutron events during live-migration for linux-bridge."},{"line_number":5196,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5197,"context_line":"                for vif in network_info if ("}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_02f15e95","line":5194,"range":{"start_line":5194,"start_character":23,"end_line":5194,"end_character":32},"updated":"2018-01-31 14:15:14.000000000","message":"\"currently\"","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":5191,"context_line":"        # Neutron should send to Nova events indicating that the VIFs"},{"line_number":5192,"context_line":"        # are well plugged on destination host."},{"line_number":5193,"context_line":""},{"line_number":5194,"context_line":"        # TODO(sahid): Currenlty we only use the mechanism of waiting"},{"line_number":5195,"context_line":"        # neutron events during live-migration for linux-bridge."},{"line_number":5196,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5197,"context_line":"                for vif in network_info if ("}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_c22cd603","line":5194,"range":{"start_line":5194,"start_character":62,"end_line":5194,"end_character":69},"updated":"2018-01-31 14:15:14.000000000","message":"\"waiting for\"","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c16cfe15e5e2c63bf151163d1b795c6db04b0376","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_9eb942cd","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"updated":"2018-01-31 18:49:03.000000000","message":"Isn\u0027t this going to override the limit you set before you kicked off this async thread? Makes me wonder if this has even been tested to actually address the concern. Perhaps if you have tested it manually, you just won the race to get this set in time? What did you do to set up the scenario?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"bab09f26ac08593fb457fde3c060b999d43e2ee5","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_a0ab201b","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_20b630fc","updated":"2018-02-07 16:11:34.000000000","message":"Yeah :) Ok cool no worries I will provide new version based on your suggestions.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"941981adf7429f0f68e6885efd60a0b2aa9e7692","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_dbdc1d76","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_3acf3fb1","updated":"2018-02-07 16:56:31.000000000","message":"\u003e \u003e Given the above, how about we _reverse_ the \u0027bandwidth\u0027 setting\n \u003e \u003e order?  E.g.\n \u003e \n \u003e We don\u0027t need to do that I think. Just set it to the speed limit\n \u003e first, don\u0027t pass the bandwidth parameter, and then unset the speed\n \u003e limit after.\n\nReasonable. Besides the unsetting part, I said the same in the pseudo code -- after first setting the bandwidth via the CONF value, run guest.migrate(...) without the \u0027bandwidth\u0027 parameter. :-)\n\n\n \u003e Note that this still seems *really* nasty to have to do this across\n \u003e the board, as we end up with a very small speed limit briefly,\n \u003e followed by a lifting of that limit, for everyone regardless of\n \u003e whether we\u0027re going to wait for the event or not (based on the VIF\n \u003e type). Maybe we could decide on the initial limit to set based on\n \u003e the presence of any VIF_BRIDGE VIFs at least.\n\nMaybe.  I\u0027ll defer to those who know more about VIF plugging and the relevant Neutron interactions here.\n\n---\n\nFWIW, it\u0027d also be clearer if someone answered the two questions from Dave Gilbert (from QEMU) I wrote further below in a long comment.  As he said they are willing to  add a new QEMU tunable (which libvirt will expose) if Nova can clearly define a need -- for future.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"558caab81632b99baaea12e4586f12a625ebbf97","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_3acf3fb1","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_4944cf1b","updated":"2018-02-07 14:51:51.000000000","message":"\u003e Given the above, how about we _reverse_ the \u0027bandwidth\u0027 setting\n \u003e order?  E.g.\n\nWe don\u0027t need to do that I think. Just set it to the speed limit first, don\u0027t pass the bandwidth parameter, and then unset the speed limit after.\n\nNote that this still seems *really* nasty to have to do this across the board, as we end up with a very small speed limit briefly, followed by a lifting of that limit, for everyone regardless of whether we\u0027re going to wait for the event or not (based on the VIF type). Maybe we could decide on the initial limit to set based on the presence of any VIF_BRIDGE VIFs at least.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"558caab81632b99baaea12e4586f12a625ebbf97","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_da4adb25","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_4f0ccf3a","updated":"2018-02-07 14:51:51.000000000","message":"I\u0027m not sure why that is confusing. The ternary operator is being used to give preference to resource (the migrateToURI2 value) if set, else fall back to the default we set in priv. Regardless of what the default was set to, this would still behave the same.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"33c7226a7ccfafc1b9d80f34c6da169839a682b5","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_4944cf1b","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_541d490d","updated":"2018-02-07 13:13:30.000000000","message":"[...]\n\n \u003e So out of curiosity, I checked with libvirt upstream:\n \u003e \n \u003e Will the \u0027bandwidth\u0027 parameter of libvirt API migrateToURI2() be\n \u003e ignored if it was previously set by the API migrateSetMaxSpeed()?\n \u003e \n \u003e \"No. If specified, the bandwidth is taken from migrateToURI2()\n \u003e because it\u0027s more specific. However, if not specified the bandwidth\n \u003e is taken from previous call to migrateSetMaxSpeed().\n \u003e \n \u003e \"As a special case, you can call migrateToURI2() with bandwidth B1\n \u003e and then call migrateSetMaxSpeed() to change the bandwidth to B2\n \u003e (e.g. to throttle it down, or up).\"\n\nGiven the above, how about we _reverse_ the \u0027bandwidth\u0027 setting order?  E.g.\n\n    guest.migrate_configure_max_speed(CONF...)\n    [...]\n    # *Without* the \u0027bandwidth\u0027 parameter\n    guest.migrate(...)","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fa8d765882fd6f828483bef7b0db182a11d03e9b","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_20b630fc","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_b5c0402c","updated":"2018-02-07 15:57:00.000000000","message":"Oh I see, your point is that if the CONF value is zero, then passing that in the bandwidth\u003d parameter causes your previous speed limit to be used. But only if the CONF value is the default zero, otherwise the speed limit will be ignored. Fair point, but still broken :)","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"91cbbb8e43d68c4a133876a581f88e6482bec5d4","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_b5c0402c","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_da4adb25","updated":"2018-02-07 15:36:29.000000000","message":"\u003e I\u0027m not sure why that is confusing. The ternary operator is being used to give preference to resource (the migrateToURI2 value) if set, else fall back to the default we set in priv. Regardless of what the default was set to, this would still behave the same.\n\nSorry Dan but that does not look right at all. If resource is 0 so priv-\u003emigMaxBandwidth is going to be used.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"6b97df87d2888cb42c5dd312e89797705611845b","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_541d490d","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_ef3a94e5","updated":"2018-02-07 10:10:46.000000000","message":"\u003e \u003e Actually no \"guest.migrate_configure_max_speed(1)\" is setting the\n \u003e \u003e global and maximum bandwidth that can be specified by this\n \u003e \u003e parameter.\n \u003e \n \u003e I don\u0027t understand this. In the guest.migrate() call, you\u0027re\n \u003e passing bandwidth\u003d(value from conf). That is clearly setting the\n \u003e limit for _this_ guest to the value in the config. However, this\n \u003e definitely happens after you set it to 1 on L6853. This code is\n \u003e executed in a thread you spawn on L6869. Unless there is some weird\n \u003e behavior to ignore this parameter, this happens _after_ the speed\n \u003e limit is set below, and thus I would imagine this resets that speed\n \u003e limit.\n \u003e \n \u003e Can you point to some libvirt code or docs that say that the\n \u003e bandwidth\u003d parameter to the migrate call will be ignored if it was\n \u003e previously set by guest.migrate_configure_max_speed()?\n\nSo out of curiosity, I checked with libvirt upstream:\n\n  Will the \u0027bandwidth\u0027 parameter of libvirt API migrateToURI2() be\n  ignored if it was previously set by the API migrateSetMaxSpeed()?\n\n    \"No. If specified, the bandwidth is taken from migrateToURI2()\n    because it\u0027s more specific. However, if not specified the bandwidth\n    is taken from previous call to migrateSetMaxSpeed().\n\n    \"As a special case, you can call migrateToURI2() with bandwidth B1\n    and then call migrateSetMaxSpeed() to change the bandwidth to B2\n    (e.g. to throttle it down, or up).\"\n\n---\n\nPS: Nova\u0027s: \n    - guest.migrate() \u003d\u003d libvirt\u0027s migrateToURI2()\n    - guest.migrate_configure_max_speed() \u003d\u003d libvirt\u0027s migrateSetMaxSpeed()","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"e195f1d50afa2c7537c6941a278fc2557027c432","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_4f0ccf3a","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"3fa0c359_ef3a94e5","updated":"2018-02-07 14:23:24.000000000","message":"\u003e Can you point to some libvirt code or docs that say that the bandwidth\u003d parameter to the migrate call will be ignored if it was previously set by guest.migrate_configure_max_speed()?\n\nOk So I think I understand what happened...\n\nBellow you can see the docstring from libvirt which confused me, I thought they were talking about the bandwidth parameter of MigrateToURI*\n\n     |  migrateSetMaxSpeed(self, bandwidth, flags\u003d0)\n     |      The maximum bandwidth (in MiB/s) that will be used to do migration\n     |      can be specified with the bandwidth parameter. Not all hypervisors\n     |      will support a bandwidth cap\n\n\nNow in the libvirt source you can see that [0]:\n\n  unsigned long migrate_speed \u003d resource ? resource : priv-\u003emigMaxBandwidth;\n\nFor information; \u0027resource\u0027 is the bandwidth parameter passed to MigrateToURI* and \u0027priv-\u003emigMaxBandwidth\u0027 is set when calling \u0027migrateSetMaxSpeed()\u0027.\n\nNova has its \u0027CONF.libvirt.live_migration_bandwidth\u0027 defaulted to \u00270\u0027 so basically that is why the migrate_speed was always using the value I have set using \u0027migrateSetMaxSpeed()\u0027\n\n[0] https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_migration.c#L3687","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"cbe4bf5850e65f261549507bf8ec8a4b7865000b","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_d69d5cbc","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"5f93b717_9eb942cd","updated":"2018-02-01 13:44:53.000000000","message":"Actually no \"guest.migrate_configure_max_speed(1)\" is setting the global and maximum bandwidth that can be specified by this parameter.\n\nAbout your concerns. I effectively tested the patch locally *and* it has been tested/ACKed by one of the Red Hat OpenStack customer (not the lasted versions).","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dd810f603361e75b8ea8a8424fecd54785bf51cc","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_ef3a94e5","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"5f93b717_d69d5cbc","updated":"2018-02-06 20:36:33.000000000","message":"\u003e Actually no \"guest.migrate_configure_max_speed(1)\" is setting the\n \u003e global and maximum bandwidth that can be specified by this\n \u003e parameter.\n\nI don\u0027t understand this. In the guest.migrate() call, you\u0027re passing bandwidth\u003d(value from conf). That is clearly setting the limit for _this_ guest to the value in the config. However, this definitely happens after you set it to 1 on L6853. This code is executed in a thread you spawn on L6869. Unless there is some weird behavior to ignore this parameter, this happens _after_ the speed limit is set below, and thus I would imagine this resets that speed limit.\n\nCan you point to some libvirt code or docs that say that the bandwidth\u003d parameter to the migrate call will be ignored if it was previously set by guest.migrate_configure_max_speed()?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"069484cf6f5bf05f81ef9cb4f7aef2e578c15a50","unresolved":false,"context_lines":[{"line_number":6500,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6501,"context_line":"                          params\u003dparams,"},{"line_number":6502,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6503,"context_line":"                          bandwidth\u003dCONF.libvirt.live_migration_bandwidth)"},{"line_number":6504,"context_line":""},{"line_number":6505,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6506,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_f940220a","line":6503,"range":{"start_line":6503,"start_character":36,"end_line":6503,"end_character":73},"in_reply_to":"5f93b717_d69d5cbc","updated":"2018-02-06 18:28:10.000000000","message":"the max speed 1MiB/s  argument is jsut like a sleep however\nhowever for a 1 gig vm at this rate it would take around 20Min to copy all the memory so for anything over a gig you will likely hit the live migration timeout first. For really small vms technically we can still race on the interface creation but its rare. \n\neven with a 64mb nano image we have over a minute not counting syncing any dirty pages, for neutron to finish wiring up the networks.\n\nit would be nicer to have a solution that is always guaranteed to work but even with a race it much less likely to be noticed then the race we have today were the RARP packets from qemu are often lost as the nic is not wired up.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c16cfe15e5e2c63bf151163d1b795c6db04b0376","unresolved":false,"context_lines":[{"line_number":6844,"context_line":"                context, instance, guest)"},{"line_number":6845,"context_line":""},{"line_number":6846,"context_line":"        if utils.is_neutron():"},{"line_number":6847,"context_line":"            # Before to continue process of live migration we have to"},{"line_number":6848,"context_line":"            # ensure the VIFs on destination node are ready."},{"line_number":6849,"context_line":"            LOG.debug(\"Slow the migration process until Nova \""},{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_7ee9d6b4","line":6847,"range":{"start_line":6847,"start_character":21,"end_line":6847,"end_character":23},"updated":"2018-01-31 18:49:03.000000000","message":"\"we\"","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5a0c614ffd3bb493d8277853532869cfe7e9d2ac","unresolved":false,"context_lines":[{"line_number":6844,"context_line":"                context, instance, guest)"},{"line_number":6845,"context_line":""},{"line_number":6846,"context_line":"        if utils.is_neutron():"},{"line_number":6847,"context_line":"            # Before to continue process of live migration we have to"},{"line_number":6848,"context_line":"            # ensure the VIFs on destination node are ready."},{"line_number":6849,"context_line":"            LOG.debug(\"Slow the migration process until Nova \""},{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_cc27a912","line":6847,"range":{"start_line":6847,"start_character":21,"end_line":6847,"end_character":23},"in_reply_to":"5f93b717_7ee9d6b4","updated":"2018-02-06 18:56:01.000000000","message":"s/\"Before to continue process of live migration\"/\"Before we \"let migration to proceed\"","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_426e862f","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"updated":"2018-01-31 14:15:14.000000000","message":"What is the logic behind this magic number?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5a0c614ffd3bb493d8277853532869cfe7e9d2ac","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_d98526af","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"in_reply_to":"3fa0c359_a1e34633","updated":"2018-02-06 18:56:01.000000000","message":"I agree with Dan here to make it a constant, even if it\u0027s used in just one place.\n\n[Slightly long read, bear with me.]\n  \nSo this change is proposing to call Nova\u0027s guest.migrate_configure_max_speed(), which is a wrapper around libvirt\u0027s migrateSetMaxSpeed() API, to slow down migration by limiting the network bandwidth to 1MiB/s.\n\nThis bandwidth-limiting is a nasty hack.  But this nastiness is probably the immediate practical solution.  At least the upside with this hack is that the guest CPUs continue to run normally while VIF plugging takes place on the destination.\n\nHowever, we should loudly and clearly document this design hack in the code.\n\n    * * *\n\nSome discussion notes with a couple libvirt and QEMU maintainers on IRC (thanks: Dan Berrangé and Dave Gilbert).\n\nA couple of questions / comments that Dave (from QEMU) raised:\n\n(1) If Nova needs to pause the migration, why can\u0027t it \n    do whatever setup it needs *before* the start \n    of migration?\n\n(2) It is OK if the pause has to be sometime later \n    during the migration, but Nova should clearly \n    *define* and document when exactly it is.\n\nIs the answer to question (1) that some Neutron network backends having work to do that is not synchronous with the initial TAP device setup.\nThis Neutron commit seems to provide some context:\nhttp://git.openstack.org/cgit/openstack/neutron/commit/?h\u003dmaster\u0026id\u003db7c303e\n(\"Notify nova with network-vif-plugged in case of live migration\")\n\n    * * *\n\nDanPB says that what Nova really needs is a way to stop the migration starting in the first place.  And suggests that a less hacky way to do that might be to use the libvirt \u0027hooks\u0027 feature.  The hook could simply sleep until plugging is complete.\n\nBut the trouble is this \u0027hooks\u0027 mechanism isn\u0027t exposed (and no plans for it as of now) via the libvirt API and needs the admin to install the hook on the host.  That means: (a) either Nova has to ship this hook; or (b) installer tools like TripleO have to install it.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"c972b7545a11e1552a2a846c3c53479d1a36d40d","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_e59b1c15","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"in_reply_to":"5f93b717_426e862f","updated":"2018-01-31 16:33:23.000000000","message":"As indicated the point is to slow the migration until we receive the events from Neutron and this value is the minimum we can set.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6fe5c2cf9dccca173056d7d60732f3733ff9feae","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_a1e34633","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"in_reply_to":"5f93b717_735d7a45","updated":"2018-02-06 15:53:54.000000000","message":"You don\u0027t have a comment explaining this enough which is why multiple people have asked about it. A constant gives a symbolic meaning to it, which I think is useful. I also think you need much better content in your comment explaining why we\u0027re doing this and why this is the only way (as opposed to some sort of pause on the migration process).","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"cbe4bf5850e65f261549507bf8ec8a4b7865000b","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_735d7a45","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"in_reply_to":"5f93b717_ded7caed","updated":"2018-02-01 13:44:53.000000000","message":"Oh so it\u0027s my mistake, in you comment you were talking about the \"logic\". And there is a comment explaining what is the purpose of that value.\n\nIt\u0027s used in on-place. Not sure it makes sense to convert a constant \u00271\u0027 in a variable. I preferred to add a comment.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c16cfe15e5e2c63bf151163d1b795c6db04b0376","unresolved":false,"context_lines":[{"line_number":6850,"context_line":"                      \"receives network events indicating everything is \""},{"line_number":6851,"context_line":"                      \"setup. (default: %d)\","},{"line_number":6852,"context_line":"                      CONF.libvirt.live_migration_bandwidth)"},{"line_number":6853,"context_line":"            guest.migrate_configure_max_speed(1)  # 1 MiB/s"},{"line_number":6854,"context_line":""},{"line_number":6855,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_ded7caed","line":6853,"range":{"start_line":6853,"start_character":50,"end_line":6853,"end_character":59},"in_reply_to":"5f93b717_e59b1c15","updated":"2018-01-31 18:49:03.000000000","message":"As indicated where? Looking at the previous comments, it was already suggested that we use a constant for this with a comment explaining that it\u0027s the minimum allowed. Why didn\u0027t you make that change?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":6856,"context_line":"            # devices on destination node. They are going to be created by"},{"line_number":6857,"context_line":"            # libvirt at the very beginning of the live-migration"},{"line_number":6858,"context_line":"            # process. Then receiving the events from Neutron will ensure"},{"line_number":6859,"context_line":"            # that everything is configured correclty."},{"line_number":6860,"context_line":"            events \u003d self._get_neutron_events_for_live_migration("},{"line_number":6861,"context_line":"                instance.get_network_info())"},{"line_number":6862,"context_line":"        else:"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_c215b69d","line":6859,"range":{"start_line":6859,"start_character":44,"end_line":6859,"end_character":53},"updated":"2018-01-31 14:15:14.000000000","message":"\"correctly\"","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":6865,"context_line":"            events \u003d []"},{"line_number":6866,"context_line":"        try:"},{"line_number":6867,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6868,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6869,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6870,"context_line":"                                       context, instance, dest,"},{"line_number":6871,"context_line":"                                       block_migration,"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_62262218","line":6868,"updated":"2018-01-31 14:15:14.000000000","message":"This can also raise an exception if the event is received, but not completed. You didn\u0027t provide an error_callback to handle that, which means you get a NovaException here that you\u0027re not catching.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"c972b7545a11e1552a2a846c3c53479d1a36d40d","unresolved":false,"context_lines":[{"line_number":6865,"context_line":"            events \u003d []"},{"line_number":6866,"context_line":"        try:"},{"line_number":6867,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":6868,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout):"},{"line_number":6869,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":6870,"context_line":"                                       context, instance, dest,"},{"line_number":6871,"context_line":"                                       block_migration,"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_28fd59b0","line":6868,"in_reply_to":"5f93b717_62262218","updated":"2018-01-31 16:33:23.000000000","message":"Yes seems reasonable to catch this.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"72ca6e105a3592b59237d71f23d4a05676021cec","unresolved":false,"context_lines":[{"line_number":6874,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":6875,"context_line":"            LOG.warning(\u0027Timeout waiting for VIFs plugging events, \u0027"},{"line_number":6876,"context_line":"                        \u0027continuing anyway but network could have \u0027"},{"line_number":6877,"context_line":"                        \u0027connectivity issues\u0027, instance\u003dinstance)"},{"line_number":6878,"context_line":"        else:"},{"line_number":6879,"context_line":"            if utils.is_neutron():"},{"line_number":6880,"context_line":"                LOG.debug(\u0027VIFs events received, continuing migration, \u0027"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_021f1eb7","line":6877,"updated":"2018-01-31 14:15:14.000000000","message":"Why? If we\u0027re just going to ignore the events why are we waiting for them?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"c972b7545a11e1552a2a846c3c53479d1a36d40d","unresolved":false,"context_lines":[{"line_number":6874,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":6875,"context_line":"            LOG.warning(\u0027Timeout waiting for VIFs plugging events, \u0027"},{"line_number":6876,"context_line":"                        \u0027continuing anyway but network could have \u0027"},{"line_number":6877,"context_line":"                        \u0027connectivity issues\u0027, instance\u003dinstance)"},{"line_number":6878,"context_line":"        else:"},{"line_number":6879,"context_line":"            if utils.is_neutron():"},{"line_number":6880,"context_line":"                LOG.debug(\u0027VIFs events received, continuing migration, \u0027"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_08009daa","line":6877,"in_reply_to":"5f93b717_021f1eb7","updated":"2018-01-31 16:33:23.000000000","message":"As for you previous comment asking me to catch an unexpected error from Neutron. Here we are trying to catch timeout issue.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c16cfe15e5e2c63bf151163d1b795c6db04b0376","unresolved":false,"context_lines":[{"line_number":6874,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":6875,"context_line":"            LOG.warning(\u0027Timeout waiting for VIFs plugging events, \u0027"},{"line_number":6876,"context_line":"                        \u0027continuing anyway but network could have \u0027"},{"line_number":6877,"context_line":"                        \u0027connectivity issues\u0027, instance\u003dinstance)"},{"line_number":6878,"context_line":"        else:"},{"line_number":6879,"context_line":"            if utils.is_neutron():"},{"line_number":6880,"context_line":"                LOG.debug(\u0027VIFs events received, continuing migration, \u0027"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_5efdfa6b","line":6877,"in_reply_to":"5f93b717_08009daa","updated":"2018-01-31 18:49:03.000000000","message":"The question is about why you\u0027re just falling through. I understand that \"except Timeout\" means you\u0027re catching the timeout.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"cbe4bf5850e65f261549507bf8ec8a4b7865000b","unresolved":false,"context_lines":[{"line_number":6874,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":6875,"context_line":"            LOG.warning(\u0027Timeout waiting for VIFs plugging events, \u0027"},{"line_number":6876,"context_line":"                        \u0027continuing anyway but network could have \u0027"},{"line_number":6877,"context_line":"                        \u0027connectivity issues\u0027, instance\u003dinstance)"},{"line_number":6878,"context_line":"        else:"},{"line_number":6879,"context_line":"            if utils.is_neutron():"},{"line_number":6880,"context_line":"                LOG.debug(\u0027VIFs events received, continuing migration, \u0027"}],"source_content_type":"text/x-python","patch_set":18,"id":"5f93b717_b33c62e1","line":6877,"in_reply_to":"5f93b717_5efdfa6b","updated":"2018-02-01 13:44:53.000000000","message":"You seem to prefer canceling the migration, right? My point was that I considered not receiving the events does not necessary means the network is not setup on destination, they might have been lost \"somewhere\" or network take for some reasons more time to setup... it\u0027s a corner-case.\n\nMy point is we should not cancel the migration but do you still prefer we cancel it?","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6fe5c2cf9dccca173056d7d60732f3733ff9feae","unresolved":false,"context_lines":[{"line_number":6874,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":6875,"context_line":"            LOG.warning(\u0027Timeout waiting for VIFs plugging events, \u0027"},{"line_number":6876,"context_line":"                        \u0027continuing anyway but network could have \u0027"},{"line_number":6877,"context_line":"                        \u0027connectivity issues\u0027, instance\u003dinstance)"},{"line_number":6878,"context_line":"        else:"},{"line_number":6879,"context_line":"            if utils.is_neutron():"},{"line_number":6880,"context_line":"                LOG.debug(\u0027VIFs events received, continuing migration, \u0027"}],"source_content_type":"text/x-python","patch_set":18,"id":"3fa0c359_61ee9e23","line":6877,"in_reply_to":"5f93b717_b33c62e1","updated":"2018-02-06 15:53:54.000000000","message":"Yes, we should cancel it IMHO.","commit_id":"b6093bc6c7971be8e2057743827e684f95fc49c1"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5bc12295ab4f5ea8c6b91566b30632d5dea5d209","unresolved":false,"context_lines":[{"line_number":323,"context_line":""},{"line_number":324,"context_line":"VGPU_RESOURCE_SEMAPHORE \u003d \"vgpu_resources\""},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"MIN_MIGRATION_SPEED_BW \u003d 1  # 1 MiB/s"},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"class LibvirtDriver(driver.ComputeDriver):"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_568265ca","line":326,"updated":"2018-03-07 12:55:55.000000000","message":"Thanks for adding the constant.","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5bc12295ab4f5ea8c6b91566b30632d5dea5d209","unresolved":false,"context_lines":[{"line_number":5403,"context_line":"            raise exception.VirtualInterfaceCreateException()"},{"line_number":5404,"context_line":""},{"line_number":5405,"context_line":"    def _neutron_failed_live_migration_callback(self, event_name, instance):"},{"line_number":5406,"context_line":"        msg \u003d (\u0027Neutron Reported failure on event during live-migration \u0027"},{"line_number":5407,"context_line":"               \u0027%(event)s for instance %(uuid)s\u0027 %"},{"line_number":5408,"context_line":"               {\u0027event\u0027: event_name, \u0027uuid\u0027: instance.uuid})"},{"line_number":5409,"context_line":"        raise exception.MigrationError(reason\u003dmsg)"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_363b3139","line":5406,"range":{"start_line":5406,"start_character":24,"end_line":5406,"end_character":32},"updated":"2018-03-07 12:55:55.000000000","message":"Nit, lower case \u0027r\u0027 --  s/Reported/reported/","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5bc12295ab4f5ea8c6b91566b30632d5dea5d209","unresolved":false,"context_lines":[{"line_number":5404,"context_line":""},{"line_number":5405,"context_line":"    def _neutron_failed_live_migration_callback(self, event_name, instance):"},{"line_number":5406,"context_line":"        msg \u003d (\u0027Neutron Reported failure on event during live-migration \u0027"},{"line_number":5407,"context_line":"               \u0027%(event)s for instance %(uuid)s\u0027 %"},{"line_number":5408,"context_line":"               {\u0027event\u0027: event_name, \u0027uuid\u0027: instance.uuid})"},{"line_number":5409,"context_line":"        raise exception.MigrationError(reason\u003dmsg)"},{"line_number":5410,"context_line":""}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_16270d15","line":5407,"updated":"2018-03-07 12:55:55.000000000","message":"If you have to re-spin, maybe reword it as: \n\n  \u0027Neutron reported failure during live migration \u0027 \n  \u0027with %(events)s for instance %(uuid)s\u0027","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5bc12295ab4f5ea8c6b91566b30632d5dea5d209","unresolved":false,"context_lines":[{"line_number":5429,"context_line":"                for vif in network_info if eventable(vif)]"},{"line_number":5430,"context_line":""},{"line_number":5431,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5432,"context_line":"        # Neutron should send to Nova events indicating that the VIFs"},{"line_number":5433,"context_line":"        # are well plugged on destination host."},{"line_number":5434,"context_line":""},{"line_number":5435,"context_line":"        # TODO(sahid): Currently we only use the mechanism of waiting"},{"line_number":5436,"context_line":"        # for neutron events during live-migration for linux-bridge."}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_565b4586","line":5433,"range":{"start_line":5432,"start_character":10,"end_line":5433,"end_character":47},"updated":"2018-03-07 12:55:55.000000000","message":"Phrasing nit, does this read any better:\n\n  \"Neutron should send events to Nova indication that \n  the VIFs are successfully plugged on destination host.\"","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"184aac6406ceecc20bdb3221f3ee6ae8c15b2e8d","unresolved":false,"context_lines":[{"line_number":6907,"context_line":"            if CONF.serial_console.enabled:"},{"line_number":6908,"context_line":"                serial_ports \u003d list(self._get_serial_ports_from_guest(guest))"},{"line_number":6909,"context_line":""},{"line_number":6910,"context_line":"            # We start migration with the minimun bandwidth"},{"line_number":6911,"context_line":"            # speed. Depending of the VIF type (see:"},{"line_number":6912,"context_line":"            # _get_neutron_events_for_live_migration) We will wait for"},{"line_number":6913,"context_line":"            # Neutron to receive events that confirm network is setup"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_9b64a6bb","line":6910,"range":{"start_line":6910,"start_character":42,"end_line":6910,"end_character":49},"updated":"2018-03-07 10:23:37.000000000","message":"minimum","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"184aac6406ceecc20bdb3221f3ee6ae8c15b2e8d","unresolved":false,"context_lines":[{"line_number":6908,"context_line":"                serial_ports \u003d list(self._get_serial_ports_from_guest(guest))"},{"line_number":6909,"context_line":""},{"line_number":6910,"context_line":"            # We start migration with the minimun bandwidth"},{"line_number":6911,"context_line":"            # speed. Depending of the VIF type (see:"},{"line_number":6912,"context_line":"            # _get_neutron_events_for_live_migration) We will wait for"},{"line_number":6913,"context_line":"            # Neutron to receive events that confirm network is setup"},{"line_number":6914,"context_line":"            # or directly configure QEMU to use the maximun BW"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_fb72827c","line":6911,"range":{"start_line":6911,"start_character":31,"end_line":6911,"end_character":33},"updated":"2018-03-07 10:23:37.000000000","message":"on","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"5bc12295ab4f5ea8c6b91566b30632d5dea5d209","unresolved":false,"context_lines":[{"line_number":6918,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6919,"context_line":"                          params\u003dparams,"},{"line_number":6920,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6921,"context_line":"                          bandwidth\u003dMIN_MIGRATION_SPEED_BW)"},{"line_number":6922,"context_line":""},{"line_number":6923,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6924,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_4c45f26f","line":6921,"range":{"start_line":6921,"start_character":26,"end_line":6921,"end_character":59},"updated":"2018-03-07 12:55:55.000000000","message":"Can you consider adding a TODO iteam to the effect of the following:\n\nTODD: Limiting bandwidth using migrateSetMaxSpeed() to 1 MiB/ is a\n      hack, but it is the immediate practical solution.  The upside with\n      this hack is that the guest CPUs continue to run normally while\n      VIF plugging takes place on the destination.\n\n      Long term: Nova needs to figure out a way to stop the migration\n      starting in the first place.  I.e. figure out a way all the \n      Nova-Neutron network related actions to be be done before the QEMU\n      migration is started.","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"f1cb243e49dc97a58615f5338339a8222a93c9f0","unresolved":false,"context_lines":[{"line_number":6918,"context_line":"                          flags\u003dmigration_flags,"},{"line_number":6919,"context_line":"                          params\u003dparams,"},{"line_number":6920,"context_line":"                          domain_xml\u003dnew_xml_str,"},{"line_number":6921,"context_line":"                          bandwidth\u003dMIN_MIGRATION_SPEED_BW)"},{"line_number":6922,"context_line":""},{"line_number":6923,"context_line":"            for hostname, port in serial_ports:"},{"line_number":6924,"context_line":"                serial_console.release_port(host\u003dhostname, port\u003dport)"}],"source_content_type":"text/x-python","patch_set":19,"id":"df7087c5_446374dd","line":6921,"range":{"start_line":6921,"start_character":26,"end_line":6921,"end_character":59},"in_reply_to":"df7087c5_4c45f26f","updated":"2018-03-08 08:21:36.000000000","message":"There is a comment line 6910 which indicates why we limit the bandwidh.\n\nYour \"long term\" can\u0027t work, it\u0027s not Nova how can deal with stopping the migration. Basically we would an API of 3 steps.\n\n- Libvirt to create TAP devices on destination\n- Libvirt to prepare the -incoming QEMU process on destination\n- Libvirt to start the migration from source","commit_id":"fc3a2533f9d85a16fd6aa36ef528b35767f5d922"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"26f12537ef375cb065905a124c776c095209ce0d","unresolved":false,"context_lines":[{"line_number":5526,"context_line":"                for vif in network_info if eventable(vif)]"},{"line_number":5527,"context_line":""},{"line_number":5528,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5529,"context_line":"        # Neutron should send events to Nova indication that the VIFs"},{"line_number":5530,"context_line":"        # are successfully plugged on destination host."},{"line_number":5531,"context_line":""},{"line_number":5532,"context_line":"        # TODO(sahid): Currently we only use the mechanism of waiting"}],"source_content_type":"text/x-python","patch_set":22,"id":"df7087c5_fb9ec761","line":5529,"updated":"2018-03-13 12:33:34.000000000","message":"Darn, I meant: s/indication/indicating/\n\n(Only fix it if you have to re-spin.)","commit_id":"4784232526f7dfc04f3a034a116ddad26d250dce"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":5538,"context_line":"        # for neutron events during live-migration for linux-bridge."},{"line_number":5539,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5540,"context_line":"                for vif in network_info if ("},{"line_number":5541,"context_line":"                        vif.get(\u0027type\u0027) \u003d\u003d network_model.VIF_TYPE_BRIDGE)]"},{"line_number":5542,"context_line":""},{"line_number":5543,"context_line":"    def _cleanup_failed_start(self, context, instance, network_info,"},{"line_number":5544,"context_line":"                              block_device_info, guest, destroy_disks):"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_288a2069","line":5541,"updated":"2018-03-15 14:08:02.000000000","message":"There is no test for this method, and since you\u0027re not generating and sending events in tests (that I can see), there\u0027s no verification that this is doing what you expect.","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"d5394a4076581eeab460358c81177461f936534b","unresolved":false,"context_lines":[{"line_number":5538,"context_line":"        # for neutron events during live-migration for linux-bridge."},{"line_number":5539,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5540,"context_line":"                for vif in network_info if ("},{"line_number":5541,"context_line":"                        vif.get(\u0027type\u0027) \u003d\u003d network_model.VIF_TYPE_BRIDGE)]"},{"line_number":5542,"context_line":""},{"line_number":5543,"context_line":"    def _cleanup_failed_start(self, context, instance, network_info,"},{"line_number":5544,"context_line":"                              block_device_info, guest, destroy_disks):"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_77d31505","line":5541,"in_reply_to":"df7087c5_288a2069","updated":"2018-03-15 17:00:49.000000000","message":"You are right I did not add one.","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":7364,"context_line":"            # libvirt at the very beginning of the live-migration"},{"line_number":7365,"context_line":"            # process. Then receiving the events from Neutron will ensure"},{"line_number":7366,"context_line":"            # that everything is configured correctly."},{"line_number":7367,"context_line":"            events \u003d self._get_neutron_events_for_live_migration("},{"line_number":7368,"context_line":"                instance.get_network_info())"},{"line_number":7369,"context_line":"        else:"},{"line_number":7370,"context_line":"            # TODO(sahid): This condition should be removed when"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_e842e80e","line":7367,"updated":"2018-03-15 14:08:02.000000000","message":"In the create domain workflow, we don\u0027t generate events if vif_plugging_timeout is zero, basically allowing the operators to disable us even waiting if they don\u0027t allow neutron to send events to nova or something. Surely we should do the same here so that we don\u0027t bypass the wait on start, but then hang on events that will never come during live migration?","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"d5394a4076581eeab460358c81177461f936534b","unresolved":false,"context_lines":[{"line_number":7364,"context_line":"            # libvirt at the very beginning of the live-migration"},{"line_number":7365,"context_line":"            # process. Then receiving the events from Neutron will ensure"},{"line_number":7366,"context_line":"            # that everything is configured correctly."},{"line_number":7367,"context_line":"            events \u003d self._get_neutron_events_for_live_migration("},{"line_number":7368,"context_line":"                instance.get_network_info())"},{"line_number":7369,"context_line":"        else:"},{"line_number":7370,"context_line":"            # TODO(sahid): This condition should be removed when"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_bc97523a","line":7367,"in_reply_to":"df7087c5_e842e80e","updated":"2018-03-15 17:00:49.000000000","message":"Yes that makes sense.","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":7375,"context_line":"            # We start migration with the minimum bandwidth"},{"line_number":7376,"context_line":"            # speed. Depending on the VIF type (see:"},{"line_number":7377,"context_line":"            # _get_neutron_events_for_live_migration) We will wait for"},{"line_number":7378,"context_line":"            # Neutron to receive events that confirm network is setup"},{"line_number":7379,"context_line":"            # or directly configure QEMU to use the maximun BW"},{"line_number":7380,"context_line":"            # allowed."},{"line_number":7381,"context_line":"            bandwidth \u003d MIN_MIGRATION_SPEED_BW"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_089e3cb8","line":7378,"range":{"start_line":7378,"start_character":25,"end_line":7378,"end_character":32},"updated":"2018-03-15 14:08:02.000000000","message":"send","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":7380,"context_line":"            # allowed."},{"line_number":7381,"context_line":"            bandwidth \u003d MIN_MIGRATION_SPEED_BW"},{"line_number":7382,"context_line":"        else:"},{"line_number":7383,"context_line":"            bandwidth \u003d CONF.libvirt.live_migration_bandwidth,"},{"line_number":7384,"context_line":""},{"line_number":7385,"context_line":"        try:"},{"line_number":7386,"context_line":"            with self.virtapi.wait_for_instance_event("}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_f4516837","line":7383,"updated":"2018-03-15 14:08:02.000000000","message":"I don\u0027t see any tests that take this path. It looks like you changed them all to be throttled initially, which I assume is because they all use linuxbridge VIFs. Maybe I missed some, but where are the tests that show that if we don\u0027t have linuxbridge VIFs, we start with full bandwidth? I would also expect to see an assertion that we don\u0027t call configure_max_speed() on any of those.\n\nI also don\u0027t really see where the neutron events are ever coming in in the tests, so I\u0027m not really sure how to verify that we\u0027re waiting for those. Can you point me to them?","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"db49ef4789e603f74f48a47711282984b8152936","unresolved":false,"context_lines":[{"line_number":7380,"context_line":"            # allowed."},{"line_number":7381,"context_line":"            bandwidth \u003d MIN_MIGRATION_SPEED_BW"},{"line_number":7382,"context_line":"        else:"},{"line_number":7383,"context_line":"            bandwidth \u003d CONF.libvirt.live_migration_bandwidth,"},{"line_number":7384,"context_line":""},{"line_number":7385,"context_line":"        try:"},{"line_number":7386,"context_line":"            with self.virtapi.wait_for_instance_event("}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_92f6f7d6","line":7383,"in_reply_to":"df7087c5_170c19a3","updated":"2018-03-15 17:22:00.000000000","message":"Since you didn\u0027t answer the second part I tracked it down:\n\nThese tests are using FakeVirtAPI() which makes the event wait a noop, which is fine, but in that case you should ensure that compute\u0027s prepare method is being called as expected on at least one of these tests. Otherwise we could remove the wait and no tests would fail.\n\nFor example, from the spawn tests:\n\nhttps://github.com/openstack/nova/blob/9038738d0134c0a1d59757ed3205d84f76416869/nova/tests/unit/virt/libvirt/test_driver.py#L15649-L15657","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"d5394a4076581eeab460358c81177461f936534b","unresolved":false,"context_lines":[{"line_number":7380,"context_line":"            # allowed."},{"line_number":7381,"context_line":"            bandwidth \u003d MIN_MIGRATION_SPEED_BW"},{"line_number":7382,"context_line":"        else:"},{"line_number":7383,"context_line":"            bandwidth \u003d CONF.libvirt.live_migration_bandwidth,"},{"line_number":7384,"context_line":""},{"line_number":7385,"context_line":"        try:"},{"line_number":7386,"context_line":"            with self.virtapi.wait_for_instance_event("}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_170c19a3","line":7383,"in_reply_to":"df7087c5_f4516837","updated":"2018-03-15 17:00:49.000000000","message":"Most of the tests are using methods from unit/tests/fake_network.py where that module is using nova-network, TYPE_BRIDGE.\n\nI added two new tests for OVS and BRIDGE/vif_plug_timeout\u003d0","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":7386,"context_line":"            with self.virtapi.wait_for_instance_event("},{"line_number":7387,"context_line":"                    instance, events, deadline\u003dCONF.vif_plugging_timeout,"},{"line_number":7388,"context_line":"                    error_callback\u003d("},{"line_number":7389,"context_line":"                        self._neutron_failed_live_migration_callback)):"},{"line_number":7390,"context_line":"                opthread \u003d utils.spawn(self._live_migration_operation,"},{"line_number":7391,"context_line":"                                       context, instance, dest,"},{"line_number":7392,"context_line":"                                       block_migration,"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_082b9c82","line":7389,"range":{"start_line":7389,"start_character":24,"end_line":7389,"end_character":68},"updated":"2018-03-15 14:08:02.000000000","message":"This is a nit, but this line breaking is hard on the eyes. I would have grabbed a reference to this above to make it cleaner, like:\n\n error_cb \u003d self._neutron_failed_live_migration_callback\n deadline \u003d CONF.vif_plugging_timeout\n with self.virtapi.wait_for_instance_event(instance, devents,\n                                           deadline\u003ddeadline,\n                                           error_callback\u003derror_cb):","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"da183fe41985d9b19ceb467cc0e5c210bcd94c13","unresolved":false,"context_lines":[{"line_number":7391,"context_line":"                                       context, instance, dest,"},{"line_number":7392,"context_line":"                                       block_migration,"},{"line_number":7393,"context_line":"                                       migrate_data, guest,"},{"line_number":7394,"context_line":"                                       device_names, bandwidth\u003dbandwidth)"},{"line_number":7395,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7396,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7397,"context_line":"                   \u0027canceling migration\u0027)"}],"source_content_type":"text/x-python","patch_set":24,"id":"df7087c5_f40ba88a","line":7394,"range":{"start_line":7394,"start_character":53,"end_line":7394,"end_character":72},"updated":"2018-03-15 14:08:02.000000000","message":"This is not a kwarg nor optional and thus shouldn\u0027t be passed as such.","commit_id":"e54bcf063ba2eb3ac22a01b0dab2e2d889e6215d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"6e2761550c01ffeaefc7fd2f57c926e1f35859df","unresolved":false,"context_lines":[{"line_number":7403,"context_line":"        else:"},{"line_number":7404,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7405,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"},{"line_number":7406,"context_line":"                          \u0027with max bandwidth configured: %d\u0027,"},{"line_number":7407,"context_line":"                          instance\u003dinstance)"},{"line_number":7408,"context_line":"                # Configure QEMU to use the maximum bandwidth allowed."},{"line_number":7409,"context_line":"                guest.migrate_configure_max_speed("}],"source_content_type":"text/x-python","patch_set":27,"id":"df7087c5_fca6ef53","line":7406,"updated":"2018-03-19 08:19:02.000000000","message":"I missed the bandwidth param.","commit_id":"98d2584685c781c546a0fc0fb7f09beecd157540"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"a35614a97a58ac88b8a1dbf4dbda7626faa387d4","unresolved":false,"context_lines":[{"line_number":7370,"context_line":"            # meaning that the operator disabled using them."},{"line_number":7371,"context_line":""},{"line_number":7372,"context_line":"            # In case of Linux Bridge, the agent is waiting for new TAPs"},{"line_number":7373,"context_line":"            # devices on destination node. They are going to be created by"},{"line_number":7374,"context_line":"            # libvirt at the very beginning of the live-migration"},{"line_number":7375,"context_line":"            # process. Then receiving the events from Neutron will ensure"},{"line_number":7376,"context_line":"            # that everything is configured correctly."}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_c9b47df5","line":7373,"updated":"2018-03-19 15:52:15.000000000","message":"s/TAPs devices/TAP devices/","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":7377,"context_line":"            events \u003d self._get_neutron_events_for_live_migration("},{"line_number":7378,"context_line":"                instance.get_network_info())"},{"line_number":7379,"context_line":"        else:"},{"line_number":7380,"context_line":"            # TODO(sahid): This condition should be removed when"},{"line_number":7381,"context_line":"            # nova-network will be erased from the tree (Rocky)."},{"line_number":7382,"context_line":"            events \u003d []"},{"line_number":7383,"context_line":""},{"line_number":7384,"context_line":"        if events:"},{"line_number":7385,"context_line":"            # We start migration with the minimum bandwidth"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_fe29f9f1","line":7382,"range":{"start_line":7380,"start_character":12,"end_line":7382,"end_character":23},"updated":"2018-03-19 15:42:14.000000000","message":"This applies to the is_neutron() check, not the vif_plugging_timeout check, which doesn\u0027t go away when nova-network does. So if you had to respin, I\u0027d re-word this as \"The is_neutron condition should be removed...\".","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac0c82e3b42dcc885896b2d42b97896b298a0295","unresolved":false,"context_lines":[{"line_number":7407,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7408,"context_line":"        else:"},{"line_number":7409,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7410,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"},{"line_number":7411,"context_line":"                          \u0027with max bandwidth configured: %d\u0027,"},{"line_number":7412,"context_line":"                          CONF.libvirt.live_migration_bandwidth,"},{"line_number":7413,"context_line":"                          instance\u003dinstance)"}],"source_content_type":"text/x-python","patch_set":28,"id":"df7087c5_bee8617c","line":7410,"updated":"2018-03-19 15:42:14.000000000","message":"Verified:\n\nhttp://logs.openstack.org/08/553608/7/check/neutron-tempest-linuxbridge/6ace55a/logs/subnode-2/screen-n-cpu.txt.gz#_Mar_18_08_40_27_265250\n\nhttp://logs.openstack.org/08/553608/7/check/neutron-tempest-linuxbridge/6ace55a/logs/screen-n-cpu.txt.gz#_Mar_18_08_42_17_287038","commit_id":"46548078e03d1c14a495b019045b539cc498616a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e13338a56964eaaf6000296cac32ab7a01a271f7","unresolved":false,"context_lines":[{"line_number":5523,"context_line":"        # anything that might be stale (cache-wise) assume it\u0027s"},{"line_number":5524,"context_line":"        # already up so we don\u0027t block on it."},{"line_number":5525,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5526,"context_line":"                for vif in network_info if vif.get(\u0027active\u0027, True) is False]"},{"line_number":5527,"context_line":""},{"line_number":5528,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5529,"context_line":"        # Neutron should send events to Nova indicating that the VIFs"}],"source_content_type":"text/x-python","patch_set":30,"id":"df7087c5_beb5bccf","line":5526,"range":{"start_line":5526,"start_character":40,"end_line":5526,"end_character":75},"updated":"2018-03-19 18:00:47.000000000","message":"Do we care about filtering out inactive ports in _get_neutron_events_for_live_migration?","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"0dd4a44a96657ac0dbc875adb6076021f2ea6e76","unresolved":false,"context_lines":[{"line_number":5523,"context_line":"        # anything that might be stale (cache-wise) assume it\u0027s"},{"line_number":5524,"context_line":"        # already up so we don\u0027t block on it."},{"line_number":5525,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5526,"context_line":"                for vif in network_info if vif.get(\u0027active\u0027, True) is False]"},{"line_number":5527,"context_line":""},{"line_number":5528,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5529,"context_line":"        # Neutron should send events to Nova indicating that the VIFs"}],"source_content_type":"text/x-python","patch_set":30,"id":"df7087c5_d8cc3763","line":5526,"range":{"start_line":5526,"start_character":40,"end_line":5526,"end_character":75},"in_reply_to":"df7087c5_5ef8207b","updated":"2018-03-20 07:56:50.000000000","message":"Sorry you asked me several time and I never replied to you.\n\nFor live-migration the ports in Neutron are already in DB. Only the \u0027host\u0027 attribute is updated to None. So when agent on destination node discover the \"new\" device, Neutron is checking whether the port already exist (by using device name). If that is the case (host\u003dNone and port is in DB) That means we are in context of live-migration and Neutron is sending the event.\n\nMy thinking is that we don\u0027t care of the \u0027active\u0027 attribute, Neutron is sending events based on host attribute and whether it\u0027s already in DB.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aa55e0534bfb7a5c494f62c0305476b731fdd44b","unresolved":false,"context_lines":[{"line_number":5523,"context_line":"        # anything that might be stale (cache-wise) assume it\u0027s"},{"line_number":5524,"context_line":"        # already up so we don\u0027t block on it."},{"line_number":5525,"context_line":"        return [(\u0027network-vif-plugged\u0027, vif[\u0027id\u0027])"},{"line_number":5526,"context_line":"                for vif in network_info if vif.get(\u0027active\u0027, True) is False]"},{"line_number":5527,"context_line":""},{"line_number":5528,"context_line":"    def _get_neutron_events_for_live_migration(self, network_info):"},{"line_number":5529,"context_line":"        # Neutron should send events to Nova indicating that the VIFs"}],"source_content_type":"text/x-python","patch_set":30,"id":"df7087c5_5ef8207b","line":5526,"range":{"start_line":5526,"start_character":40,"end_line":5526,"end_character":75},"in_reply_to":"df7087c5_beb5bccf","updated":"2018-03-19 18:02:43.000000000","message":"Nevermind, this is a different scenario where the VIFs aren\u0027t active yet. For live migration they are.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"19c41b08f9e6842207d48ffaf3b0e6a4e6eda53e","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_17fe15ae","line":7384,"updated":"2018-04-27 14:29:32.000000000","message":"There is a case here which we don\u0027t take into account. We are making the migration moving slowly but the migration is still progressing.\n\nThe default timeout is 5min, so it\u0027s possible for an instance to have been migrated before we hurt that timeout.\nThe problem is that, the instance has been migrated in the destination host and we are trying to rollback which is creating an unpredictable state.\n\nIn my first version I was doing a warning that to let operators know that Nova did not receive the events because of some reasons (slow network). But I was considering to continue the process of live-migration anyway.\n\nI wondering whether we should not purpose a patch to change it?","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f2b33931d1c6b606d1a6cdf00d2d82af83e38184","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_d792dd4b","line":7384,"in_reply_to":"9f6a8fd7_17fe15ae","updated":"2018-04-27 14:35:56.000000000","message":"This is why I say this is a complete hack :)\n\nI can\u0027t imagine that any *real* instance could migrate at 1kb/s in under five minutes. It would have to be under 300kb of memory to migrate within that window. Is this a theoretical situation or have you experienced it somewhere for real?","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"48031533ffedb3115ae28e91c0e66d6430a247b3","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_93c1d883","line":7384,"in_reply_to":"9f6a8fd7_57200db1","updated":"2018-04-27 15:03:33.000000000","message":"\u003e So like that, that part just don\u0027t work anyway, so my thinking was to log a warning and keep the process moving forward.\n\nCorrection, that does not work for really small instances and if we hurt timeout for some reason.\n\nI can be agree with you to keep the code like that actually.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39f06c197c9414ce0d07eaa419c0e35329ee7b8d","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_f974b39e","line":7384,"in_reply_to":"9f6a8fd7_93c1d883","updated":"2018-04-27 16:06:14.000000000","message":"Are they artificially blocking the notification to trigger the timeout? If that\u0027s the case, then I don\u0027t think that something we need to account for.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"4d835a5d0ae497b0028eb9cf8033d0d525cbb60b","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_57200db1","line":7384,"in_reply_to":"9f6a8fd7_d792dd4b","updated":"2018-04-27 14:54:04.000000000","message":"\u003e This is why I say this is a complete hack :)\n\nBlinds its eyes :)\n\n\u003e I can\u0027t imagine that any *real* instance could migrate at 1kb/s in under five minutes. It would have to be under 300kb of memory to migrate within that window. Is this a theoretical situation or have you experienced it somewhere for real?\n\nI\u0027m agreed it\u0027s something that should not happen under real situation. It\u0027s an internal customer how reported the issue. They basically demonstrate the fact that if Nova hurts the timeout the instance get stuck. Which it\u0027s true.\n\nSo like that, that part just don\u0027t work anyway, so my thinking was to log a warning and keep the process moving forward.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"c8e38ace9c6012fefb303b66147ab6c68652e3c2","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"5f7c97a3_64b2814b","line":7384,"in_reply_to":"9f6a8fd7_d949af8b","updated":"2018-05-15 07:55:58.000000000","message":"They are agreed this should not happen under normal conditions. But they think that if for some reasons the events are not received (agent stopped on destination node for example) and instance is running with small RAM which is something acceptable. So the instance goes in a unpredictable state where it would be better to have it well migrated so then  they could try to rescue it.\n\nI don\u0027t know why but they look to be really pushy on fixing that point.","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"70944ec5d38e81529d2c8c6a1601ca6b85038201","unresolved":false,"context_lines":[{"line_number":7381,"context_line":"        except eventlet.timeout.Timeout:"},{"line_number":7382,"context_line":"            msg \u003d (\u0027Timeout waiting for VIF plugging events, \u0027"},{"line_number":7383,"context_line":"                   \u0027canceling migration\u0027)"},{"line_number":7384,"context_line":"            raise exception.MigrationError(reason\u003dmsg)"},{"line_number":7385,"context_line":"        else:"},{"line_number":7386,"context_line":"            if utils.is_neutron() and events:"},{"line_number":7387,"context_line":"                LOG.debug(\u0027VIF events received, continuing migration \u0027"}],"source_content_type":"text/x-python","patch_set":30,"id":"9f6a8fd7_d949af8b","line":7384,"in_reply_to":"9f6a8fd7_f974b39e","updated":"2018-04-27 16:32:54.000000000","message":"I will clarify that point","commit_id":"8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4"}]}