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.
This attribute of the 'interface' schema allows the user to prompt what
type of PHY they are expecting this interface to be. It will serve an
immediate and a future purpose.
Immediate: presence of the 'dpdk' device-type in a list of interfaces
will help an upcoming vppapy.mockconfig() to generate a cache without
having to talk to the API. This is useful to generate a pre-compute a
complete vpp.exec based off of an empty VPP dataplane
Future: addition of different PHY types, notably RDMA and
VirtualEthernet types
TESTED:
- Added a unit test to ensure that only is_phy() eligable interfaces
receive the device-type attribute.
- All unit and YAML tests pass.
If there is no need to connect to a running VPP instance (for example,
if the configuration is going to mock the VPPMessage()s rather than read
them from the VPP dataplane), then there is no need to assert that a
socket exists.
Scan the JSON files in the constructor though, not at connect time, as
other methods may want to use the JSON files without having to connect
to the API.
The execution of vppcfg/tests.py from the main directory will cause the
--test flag to not glob any YAML files. Enter the source directory
before executing the tests.
Before:
- No YAML tests were executed, so 'success' was always returned. Unit
tests were all executed.
After:
- Both unit tests and YAML tests are executed (and they all pass)
Before, interface_names was a literal copy of the VPPMessage() from
sw_interface_details, so interfaces and interface_names kept the
messages twice. This change makes interface_names a pointer to the index
on interfaces.
- Update the cache creation to make the indirection from interface_names
to interfaces
- Introduce get_interface_by_name()
- Update/fix all the call sites
Tested:
- All unit tests and yamltests pass before and after this change
- The hippo integration test passes before and after this change
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>
Initial version of deb pkg, based on pybuild. Reverted to classic
setup.py, because debian tooling does not yet understand the newer
pyproject.toml.
Yamale is absent from the list of package dependencies as there is as
yet no upstream debian packaging for it, will need to work around with
documentation and install with pip for the moment. Autotest of the
debian packaging is also disabled for the moment.
Systemd service is automatically installed and bould to the vpp
service, but does not become active until the user creates the
configuration /etc/vpp/config.yaml
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
When a bridge-domain has a BVI, it will not sync/add the interfaces to
the bridge. As an example:
bridgedomains:
bd1001:
bvi: loop1001
interfaces: [ tap1001 ]
mtu: 9000
taps:
tap1001:
host:
bridge: br0
mac: 02:fe:83:97:f4:7f
mtu: 9000
name: vpp-bd1001
Before this change, the 'tap1001' would get created, but if the BVI
'loop1001' was correctly set up on the bridge, the code would continue
and skip over enumerating config_bridge_iface. After this change,
both the BVI will be checked (and added if not present), AND all
interfaces will be enumerated (and added if not present).
