Hi Pim, Over the past few years, we had many discussions about how best can VPP be configured by end users. What is really nice with your proposal is that it’s pragmatic and simple. Actually much more simple than the Netconf/yang (remember Honeycomb…) and probably cover many use cases. I’ve not yet tried it but will certainly do it soon. Thanks ! Jerome
De : vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> de la part de Pim van Pelt <p...@ipng.nl> Date : samedi, 2 avril 2022 à 17:18 À : vpp-dev <vpp-dev@lists.fd.io> Objet : [vpp-dev] Feedback on a tool: vppcfg 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<mailto:p...@ipng.nl>> PBVP1-RIPE - http://www.ipng.nl/
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21186): https://lists.fd.io/g/vpp-dev/message/21186 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] -=-=-=-=-=-=-=-=-=-=-=-
