305a30b1a1
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.
A VPP Configuration Utility
This tool reads a configuration file, checks it for syntax and semantic correctness, and then reconciles a running VPP daemon with its configuration. It is meant to be re-entrant and stateless. The tool connects to the VPP API and creates/removes all of the configuration in a minimally intrusive way.
NOTE This code is under development, and probably won't work well until this note is removed. If you're interested in helping, reach out to <pim at ipng dot ch> to discuss options.
Building
This program expects Python3 and PIP to be installed. It's known to work on OpenBSD and Debian.
## Install python build dependencies
$ make install-deps
## Ensure all unittests pass.
$ vppcfg/tests.py -d -t vppcfg/unittest/yaml/*.yaml
## Build vppcfg
$ make build
## Install the tool with PIP
$ make install
## To build & install debian packaging
$ make pkg-deb
$ ls -l ../vppcfg_*_amd64.deb
Running
usage: vppcfg [-h] [-d] [-q] [-f] {check,dump,plan,apply} ...
positional arguments:
{check,dump,plan,apply}
check check given YAML config for validity (no VPP)
dump dump current running VPP configuration (VPP readonly)
plan plan changes from current VPP dataplane to target config (VPP readonly)
apply apply changes from current VPP dataplane to target config
optional arguments:
-h, --help show this help message and exit
-d, --debug enable debug logging, default False
-q, --quiet be quiet (only warnings/errors), default False
-f, --force force progress despite warnings, default False
Please see vppcfg <command> -h for per-command arguments
Documentation
Main user-focused documentation:
Developer deep-dives:
Licensing
The code in this project is release under Apache 2.0 license. A copy of the license
is provided in this repo here. All contributions are held against our
contributing guidelines. Notably, all code must be licensed
Apache 2.0, and all contributions must come with a certificate of origin in the
form of a Signed-off-by field in the commit.
All documentation under the docs/ directory is licensed Creative Commons Attribution 4.0 International License (details). A copy of the license is provided in this repo here.