)]}'
{"nova/virt/libvirt/driver.py":[{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"fb7ce1c5c8f1b6b879e1816ce69a95a10ac9cd71","unresolved":false,"context_lines":[{"line_number":5403,"context_line":"    def _get_neutron_events(self, network_info, reboot\u003dFalse):"},{"line_number":5404,"context_line":"        def eventable(vif):"},{"line_number":5405,"context_line":"            if reboot:"},{"line_number":5406,"context_line":"                # NOTE(melwitt): We won\u0027t expect events for the bridge vif"},{"line_number":5407,"context_line":"                # type during a reboot because the neutron agent might not"},{"line_number":5408,"context_line":"                # detect that we have unplugged and plugged vifs with os-vif."},{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_36001135","side":"PARENT","line":5406,"updated":"2018-03-07 11:27:51.000000000","message":"You should not change that, the whole context of the explanation is for vif type bridge.\n\nAlso the explanation is not totally right. The agent is detecting new bridge on compute node, during soft-reboot we do not destroy/re-create the bridge so the events are not sent by Neutron. BUT if we do a hard reboot they should be sent.\n\nSo I would say the fix from melwitt is not totally right.","commit_id":"5d2add74534719c5670b29152964a60e8f23b42b"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"c8ff2e3bb1e7264cdb18e1e0ab4c6688117d7305","unresolved":false,"context_lines":[{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"},{"line_number":5410,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5411,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5412,"context_line":"                return vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT"},{"line_number":5413,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5414,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5415,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_f007c61b","line":5412,"range":{"start_line":5412,"start_character":23,"end_line":5412,"end_character":77},"updated":"2018-03-09 12:01:35.000000000","message":"FWIW this was a stab in the dark, I don\u0027t know how neutron handles port re-plugs for directly attached VIFs.","commit_id":"b78cbe5fc1aea2c7dbb4994534d7b02ad178cb6e"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"fb7ce1c5c8f1b6b879e1816ce69a95a10ac9cd71","unresolved":false,"context_lines":[{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"},{"line_number":5410,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5411,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5412,"context_line":"                return vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT"},{"line_number":5413,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5414,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5415,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_914c8777","line":5412,"updated":"2018-03-07 11:27:51.000000000","message":"I think we should pass on all kind whether it\u0027s not a hard reboot. Since during soft reboot we should not unplug/replug vifs. It\u0027s all about guest OS.","commit_id":"b78cbe5fc1aea2c7dbb4994534d7b02ad178cb6e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"7b195bc14160f35e7c8ac69124f9d3b00746185e","unresolved":false,"context_lines":[{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"},{"line_number":5410,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5411,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5412,"context_line":"                return vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT"},{"line_number":5413,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5414,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5415,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_1644b2b6","line":5412,"range":{"start_line":5412,"start_character":23,"end_line":5412,"end_character":77},"in_reply_to":"df7087c5_1ba85b75","updated":"2018-03-09 13:33:56.000000000","message":"\u003e I think they are a confusion here.\n \u003e \n \u003e VIF_TYPE_BRIDGE, so the agent is checking whether new tap devices\n \u003e are created. That is done by libvirt when it creates a domain.\n \u003e Basically during soft-reboot we do not destroy/create domains, we\n \u003e do that only for hard-reboot.\n\nreboot\u003dTrue here indicates this is a hard reboot. We don\u0027t call down into this method via _create_domain_and_network for soft reboots at all. I\u0027ll create a follow up to rename the reboot arg to hard_reboot or something to make this clear.\n\nFWIW it doesn\u0027t appear that we aren\u0027t getting plugged events from all VIF_TYPE_BRIDGE VIFs, that\u0027s why this logic is here. When I changed the hard reboot behaviour in Id188d48609f3d22d14e16c7f6114291d547a8986 we saw failures in Neutron CI hard rebooting instances using linuxbridge VIFs, Mel tracked this down in Ib08afad3822f2ca95cfeea18d7f4fc4cb407b4d6 and introduced the original logic to skip VIF_TYPE_BRIDGE VIFs here.\n\n \u003e VIF_TYPE_OVS, there are two cases but basically the same story, the\n \u003e agent is looking ovsdb to see whether a veth \"qvo-xxx\" has been\n \u003e added to br-int (hybrid\u003dtrue) or a new tap directly connected to\n \u003e br-int (hybrid\u003dfalse).\n\nRight and during a hard reboot that results in a vif-plugged event being sent from Neutron to Nova, allowing us to wait for VIF_TYPE_OVS vifs.\n\n \u003e VIF_TYPE_DIRECT_PASSTHROUGHT (VNIC_TYPE_DIRECT + VNIC_TYPE_DIRECT_PHY)\n \u003e so the physical device is already connected to br-int, we pass the\n \u003e phy_func or virt_func directly to the guest so there is not events.\n\nCool, so this should be added to the original conditional and shouldn\u0027t replace the original VIF_TYPE_BRIDGE part.","commit_id":"b78cbe5fc1aea2c7dbb4994534d7b02ad178cb6e"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"c8ff2e3bb1e7264cdb18e1e0ab4c6688117d7305","unresolved":false,"context_lines":[{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"},{"line_number":5410,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5411,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5412,"context_line":"                return vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT"},{"line_number":5413,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5414,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5415,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_10a7da51","line":5412,"in_reply_to":"df7087c5_914c8777","updated":"2018-03-09 12:01:35.000000000","message":"I don\u0027t think we want to skip these VIFs during an initial instance boot, the below active conditional is enough there, I\u0027d rather keep this hard reboot logic separate from that.","commit_id":"b78cbe5fc1aea2c7dbb4994534d7b02ad178cb6e"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"b2720a30dee6566c5b3690ef62f1f975b0988532","unresolved":false,"context_lines":[{"line_number":5409,"context_line":"                # We also disregard the \u0027active\u0027 status of the vif during a"},{"line_number":5410,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5411,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5412,"context_line":"                return vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT"},{"line_number":5413,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5414,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5415,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":1,"id":"df7087c5_1ba85b75","line":5412,"range":{"start_line":5412,"start_character":23,"end_line":5412,"end_character":77},"in_reply_to":"df7087c5_f007c61b","updated":"2018-03-09 12:37:57.000000000","message":"I think they are a confusion here.\n\nVIF_TYPE_BRIDGE, so the agent is checking whether new tap devices are created. That is done by libvirt when it creates a domain. Basically during soft-reboot we do not destroy/create domains, we do that only for hard-reboot.\n\nVIF_TYPE_OVS, there are two cases but basically the same story, the agent is looking ovsdb to see whether a veth \"qvo-xxx\" has been added to br-int (hybrid\u003dtrue) or a new tap directly connected to br-int (hybrid\u003dfalse).\n\nVIT_TYPE_DIRECT_PASSTHROUGHT (VNIC_TYPE_DIRECT + VNIC_TYPE_DIRECT_PHY) so the physical device is already connected to br-int, we pass the phy_func or virt_func directly to the guest so there is not events.","commit_id":"b78cbe5fc1aea2c7dbb4994534d7b02ad178cb6e"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"fa37ac7c09e1c505a2f3354904280b8115577221","unresolved":false,"context_lines":[{"line_number":5507,"context_line":"                # reboot because the stale network_info we get from the compute"},{"line_number":5508,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5509,"context_line":"                # NOTE(lyarwood): We also don\u0027t expect events from direct vifs."},{"line_number":5510,"context_line":"                return (vif.get(\u0027type\u0027) !\u003d network_model.VIF_TYPE_BRIDGE and"},{"line_number":5511,"context_line":"                        vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT)"},{"line_number":5512,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5513,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"}],"source_content_type":"text/x-python","patch_set":3,"id":"df7087c5_15a9e3dd","line":5510,"updated":"2018-03-12 11:05:24.000000000","message":"Actually I\u0027m a bit confused. If reboot is for hard_reboot. So when we destroy/create the instance, libvirt is going to create new tap devices which are going to be seen be the agent and so the events are going to be send.\n\n\nBeside of that I\u0027m agreed for passing with VFs/PFs","commit_id":"a77a8eaa7dd5d10b8850124f1a654f13eb6cd53b"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"3bb6e5a2bd24aa1f5ff344299a46088df1c3032f","unresolved":false,"context_lines":[{"line_number":5508,"context_line":"                # manager won\u0027t show active\u003dFalse for the vifs we\u0027ve unplugged."},{"line_number":5509,"context_line":"                # NOTE(lyarwood): We also don\u0027t expect events from direct vifs."},{"line_number":5510,"context_line":"                return (vif.get(\u0027type\u0027) !\u003d network_model.VIF_TYPE_BRIDGE and"},{"line_number":5511,"context_line":"                        vif.get(\u0027vnic_type\u0027) !\u003d network_model.VNIC_TYPE_DIRECT)"},{"line_number":5512,"context_line":"            # NOTE(danms): We need to collect any VIFs that are currently"},{"line_number":5513,"context_line":"            # down that we expect a down-\u003eup event for. Anything that is"},{"line_number":5514,"context_line":"            # already up will not undergo that transition, and for"}],"source_content_type":"text/x-python","patch_set":3,"id":"df7087c5_1a18307f","line":5511,"updated":"2018-03-12 10:58:38.000000000","message":"We want that behavior also for PFs. the list VNIC_TYPE_DIRECT_PASSTHOUGHT should be used here.","commit_id":"a77a8eaa7dd5d10b8850124f1a654f13eb6cd53b"}]}