ipng/vppcfg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'main' of github.com:pimvanpelt/vppcfg into main

Browse Source
This commit is contained in:
Pim van Pelt
2022-04-03 09:04:19 +00:00
parent d30f2d8965 5e7f1bdba4
commit 75e5a23538
2 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
LICENSE
View File

@ -1,4 +1,3 @@
Copyright (c) 2013, Rayed A Alrashed
Copyright (c) 2021, Pim van Pelt <pim@ipng.nl> Copyright (c) 2021, Pim van Pelt <pim@ipng.nl>
All rights reserved. All rights reserved.

31
README.md
View File

@ -29,15 +29,20 @@ pyinstaller vppcfg --onefile
``` ```
dist/vppcfg -h dist/vppcfg -h
usage: vppcfg [-h] -c CONFIG [-s SCHEMA] [-d] usage: vppcfg [-h] [-s SCHEMA] [-d] [-q] [-f] -c CONFIG {check,plan,apply} ...
positional arguments:
{check,plan,apply}
optional arguments: optional arguments:
-h, --help show this help message and exit -h, --help show this help message and exit
-c CONFIG, --config CONFIG
YAML configuration file for VPP
-s SCHEMA, --schema SCHEMA -s SCHEMA, --schema SCHEMA
YAML schema validation file YAML schema validation file
-d, --debug Enable debug, default False -d, --debug Enable debug logging, default False
-q, --quiet Be quiet (only warnings/errors), default False
-f, --force Force progress despite warnings, default False
-c CONFIG, --config CONFIG
YAML configuration file for vppcfg
``` ```
## Design ## Design
@ -109,7 +114,7 @@ Fields:
an error is repeated N times, and it's good practice to precisely establish how many errors an error is repeated N times, and it's good practice to precisely establish how many errors
should be expected. That said, this field can be empty or omitted. should be expected. That said, this field can be empty or omitted.
## Reconciling ## Planning
The second important task of this utility is to take the wellformed (validated) configuration and The second important task of this utility is to take the wellformed (validated) configuration and
apply it to the VPP dataplane. The overall flow consists of three phases: apply it to the VPP dataplane. The overall flow consists of three phases:
@ -197,3 +202,19 @@ and finally all objects are synchronized with the configuration (IP addresses, M
must be temporarily set admin-down to change that!) must be temporarily set admin-down to change that!)
1. Add IPv4/IPv6 addresses 1. Add IPv4/IPv6 addresses
1. Set admin state for all interfaces 1. Set admin state for all interfaces
## Applying
Finally, once the path planner does its work and orders the operations to reconcile the running dataplane
into the desired configuration, we can apply the configuration. Currently not implemented, pending a bit
of community feedback.
For now, the path planner works by reading the API configuration state exactly once (at startup), and then
it figures out the CLI calls to print without needing to consult VPP again. This is super useful as it’s a
non-intrusive way to inspect the changes before applying them, and it’s a property I’d like to carry forward.
However, I don’t necessarily think that emitting the CLI statements is the best user experience, it’s more for
the purposes of analysis that they can be useful. What I really want to do is emit API calls after the plan
is created and reviewed/approved, directly reprogramming the VPP dataplane. However, the VPP API set needed
to do this is not 100% baked yet. For example, I observed crashes when tinkering with BVIs and Loopbacks,
and fixed a few obvious errors in the Linux CP API but there are still a few more issues to work through
before I can set the next step with vppcfg.