Bug 1649334

The issue happens to me also on my OVN HA + DVR deployment (3 controllers, 2 computes, no Octavia)
puddle 14.0-RHEL-7/2019-01-07.1

/var/lib/config-data/neutron/etc/neutron/neutron.conf:enable_dvr=True
/var/lib/config-data/neutron/etc/neutron/plugins/ml2/ml2_conf.ini:enable_distributed_floating_ip=True

DB NAT entries do not have external_mac set

_uuid               : 61e0295c-e327-41f7-8324-74929b74c84c
external_ids        : {"neutron:fip_external_mac"="fa:16:3e:57:fe:70", "neutron:fip_id"="772059ef-d0c0-4798-95de-be3e75301fb6", "neutron:fip_port_id"="95381926-1945-4e85-ac84-78f2aa35676a", "neutron:revision_number"="2", "neutron:router_name"="neutron-aeca181a-dd4d-426a-a772-9388ab25a77e"}
external_ip         : "10.0.0.216"
external_mac        : []
logical_ip          : "10.0.1.10"
logical_port        : "95381926-1945-4e85-ac84-78f2aa35676a"
type                : dnat_and_snat

_uuid               : 7e7030c4-7b79-46e5-ac80-866d206c4e2e
external_ids        : {}
external_ip         : "10.0.0.232"
external_mac        : []
logical_ip          : "10.0.1.0/24"
logical_port        : []
type                : snat

_uuid               : 0b8947f6-a4ec-4feb-8819-6a79594693bc
external_ids        : {"neutron:fip_external_mac"="fa:16:3e:f5:1b:cc", "neutron:fip_id"="3590fa6e-3416-43c5-b13e-ad2a5c4447a6", "neutron:fip_port_id"="1e43055d-0865-4a57-b5cf-3ffa22c2ccbf", "neutron:revision_number"="2", "neutron:router_name"="neutron-aeca181a-dd4d-426a-a772-9388ab25a77e"}
external_ip         : "10.0.0.212"
external_mac        : []
logical_ip          : "10.0.2.18"
logical_port        : "1e43055d-0865-4a57-b5cf-3ffa22c2ccbf"
type                : dnat_and_snat

_uuid               : ae619bd7-1810-4b9c-91c7-10a0566493e7
external_ids        : {}
external_ip         : "10.0.0.232"
external_mac        : []
logical_ip          : "10.0.2.0/24"
logical_port        : []
type                : snat

(In reply to Roman Safronov from comment #1)
> The issue happens to me also on my OVN HA + DVR deployment (3 controllers, 2
> computes, no Octavia)
> puddle 14.0-RHEL-7/2019-01-07.1
> 
> /var/lib/config-data/neutron/etc/neutron/neutron.conf:enable_dvr=True
> /var/lib/config-data/neutron/etc/neutron/plugins/ml2/ml2_conf.ini:
> enable_distributed_floating_ip=True
> 
> DB NAT entries do not have external_mac set
> 
> _uuid               : 61e0295c-e327-41f7-8324-74929b74c84c
> external_ids        : {"neutron:fip_external_mac"="fa:16:3e:57:fe:70",
> "neutron:fip_id"="772059ef-d0c0-4798-95de-be3e75301fb6",
> "neutron:fip_port_id"="95381926-1945-4e85-ac84-78f2aa35676a",
> "neutron:revision_number"="2",
> "neutron:router_name"="neutron-aeca181a-dd4d-426a-a772-9388ab25a77e"}
> external_ip         : "10.0.0.216"
> external_mac        : []
> logical_ip          : "10.0.1.10"
> logical_port        : "95381926-1945-4e85-ac84-78f2aa35676a"
> type                : dnat_and_snat
> 
> _uuid               : 7e7030c4-7b79-46e5-ac80-866d206c4e2e
> external_ids        : {}
> external_ip         : "10.0.0.232"
> external_mac        : []
> logical_ip          : "10.0.1.0/24"
> logical_port        : []
> type                : snat
> 
> _uuid               : 0b8947f6-a4ec-4feb-8819-6a79594693bc
> external_ids        : {"neutron:fip_external_mac"="fa:16:3e:f5:1b:cc",
> "neutron:fip_id"="3590fa6e-3416-43c5-b13e-ad2a5c4447a6",
> "neutron:fip_port_id"="1e43055d-0865-4a57-b5cf-3ffa22c2ccbf",
> "neutron:revision_number"="2",
> "neutron:router_name"="neutron-aeca181a-dd4d-426a-a772-9388ab25a77e"}
> external_ip         : "10.0.0.212"
> external_mac        : []
> logical_ip          : "10.0.2.18"
> logical_port        : "1e43055d-0865-4a57-b5cf-3ffa22c2ccbf"
> type                : dnat_and_snat
> 
> _uuid               : ae619bd7-1810-4b9c-91c7-10a0566493e7
> external_ids        : {}
> external_ip         : "10.0.0.232"
> external_mac        : []
> logical_ip          : "10.0.2.0/24"
> logical_port        : []
> type                : snat

I think it is a different issue. Due tothe fact the bug focuses on LB traffic flow I would suggest for you to raise a new bug for you issue

This issue can be resolved by changing the behavior in python-ovsdbapp. Due to lsp_get_up().execute() command being nested inside another transaction, the result isn't set until after the parent transaction completes. So execute() returns None and the code that would set the external_mac does not run.

I agree with Alex, this is different issue from the one that Roman mentions.
There's two separate things here:

1. Traffic to the VIP with Octavia is centralized no matter whether DVR is enabled or not, we did this by design due to a blocker BZ we had as previous to this, it wasn't working at all as the VIP port is not bound to any host. For this I suggested to run a new set of tests using latest OVN (https://bugzilla.redhat.com/show_bug.cgi?id=1649332#c1). It would involve patching the system manually and rerun she test.
If with latest OVN it doesn't work, then something else must be implemented. ODL folks implemented it by listening to the GARPs from the VIP; this should be already done by latest versions of OVN, hence why I'm asking for a re-test. Please, update this BZ or the OSP13 one with the results. 

2. DVR is broken under certain circumstances due to the ovsdbapp problem that Terry highlighted and opened a BZ for. https://bugzilla.redhat.com/show_bug.cgi?id=1669306

Due to the many conflicts in backporting the "virtual ports" feature from networking-ovn latest branches to OSP 13 I'm closing this bug as WONTFIX.

I've talked with Carlos (Octavia Squad Lead) and Luis Tomas(OCP) on IRC regarding the problem with backporting it (and its maintainability) and we've agreed to closing it as WONTFIX.

(In reply to Lucas Alvares Gomes from comment #6)
> Due to the many conflicts in backporting the "virtual ports" feature from
> networking-ovn latest branches to OSP 13 I'm closing this bug as WONTFIX.
> 
> I've talked with Carlos (Octavia Squad Lead) and Luis Tomas(OCP) on IRC
> regarding the problem with backporting it (and its maintainability) and
> we've agreed to closing it as WONTFIX.

Small correction here. Carlos didn't explicitly agree with closing this but he's aware of the reasons why I'm doing it.

Also, if the author of the bug thinks this is a must-have feel free to re-open it and we can discuss other possible solutions for this.

Cheers,
Lucas