Quantum OVS tunneling - Why delete openflows on added port in bridge br-int ?

We don't add flow on VM's port.

Ok, I understand.
If we don't add flows on VM's port why add a delete flow command in the code ?
Is it to do clean up in case of a rule is added ?

git blame on that line of code points to the following bug report that explains why https://bugs.launchpad.net/quantum/+bug/1019491

No this bug point to the line https://github.com/openstack/quantum/blob/stable/folsom/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L387
This bug added the 'if' line to be sure the port exists before delete related flows.

The line I pointed is related to the blueprint
https://blueprints.launchpad.net/quantum/+spec/quantum-ovs-tunnel-agent
https://review.openstack.org/#/c/4367/

It's what I understand, are you agree ?

Hi Edourard,

Sorry about this. When I click on this link https://github.com/openstack/quantum/blob/stable/folsom/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L387

It was highlighs this line:
        if int(port.ofport) != -1:
            self.int_br.delete_flows(in_port=port.ofport) <--- Which is line 451 must be some chrome/linux issue.

checking...

So line 387 is:

        if lvm.network_type == constants.TYPE_GRE:
            if self.enable_tunneling:
                self.tun_br.delete_flows(tun_id=lvm.segmentation_id) <--- 387

lvm.segmentation_id is the gre_tunnel key that is used for a tenant's network. Once that tenants network is deleted (if that network_id existed on this HV) then the flow entry that was added to allow traffic to the vm on this tunnel matching this key needs to be deleted since it's no longer used. The flow entries that it is deleting was added here (line 315, 320)

        if network_type == constants.TYPE_GRE:
            if self.enable_tunneling:
                # outbound
                self.tun_br.add_flow(priority=4, in_port=self.patch_int_ofport, <---
                                     dl_vlan=lvid,
                                     actions="set_tunnel:%s,normal" %
                                     segmentation_id)
                # inbound bcast/mcast
                self.tun_br.add_flow( <---
                    priority=3,
                    tun_id=segmentation_id,
                    dl_dst="01:00:00:00:00:00/01:00:00:00:00:00",
                    actions="mod_vlan_vid:%s,output:%s" %
                    (lvid, self.patch_int_ofport))

Sorry for the confusion before.

Whoops sorry I was looking at master not stable/folsom......

If port_dead() is called which adds the flow entry:
        self.int_br.add_flow(priority=2, in_port=port.ofport, actions="drop")
and then later the port shows up we delete this flow entry in port_bound()

The reason for the if int(port.ofport) != -1:

is because if the HV is rebooted the tap interfaces that connect to the vms will not persist the reboot but they will still be in OVSDB. The ovs agent will start up for the first time (after reboot) and detect this as a new port (since its the first time it's run ovs-vsctl list-ports br-int). Then it will enter port_bound() but since the tap interface doesn't exist on br-int port.ofport will == -1 and if it runs delete_flows with inport=-1 (which isn't a valid port as these must be non negative ) ovs-vsctl will return non 0 which causes an exception. This is the reason for the if statement. Sorry again about the confusion. Does this answer your question?

Ok, it's clearer.

I didn't saw that when a port is dead we put it in the dead VLAN and add flow rule to drop all its traffic.

So if I understand, a port is dead when it is administratively down.
An when it goes administratively up, we put it in the appropriate local VLAN and delete all drop flow rule (in port_bound())

Thanks Aaron.