We were only adding the ChassisCreateEvent, but if Chassis_Private
table is present, we should also add the event related to it
Change-Id: I40cf7d4c04636160ac65dfe32664430878d72b9c
This will help to implement different wiring mechanisms, such
as using l2vni/vrfs which will require linux bridge/vlan devices.
This way the modifications on the drivers will be minimal and
the wiring actions can be reused across them
Change-Id: Ic61c58fcc807a450410d085ead9c582e70563d5e
This is done to ensure reusability from different drivers, as well
as in the future to more easily support different ways of exposing
without having to modify all the drivers
Change-Id: I1983846191f9ffc82437fd899a7b38272ab28e07
When exposing IPs, there is a need to first wire it, i.e., ensure
connectivity to/from OVN overlay, and then expose the IP through
BGP. For withdrawn the process is the opposite, first withdraw the
IP through BGP, and then remove the wiring
Change-Id: I3d41380829e2aa5dc3109a37f8879246a718c8d7
Ensure methods get_virtual_ports_on_datapath_by_chassis returns
an empty list if the datapath no longer exists
Change-Id: Ia50da1c8366ea645f64ce6f422551c8dad282cce
The logic to expose the ovn lb on the provider network was
relying on the information about the tenant networks connected to
the cr-lrp, that is only filled in when tenant networks are also
exposed. This patch is changing that so that this loadbalancers
are exposed even if the tenant networks are not.
Change-Id: I297af3b87b9683724977c279d0f5f5157abe2672
This patch adds protection to expose_subnet in case by the time
the event is processed the peer is not yet linked or already
deleted
Change-Id: I0d3872d31055d94766b7483e074bd417e852fd2f
This patch adds protection when processing an expose_subnet action
in case the router gets deleted before the event gets processed
Change-Id: I2d07c77568f7ea51f464c4185d9e28f5e477174f
There is a chance that the routing table associated to the ovs
bridge device collides with the one assigned for the VRF. If this
is the case there will be more routes than expected in the ovs
routing table and the traffic will be wrongly redirected to the
nic associated to the vrf instead of to the ovs bridge (e.g., br-ex)
Change-Id: Id723800050a6a4e367a3c13600fd2a7cdca17028
The symbol is documented to be ovn_bgp_stretched_l2_driver, while
it in setup.cfg has been installed as ovn_stretched_l2_bgp_driver.
This patch makes the symbol consistent with the documentation.
Change-Id: I5691779d0f465b475a5ea2335ed4323591a1d8f0
For vlan provider network we need to add the mac entry for the cr-lrp
pointing to the vlan device, not the bridge itself.
Otherwise this won't work when the router has snat disable.
Story 2010620
Task 47553
Change-Id: I2171faf62b57030465b5860a9a3c95aaac1e45ec
The calls were doing nothing but better to not do them if not
needed. This patch ensures we only make calls for the actions
where it is needed to expose/withdraw IP(s).
Change-Id: I5bc75e9e03c42da811517e80c7b5305996a03f3f
There are chances that while running a sync action some unhandled
exception is raised and kills the agent. To avoid this patch is
ensuring any exception raised during the re-sync action is properly
logged and allows the sync actions to continue in the next iterations
Change-Id: Ie1b0ee5fd2ff64cfcbfc948a592f5a9956613247
We need to wait to expose the ovn lb with VIP on the provider
network for them to have members (and therefore have an entry
on the Load_Balancer table at the SB DB) so that it gets
associated to one specific cr-lrp (the one that will reply to
ARPs)
This patch partly reverts/adapt what was done in [1] to fix the
problem of exposing the VIPs in all the nodes with cr-lrp connected
to the same provider network
[1] https://review.opendev.org/c/x/ovn-bgp-agent/+/873073
Change-Id: Idc1022bc0593c21e272d138757391800f12415f1
After change [1] we forgot to consider the ovn lb IPs exposed
on the re-syncs. This leads to the exposed IPs to be withdrawn.
This patch fixes this, ensuring the exposed IPs are not removed
on re-syncs.
[1] https://review.opendev.org/c/x/ovn-bgp-agent/+/873073
Change-Id: Ie1fb190d671b4957633cd528e1371ad409cf07c2
There is an option for race conditions on the
"is_provider_network" checkings when doing expose/withdraw actions.
This happens when by the time the action checking if the
port associated datapath is a provider network, the network
associated to the datapath has been deleted, throwing an exception
at ovsdbapp level -- ValueError
This case needs to be handled so that if it happens on a expose
action, the processing is not continued (there is no need to expose
an IP on a subnet that is removed, as the port will be removed too).
If by contract it happens on a withdraw, there are some cases where
it can be dismiss too, as other associated event will take care of
them (such as the case for OVN_LBs or for remote IPs), but needs to be
handled in others (such as IPs on the provider network). This
patch is adding this logic to the driver.
Change-Id: Ia5d832499d70ebae2aa413b2028232d745d9131f
There is a chance that at the same time of processing a
withdraw_subnet event, its associated cr-lrp got moved to the
local chassis. This will lead to KeyError exception as the
withdraw process moves forward but the event to associate the
cr-lrp to the local chassis has not yet being processed.
In this case there is no need to process the withdraw_subnet
event in the local chassis as it has not yet been exposed. This
patch is adding protection for this case.
Change-Id: I64bd6e99cd6b38247b4a77c8a61860d51c6d116c
There is a chance that a lrp port got just created when
we discover it on a re-sync action and did not yet have the
information about the peer. In that case the port should be skip
until the information is ready. Another option was that the lrp
port was being deleted. In that case it is also the right action
to skip it.
Change-Id: Iddc30a3bfc910fa3e2e390e54015c82f13f3fdfa
There is already a sync function, so there is no need to
recheck the flows when VM IPs are being exposed
Change-Id: I15100bbec6b8856a9a34f00e2d92164cc992447b
After change [1] in ovn-octavia, there is no information at the
Load_Balancer table on OVN SB DB related to the provider network.
This means the logic to managed the OVN loadbalancer with VIPs on
the provider networks needed to be updated to account for it.
[1] https://review.opendev.org/c/openstack/ovn-octavia-provider/+/871263
Change-Id: I6fbfb3eeb115c3a528d580561868e45ac72e8318
This patch adds the option to filter the tenant subnets to
be exposed depending on them belonging or not to an
address_scope (i.e., to a subnet pool associated to an
address_scope).
Change-Id: Iacbcc2ef094858f82166273d5b23c81f10324726
Docs should be published at https://ovn-bgp-agent.readthedocs.io/
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: I4e59fabd66aa9e67d59937762ff9eadca8fe33fd
Fix the "openstackdocs_auto_name" configuration value type, otherwise
the command will fail with the following error:
Warning, treated as error:
The config value `openstackdocs_auto_name' has type `str', defaults to
`bool'.
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: Id130a0dd9eabc2ed8847b25e8787947086863f79
This extra checking got (wrongly) dropped at [1].
This patch re-adds it with the adaptation to the new DB field
[1] https://review.opendev.org/c/x/ovn-bgp-agent/+/868332
Change-Id: Ida98871610536f51b924cc79de0433b53b9139e9
When using configdrive instead of dhcp the port_binding entry for
the tenant IP has ['unknown'] at the mac entry instead of the mac
and IPs of the VM. There is information added about the actual
IPs on the external_ids (neutron:cidrs) that could be used in
that case. This patch ensures this information is processed
if there is an unknown mac entry.
Change-Id: I59dab6fa7e1ec64c86340861e2811c3cdcedfa96
When a VIP changes chassis the port_binding table gets the
chassis information updated instead of deleted and added.
This patch ensures update of chassis field is properly handled
in that case so that the IP/FIP gets properly exposed on time,
rather than the re-sync function fixing it
Change-Id: Idced3467780f7a17aabe5cc2d821020152c7735b
When the VM that has a FIP associated is not using dhcp to get
its IP, the mac entry on the port_binding table is set to
['unknown']. This made the resync to fail on the mac checking
and therefore remove the exposed FIP routes.
This patch checks if the macs is unknown and it is a IP on the
tenant networks. If that is the case we don't check the format
of the mac and call expose_ip with empty IPs, as the IP to expose
in this case is the FIP that will be obtained at the expose_ip
method anyway.
Change-Id: Icdfc1cdc8b759181de3509cd5ddda330270fa6dc
These actions were carried out during the sync phase. However
the VRF configuration can be perform on the start up phase and
probably won't change at all over time. We added some info logs
about it, and left the actions also at the sync function in case
they are manually changed/deleted by mistake -- as a reconcile
action
Change-Id: Ic39014b0e86ef2ed7b9cfc33d034c79cc150e7c0
Update a couple of utils functions related to router_gateways
to ensure the return value is a boolean and not "None"
Change-Id: Ie904b3010d44761421319080def79bc25eef9a7c
This driver allows to announce tenant networks with
an address scope via the virtual router IP.
For this to work, all routers in the respective L2
network must be reachable to each other and the
ovn-bgp-agent/frr needs an IP in this network to
talk to its BGP peer.
The following changes have been made:
- To filter which networks are announced via which
agent/BGP session, we added a filter on the
OpenStack address scope
- Networks are announced instead of VM IPs
- Add SubnetRouterUpdateEvent to handle updates of
lrp ports
Depends-on: https://review.opendev.org/c/openstack/neutron/+/861719
Change-Id: I6e48c7e056ba2101ad670ab54c96e072459c5e65
When a VIP for an amphora load balancer is created on the
(IPv6) provider network there is a need for the agent to
create an NDP Proxy (similarly to the case for the VMs on
the tenant network) so that the traffic can be properly
redirected out through the br-ex.
Change-Id: I6237c51f0f59aab44d18e10dd46fc1ddfe38b215
After [1] the Load_Balancer table at SB DB stop using the
datapaths field, in favor of the datapath_group.
This patch ensures this new field is processed if available
[1] https://mail.openvswitch.org/pipermail/ovs-git/2022-August/026755.html
Change-Id: I3f3f8395d56d4ff501d6ae2ad1a359defe6ab25d
In previous code reorg this issue was introduced. When a
tenant port gets deleted, the old row does not have information
about the chassis. So this needs to be used only for the UPDATE
events, and for the DELETE event simply use the one at the row
being deleted
Change-Id: Ibde8cab5e45ff141cdcebae033909cb4bbfb90cd
Avoid code duplication by reusing the same functions for
events and sync actions.
It also fixes a leak on NDB Proxy removal
It also bumps the minimum coverage to 87%
Change-Id: I7d704381c0585b642f0c420b98cd4090266fa2ce
This patch moves the logic about exposing/withdrawing an IP
on the provider network to common functions to avoid code
duplication and make their modifications easier.
Also fixes a typo on ensure_arp_ndp_enabled_for_bridge
function name
Change-Id: I70d86c12fa860a8850b6bcceb7b7374d9702aaee