Hi Pim,
This is most excellent! Thank you for sharing your work.
I also have only taken a quick pass through the information you posted,
but have been thinking about tackling a YAML or JSON based configuration
format to help simplify the unit testing environment and make use case
test automation more accessible.
From a FD.io community perspective, your work could readily be set up
as a sub-project which would be extremely beneficial were it to be
adopted as a tool to be utilized in the test pipeline in addition to
other downstream VPP consumers.
I will give a test drive this week and provide some feedback to you. I'm
very interested in helping out with this effort.
In case you are not aware, Ole introduced JSON formatted API output and
vat2 which translates JSON api files into VPP api calls. I have used
this feature to capture 'make test' testcase configurations and replay
them to VPP using vat2. This experiment is part of the 'make test'
framework refactoring that I am engaged in to separate Scapy packet
stream processing (pcap input file generation and pcap output file
verification) from the 'make test' python framework. I haven't looked
at your implementation closely at this point, so you may in fact already
be using this. If so, please excuse my ignorance. :)
There is also a gap in VPP control plane interfaces between the Debug
CLI and VPP-API. As you mention in your write-up, the debug CLI is NOT
intended to be used as the primary control plane interface.
The original control plane design patter by Dave Barach was to split
feature configuration into parallel CLI/API parsing/message validation
stages, each of which would call the same feature config function. This
allowed Dave to rapidly prototype the configuration interface using the
debug CLI and subsequently add the VPP-API with minimal effort.
Unfortunately this architecture has not been utilized universally as VPP
features have been added. This has led to inconsistency between debug
CLI commands and the VPP-API. While it is understandable that there are
debug configuration attributes that are not appropriate for the
production API, I think that it would be great to make a pass through
the feature set to align them more closely and to promote the sharing of
common configuration code in VPP features between the Debug CLI and VPP-API.
In any case, enough of my ranting -- thanks again for your contributions
to VPP & the FD.io community!
-daw-
On 4/2/2022 2:21 PM, Florin Coras wrote:
Hi Pim,
Definitely cool! Haven’t had a chance to go through all of it but the
fact that some binary api calls crash vpp is something we should fix.
It feels like vppcfg could also be used for extensive vpp api/cli/cfg
testing.
My quick 0.02$
Regards,
Florin
On Apr 2, 2022, at 8:17 AM, Pim van Pelt <p...@ipng.nl> wrote:
Hoi colleagues,
I know there exist several smaller and larger scale VPP configuration
harnesses out there, some more complex and feature complete than
others. I wanted to share my work on an approach based on a YAML
configuration with strict syntax and semantic validation, and a path
planner that brings the dataplane from any configuration state safely
to any other configuration state, as defined by these YAML files.
A bit of a storyline on the validator:
https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
A bit of background on the DAG path planner:
https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html
Code with tests on https://github.com/pimvanpelt/vppcfg
The config and planner supports interfaces, bondethernets, vxlan
tunnels, l2xc, bridgedomains and, quelle surprise, linux-cp
configurations of all sorts. If anybody feels like giving it a spin,
I'd certainly appreciate feedback and if you can manage to create two
configuration states that the planner cannot reconcile, I'd love to
hear about those too.
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 (see my thread from last week,
thanks for the response Neale), and fixed a few obvious errors in the
Linux CP API (gerrit) but there are still a few more issues to work
through before I can set the next step with vppcfg.
If this tool proves to be useful to others, I'm happy to upstream it
to extras/ somewhere.
--
Pim van Pelt <p...@ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21185): https://lists.fd.io/g/vpp-dev/message/21185
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
