)]}'
{"vif_plug_ovs/linux_net.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ecca142837afbe91019dd792362f313e031861b2","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"7f287b81_41b3524e","line":156,"range":{"start_line":156,"start_character":8,"end_line":156,"end_character":61},"updated":"2017-09-06 09:42:34.000000000","message":"Im not sure this makes sense.\nThe issue described in the bug describes how the RARP packets are not learned by ovs as the port is not tagged when they are sent. This change will not help resolve that problem. you are simply disabling again on the linux bridge which is not where the learning was failing.","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4468d7033747b7d52ad5b1071402cae3de5ee54e","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f2577a7_9a945546","line":156,"in_reply_to":"5f2577a7_016dac97","updated":"2017-09-11 12:59:01.000000000","message":"ah ok so the destination bridge is learning the mac of the vm on the veth pair because the souce tap has not been removed.\n\nthe fact that the destination bridge has a tap with mack xyz and can learn xyz on a different interfaces seems like a linux bridge bug to me but if this will fix that then im fine with this. \n\nmy only concern would be what happen if the destination bridge learns the vm mac from the uplink before that tap is added to the destination bridge. are we adding the veth pair to the bridge before libvirt creates the tap device and adds it to the bridge","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3f8ba298cdda92bdf4cfbc818af834c1f276fcdd","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"bf57530f_e05058d7","line":156,"in_reply_to":"5f2577a7_45196e77","updated":"2017-09-20 12:49:01.000000000","message":"That\u0027s some really good investigative work. Can we get a summary of that in the commit message, so future reviewers can better understand this change","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"a306c40980eed754c3b23ded8551146422375122","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f2577a7_45196e77","line":156,"in_reply_to":"5f2577a7_9a945546","updated":"2017-09-11 13:42:17.000000000","message":"I would say you are right it\u0027s probably a bug in Linux Bridge but I can\u0027t totally ensure that.\n\nFrom what I do understand if the destination bridge learns the VM MAC from uplink before the TAP is added, it\u0027s not a problem that because the TAP is added locally so it takes the lead, the problem can \"only\" happen when the TAP is already plugged so at this point the learning table can be rewritten.","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"bcf5b42131b1e22484334350117db0cc8b089361","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"7f287b81_c137424d","line":156,"in_reply_to":"7f287b81_41b3524e","updated":"2017-09-06 09:51:35.000000000","message":"I can remove the tag 1414559 is that can help. Here [0] is the serie which should resolve it. I do work on fixing all of these live migration problems hence why I referenced it as \"Related\"\n\n[0] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1414559","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a71ff9314f2aeddef08067fdefe2cd54bd2301b1","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"7f287b81_f6c1b430","line":156,"in_reply_to":"7f287b81_c137424d","updated":"2017-09-07 16:31:03.000000000","message":"ok but im still not sure why this is needed.\n\nthe linux bridge used in hybrid plug only has two ports.\nlinux bridge impelentes split horizon forwarding.\nas such when a mac address is not learned it floods\nto all other ports. that means that that because we only have two port regardless of if the mac adress is learned or not all lb will do is forward the packet to the other port on the bridge so really there should be no effect to the above change other then increase the memory use by the mac learning table in the linux bridge.","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"6b9e334f62b4108f1fe391ea20e2070ebfa86ca1","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027addbr\u0027, bridge)"},{"line_number":154,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setfd\u0027, bridge, 0)"},{"line_number":155,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027stp\u0027, bridge, \u0027off\u0027)"},{"line_number":156,"context_line":"        processutils.execute(\u0027brctl\u0027, \u0027setageing\u0027, bridge, 0)"},{"line_number":157,"context_line":"        syspath \u003d \u0027/sys/class/net/%s/bridge/multicast_snooping\u0027"},{"line_number":158,"context_line":"        syspath \u003d syspath % bridge"},{"line_number":159,"context_line":"        processutils.execute(\u0027tee\u0027, syspath, process_input\u003d\u00270\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f2577a7_016dac97","line":156,"in_reply_to":"7f287b81_f6c1b430","updated":"2017-09-09 15:21:25.000000000","message":"No really, nothing in relation with performance and memory consumption here.\n\nThat is the point, in pre-live-migration Nova is creating a bridge on destination node and the agent is detecting it. The agent is then processing of building that new port... During that time Nova has initiated the live-migration via libvirt API. At the very beginning libvirt is creating the TAP, plug it to the bridge, and start the domain in pause (So QEMU does not send any announcement). During that phase, we have a same MAC address for to two different device on a same L2. Now when QEMU is started, it will broadcast the RARP packets to announce itself, and the bridge on source (if not destroyed at time) can respond of them which is going to instruct the bridge on destination host to use the uplink to reach that MAC. As you image it means that we can\u0027t ping the VM until the bridge reset its mac learning table for that entry (by default 300s).\n\nBy setting the ageing to zero we make it persistent so the bridge is going to ignore these RARP since libvirt before to plug the TAP configures the MAC, and that one is going to be local to the bridge.\n\nThis issue is very tricky I was only able to see it with the plugin opflex which adds a layer to then control the agent. I would say it also adds some kind of latency which is causing that bug.","commit_id":"77a12494458fea8cd18b78d2ff248dc3e6ffb64d"}]}