Hi Pim This is very helpful. I'll give it a try ASAP.
Dave's proposal to incubate thi project in FDio as a subproject makes sense and I would be interested to follow up on that. On Sat, Apr 2, 2022 at 5:18 PM 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 architecture looks similar to neplan + systemd-networkd. I did not check the code yet in detail so I may be wrong. Thanks for sharing Luca > > 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 (#21197): https://lists.fd.io/g/vpp-dev/message/21197 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] -=-=-=-=-=-=-=-=-=-=-=-
