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 > <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 > <https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html> > Code with tests on https://github.com/pimvanpelt/vppcfg > <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 <mailto:p...@ipng.nl>> > PBVP1-RIPE - http://www.ipng.nl/ <http://www.ipng.nl/> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21184): https://lists.fd.io/g/vpp-dev/message/21184 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] -=-=-=-=-=-=-=-=-=-=-=-
