Reviving an old project: Viconf
So a few days ago I cryptically tweeted out about finding a provisioning system I had coded about two years ago, and abandoned.
It came rather conveniently, as I was looking in to automating some processes, and a functional provisioning system would be welcome.
The system was sort of complete, and packed with interesting features, however in the core, it was flawed, and I decided, stupid as I may be, to rewrite the whole damn thing.
It may, however, be worth spending a little time on describing why I have written a provisioning system, and why I’m stubbornly standing with it, especially now that we have ansible and all of that.
The case of the speed test system
Years ago, my employer at the time had won a big contract, and in that contract they were required to hand over test reports for each delivered line. The very first line was tested on my laptop in the pop we had in the basement, and graphs made hastily in gnuplot.
I then decided to write a system that would generate the necessary test circuit configuration for the devices, automate the test process and generate reports.
This tool is now open source, but I haven’t touched it in years.
What I really liked about it however was the template engine. It was capable of turning any network template in to a form with validation.
It was based around Mustache templates. These templates are a lot simpler than any jinja2 templates that you may know from ansible, and that's quite the point. Simple templates that translates directly in to configuration.
The provisioning system
For a long time after that I was thinking of turning it in to a full fledged provisioning system, and about two years ago, I spend the summer freeze period doing so.
It was actually quite nice. I wrote an arbitrary inventory system, and a asynchronous component that would push config via napalm.
And then I got busy with other things, and the code was left to rot on Github. I archived it a few months ago.
This week I decided to revisit it, and attempt to set up an actual service in it, since I had an urgent use case for it. Then I discovered that the data model did not at all fit what I needed it.
It was designed with a simple structure in mind: You would define a template including the configuration necessary to build and tear down. Then you would define a form based on this template. By parsing the template, I would prompt the user for each variable type for later validation, and in the form data type, I would get human readable labels for each variable, as well as optional default values.
However, what if the service I was interested in spanned multiple nodes?
This data model was obviously flawed in this regard, so I decided to rewrite the whole thing.
It was also quite clear to me that I am today a much better python programmer than I was two years ago.
It has taken me about a day to code a REST only app that has the core functionality.
I have now functional backend code on Github, and I'm slowly working my way through the frontend code.
The new datamodel is a lot more flexible, but a bit more work is required as well.
The key part of this model is both the ManyToMany abstraction between templates and services, and the ability to instantiate one or many templates together with a node. This should give a lot more flexibility to create network wide configuration.
So far, I'm working slowly through it, and I have quite good test coverage, which is a lot more than I can say about the old code.
My plan is to follow up on this article as I make progress.
What's the goal?
The goal is not to be a new Ansible, or NSO or anything. The point is to have something that works on a simple and user friendly level. Something that transforms simple templates in to webforms and then in to configuration. Nothing more.