Hoi Pim, This solves a challenge we are having in our infrastructure. Will give this a spin shortly!
— Eyle > On 3 Apr 2022, at 18:26, Pim van Pelt <p...@ipng.nl> wrote: > > Hoi, > > That's so much more enthusiasm than I had anticipated, thank you very much > for your kind and encouraging words! I've spent some time writing a starting > set of documentation. > User Guide: https://github.com/pimvanpelt/vppcfg/blob/main/docs/user-guide.md > <https://github.com/pimvanpelt/vppcfg/blob/main/docs/user-guide.md> > Config Guide: > https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md > <https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md> > > The config guide mentions a few caveats, nothing major, but just a few > considerations in case we do want to elevate this and use it more broadly > than just my basement ISP. While I wait around a bit for community feedback > on its use, I've cleaned up the code a bit, so that it can serve as a > standalone compiled binary now: > usage: vppcfg [-h] [-d] [-q] [-f] {check,dump,plan,apply} ... > > positional arguments: > {check,dump,plan,apply} > check check given YAML config for validity (no VPP) > dump dump current running VPP configuration (VPP readonly) > plan plan changes from current VPP dataplane to target > config (VPP readonly) > apply apply changes from current VPP dataplane to target > config > > optional arguments: > -h, --help show this help message and exit > -d, --debug enable debug logging, default False > -q, --quiet be quiet (only warnings/errors), default False > -f, --force force progress despite warnings, default False > > Please see vppcfg <command> -h for per-command arguments > > groet, > Pim > > On Sun, Apr 3, 2022 at 8:46 AM Jerome Tollet (jtollet) <jtol...@cisco.com > <mailto:jtol...@cisco.com>> wrote: > 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 <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io>> de la part de Pim van Pelt <p...@ipng.nl > <mailto:p...@ipng.nl>> > Date : samedi, 2 avril 2022 à 17:18 > À : vpp-dev <vpp-dev@lists.fd.io <mailto: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 > <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/> > > -- > Pim van Pelt <p...@ipng.nl <mailto:p...@ipng.nl>> > PBVP1-RIPE - http://www.ipng.nl/ <http://www.ipng.nl/> >
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21193): https://lists.fd.io/g/vpp-dev/message/21193 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] -=-=-=-=-=-=-=-=-=-=-=-
