There is a chance that patch ports are not yet created when
the agent tries to add the ovs-flows for them. This ends up in
the flows not being added until the next re-sync action or a
new VM created in the same node
Closes-Bug: #2018565
Change-Id: I598267f701587696feb31f9dedef8c9f1895fc72
As part of commit [1] we moved the register options to a function,
that means unit tests need to be updated to register those option
in the setup if they are needed, otherwise we can get errors like:
Captured traceback:
~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
File "/builddir/build/BUILD/ovn-bgp-agent-0.3.1.dev112/ovn_bgp_agent/tests/unit/drivers/openstack/watchers/test_bgp_watcher.py", line 878, in test_run_no_subnets_datapath
CONF.set_override('expose_tenant_networks', False)
File "/usr/lib/python3.9/site-packages/oslo_config/cfg.py", line 2059, in __inner
result = f(self, *args, **kwargs)
File "/usr/lib/python3.9/site-packages/oslo_config/cfg.py", line 2442, in set_override
opt_info = self._get_opt_info(name, group)
File "/usr/lib/python3.9/site-packages/oslo_config/cfg.py", line 2858, in _get_opt_info
raise NoSuchOptError(opt_name, group)
oslo_config.cfg.NoSuchOptError: no such option expose_tenant_networks in group [DEFAULT]
[1] 90b6940b21
Change-Id: I138ab9a4ed6f7b1d0138129c00362f603fc4320a
When no VLAN tag is defined in the portbinding or Logical Switch Port entry, the append will fail
Change-Id: I8889ea036a8bb4ea7096d1165b0621442acea33d
Signed-off-by: Justin Lamp <justin.lamp@netways.de>
Until ovsdbapp version can be bumped to the release 2.3.0, we need
this workaround to be able to use this function that was implemented
in [1], and that is needed for the NB DB driver
[1] https://review.opendev.org/c/openstack/ovsdbapp/+/873853
Change-Id: Id7c75d81175c283a9814b536eec473978b8b0c7f
This reverts commit 9dcede6d92464e10c2a313d5df8fb7c577e2a326.
Reason for revert: This does not meet the current uppper-constraints
Change-Id: I565a2774bd9814584c6d2cb77e7cb946718de8ac
There may be serveral neutron vlan provider networks associated
to a physical bridge. For example, having ovs bridge-mappings
set to "datacentre:br-ex", and then have several provider networks
of vlan type associated to datacentre.
This was not being properly handled on the sync actions as only
the first vlan tag was being processed. This patch ensure all the
vlan tags associated to a bridge are processed and their respective
vlan devices are created
In addition, it seems the way of estimating the coverage has changed,
as now the value is higher, this patch also bumps the minimal coverage
(setting it to 92%), so that the coverage is not reduced unnoticed
Change-Id: I39168fa633f0a69439980c5a2fd163e389cf11fe
The interval to do the resync was meant to be configurable but
it was always taking the default values due to the config
being loaded after the decorator gets applied.
This patch is moving away from periodic_task in favor of
loopingcall.FixedIntervalLoopingCall so that we can more easily
enforce the reconcile intervals based on the config
Change-Id: I8c6b1ebac77336d5cbe2e725b38c5a0f53446934
There is a race condition when using cascade deletion where the
port is already deleted when the even for the loadbalancer gets
processed, therefore not being able to retrieve the needed information
to do the withdrawn.
This patch adds new logic on the removal so that it does not rely
on the VIP port but the VIP IP information
Change-Id: I168aeba377fb15abb284973e5500f6b4c82c7947
The patch port between br-int and the ovs provider bridge are created
upon the first VM created in that node with IP in the related provider
network (VM on the provider or FIP associated to it). Thus we need
to ensure the mac tweaking flows for those patch ports are added
as part of the wiring flow
Change-Id: Ieaa111506439625280f2ec64711a1447a5e94f54
When adding the exception for external networks that are not
provider [1] we break the logic for handling the FIPs association
events, and only the sync action was correcting it -- also hidding
the problem
With this patch we make the proper checking (on the patch port,
not on the VM port) to decide to only expose the FIPs if the
external networks is also a provider one
[1] d9c7de6465
Change-Id: Ie344ff0f477e32df270dedea02ff5b689f45836a
We are moving away from storyboard and will be using launchpad instead.
Depends-On: https://bugs.launchpad.net/ovn-bgp-agent/
Change-Id: I43f2da995af02c17de1995373bf65bf9f7c8e212
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
It may happen that if pyroute crashed with a dump interrupted,
and the exception is not properly handled, the agent will stop
processing further events
Change-Id: I2416393a3c45f2424aefd342380d7f9e07df9123
It is possible that FRR gets restarted, loosing the configuration
added by the agent (for instance the vrf leaking). As the sync
action is kind of heavy to run it more frequently, this patch adds
a new periodic task that is in charge of just ensuring the FRR
configuration and not about the routes being exposed. That way
it can be executed more frequently.
Change-Id: I19c4a295eac6454d5aa465aa7b90ecf258701850
For vlan provider networks we add the mac entry for the cr-lrp
pointint to the vlan device, not the bridge itself [1].
This patch ensure the deletion part takes that into account too
[1] https://review.opendev.org/c/openstack/ovn-bgp-agent/+/875636
Change-Id: I8221457ee588cd36de08cc0976bf6a1ec377c331
This patch adds initial support for the OVN exposing method, where
there is no need to write stuff once VMs are created in a host, but
just to advertize them.
Note as only underlay exposing method is currently supported for
the bgp drivers, the bgp utils for wiring/unwiring only consider
these 2 methods.
Change-Id: Id0d18b70f097981289851fd65a02dcaba73a7467
Some drivers are duplicating some base BGP configuration to later
expose IPs. This patch is moving them to the bgp utils to avoid
code duplication.
It will also allow different base BGP configuration for different
exposing modes within the same driver, once that is implemented.
Change-Id: I0061b4598ad649c7492af3464a07d95a21eebc69
With the move to be included in the Neutron governance we have to update
the references from x/ to openstack/
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: I9bdd16d1feacefa0a9937bcf322ad7c242b506d4
This patch creates a new driver using NB DB information instead of
SB DB. This has 2 objective:
- Alleviate the stress on big scale environment due to many
connections to the SB DBs.
- Being more future proof as content generated in the SB DBs based
on NB DB information is subject to change. For example we were
already adviced that the information we are currently using for
ovn LB events at the SB DB is probably going to change soon.
Depends-On: https://review.opendev.org/c/openstack/ovsdbapp/+/873853
Change-Id: Ib6bf077ce1e354652f5b728bd7192c762d3d071b
The IPs to add to the provider bridges for both ARP and NDP
to work are moved to constant, and the IPv4 is changed by the
locallink range so that we avoid collisions with the tenant
networks, otherwise some of them won't have proper connectivity
Change-Id: Iff2fe1dff120139ce71f05e28dfa66cfb6006e10
If the FRR service is restarted, its configuration will not include the
bgp-vrf section that is necessary to advertise the IPs that the OVN BGP
agent exposes (unless the agent is restarted later).
With this patch, the bgp-vrf part is added to the FRR configuration when
the sync is executed periodically.
Change-Id: I54e29a6412fe09e727d8a373fccd085e8d25c941
It seems it is posible to have external networks (with cr-lrp
associated to them) that are not provider networks (e.g., vxlan
type). In this case we are opting for not exposing through BGP
their IPs as there is no physical infra handling it. This patch
makes sure those networks are not considered when processing the
events associated to them.
Change-Id: Ib436894e2337248b4e37039a1d6690fef406753b
If a new provider network is created, we need to re-sync so that
we have the needed information to expose IPs on it or through
CR-LRPs that will be associated to it
Change-Id: I822ae25f93b0a9e017f86c3f0ac4ac0010d49211
We need information about the bridge_device when wiring/unwiring
the exposed IPs. If this is not provided, the wiring/unwiring functions
need to return False and the driver need to ensure it is considered,
with proper logging of the failure at exposing/withdrawing.
The missing bridge device may happen if the provider network
is deleted in between or if it was created and not yet present
due to missing sync action
Change-Id: I34c9840b1ac3073c5d50c1c6e5b2d488be9ceca9
As we are only doing read operations, we can connect to any
Southbound cluster member, not necessarily only the leader.
Change-Id: I3f528dd10736c71825983d1fb1ee8c621c08a745