This requires a schema change, adding 'mode' and 'load-balance' fields,
a semantic invariant that 'load-balance' can only be set in the case of
LACP and XOR bonds, a mapper from the mode/lb strings, ie.
"round-robin" to their VPP numeric counterparts, a bunch of unit tests.
Then in the reconciler, changing bonds (__bond_has_diff()) will
invalidate any LCP or sub-interfaces built on them, so those will have
to be pruned. create_bondethernet() will now create (or re-create)
the bond with the correct flags.
Unit-tests, YAML tests and the integration test all pass.
Updated config-guide.
TIL! Using the existence of obscure member sys._MEIPASS, I can detect if
we're running from a bundled PyInstaller binary, versus running from Python
directly.
Add schema.yaml to the datas of the PyInstaller spec. Then, if the
-/--schema flag is given, use it, and if it's not given, default to the
built-in one if we're running from a bundled binary, or fall-through to
./schema.yaml in other cases.
This avoids the need for config/schema.py as a carbon-copy of the schema,
slick!
Bridges can be created with default settings, with specific settings,
and they can be sync'd at runtime with all of the settings in this
change.
Notably missing are two features:
- unknown unicast flooding into specific interfaces (as opposed to
on/off on the bridge)
- learn-limit, which does not have an API getter, only a setter.
The handling of BVI is awkward, with the autoderived interface name
"bviXX" based on the bridgedomain bd_id. Lots of special casing happens
on account of this decision, and to make matters worse there is poor
interaction (leading to VPP crashes) when BVIs and Loopbacks are used
at the same time: https://lists.fd.io/g/vpp-dev/message/21116
In this commit, I reintroduce the ability to set bridgedomain virtual
interfaces by means of the 'bvi' keyword. The 'bvi' must:
- be a Loopback interface
- must be used at most once (bvi_unique())
When pruning, I now need to prune bridgedomains before pruning
loopbacks, because any given loopback might be a BVI for a bridge. So,
I'll remove the loop/BVI from the bridge (by setting it to L3) and only
then removing the loopback from VPP.
In the reconciler, remove BVIs that have changed in prune_bridgedomains()
and set it in sync_bridgedomains().
The handling of BVI is awkward, with the autoderived interface name
"bviXX" based on the bridgedomain bd_id. Lots of special casing happens
on account of this decision, and to make matters worse there is poor
interaction (leading to VPP crashes) when BVIs and Loopbacks are used
at the same time: https://lists.fd.io/g/vpp-dev/message/21116
This is step one of a refactor of the logic. In this commit, I'm
removing all of the BVI logic from the codebase, rendering bridgedomains
unable to have IP interfaces. In the next commit, I will introduce new
behavior in the schema, allowing for 'bvi' to be a loopback
interfacename which will be used as BVI for a bridgedomain, restoring
the ability to use bridgedomains with IP interfaces (using a loop).
Refactor validator main function to avoid 'interface' symbol clash.
Add get_mtu() for interfaces, returns the sub-int's MTU or its parent's MTU, defaulting to 1500.
Ensure MTU for all bridge-domain members is set to the same value.
Ensure all bridge-domain members are L2 (have no LCP, have no address)
