First stab at integrating the acl-plugin from VPP. Allow to craft ACLs
consisting of one-or-more ACEs (this is ensured by 'terms' being
required with min=1), and a rich language to be able to set any L3
and L4 (UDP, ICMP, TCP) matchers that the plugin provides.
Explain how the syntax will look like, although for now only YAMALE
syntax checking can be performed (semantic validation is next).
TESTED:
pim@hippo:~/src/vppcfg/vppcfg$ ./vppcfg.py check -c example.yaml
[INFO ] root.main: Loading configfile example.yaml
[INFO ] vppcfg.config.valid_config: Configuration validated successfully
[INFO ] root.main: Configuration is valid
Add a feature to plan a configuration without reading from the VPP Dataplane.
In this mode, the configuration file is read and validated in the same way as `check` or `plan`,
but then instead of retrieving the running state from the VPP API, a state is re-created using
the physical interfaces specified in the YAML config.
Implement this by creating vppapi:mockconfig() which reads the 'interfaces' scope from the YAML
config file, and creates a VPPMessage() of type sw_interface_details for each interface that is a
PHY (for now, only supporting device-type 'dpdk').
If the flag --novpp is specified in the planner, call mockconfig() instead of readconfig().
Some further details:
- if the MAC is not set in the YAML config, it won't be set in the output exec file.
- for bondethernets, no MAC can be generated unless it's set in the first member.
- the MTU is always set, because it's mocked to 64b and the YAML file will always be higher.
TESTED:
- the unit tests and YAML tests all pass
- the integration tests all pass, but they do not call this new codepath
- Based on an empty VPP on Hippo, I compared the output of these two, side by side:
for i in intest/*yaml; do ./vppcfg.py plan -c $i -o /tmp/$i-vpp.exec; done
for i in intest/*yaml; do ./vppcfg.py plan --novpp -c $i -o /tmp/$i-novpp.exec; done
==> The only changes here are:
* if I cannot determine the bondether MAC in the --novpp case, it is not emitted
* if the MAC address is set in the YAML file, the --novpp case will always emit it
* if VPP has mtu 9000, the --novpp case will end up still emitting interface and packet MTU,
because it mocks the interface MTU at 64.
In all cases, --novpp emits more configuration statements, and the statements that it emits are
redundant.
Fixed python load paths so that vppcfg will work installed as python
library and standalone from the source directory, fixing load
pathes for resources such as yaml files along the way.
Added a make target for pylint called 'make check-style', fixed a
number of minor pylint issues along the way.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
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.
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.