I’ve written about hierarchical configuration in the past, (here). We intended to maintain it as an open source project, but we really did a horrible job of it. Soon, our internal version was very different than what was maintained on the public github.
We decided to give it another shot. This time maintaining hierarchical configuration as a installable library, available on pypi. We would then install hierarchical configuration as a requirement for our internal tooling. It’s a learning curve; our first attempt at truly maintaining an open source project.
In this post, I’ll go over installing hierarchical configuration and provide a basic example of how it’s used. In future posts, I’ll provide other examples of how to perform more advanced tasks with hierarchical configuration.
Hierarchical Configuration is a python library, which is installable via pip. It currently is supported on Python 2.7 and Python 3.6. Python 2.7 goes EOL on January 1, 2020. At which point, future versions of hierarchical configuration will be Python 3+ only, as we’ll likely implement python features that are only available in Python 3.
For this post, I’ll be installing and working with hierarchical configuration in a python virtual environment.
At this point, hierarchical configuration is installed, as is pyyaml, which will be used to consume the hierarcical configuraiton options file. For the sake of demo, I’ll utilize the test options and router configuration files from the hier-config github repository.
At this point, you should have a running_config.conf, compiled_config.conf, and a test_options_ios.yml file. These will be used for this demo. So, let’s start up Python IDLE.
The first thing that we’ll need to do is import the necessary libraries. These libraries are Host and HConfig from hier_config and yaml.
The Host object is used for creating a host object. A host object is a data structure that describes a host. For the purposes of hierarchical configuraiton, the data structure contains the hostname, os (operating system), and hconfig_options properties by default, but can be easily expanded on as necessary. Let’s create a host object.
At this point, a Host object has been created named host. Below is a bit of exploring the Host object.
Here is an example of being able to extend the Host object.
With the Host object created. We can now create a HConfig object and load a device running configuration into it.
With a HConfig instance created with the running config of host, we can create another instance of HConfig with the compiled config or intended config.
Now, this is where the magic comes in. We can let hierarchical configuration compare the running config to the compiled config and automatically create a set of remediation commands that will bring the device into compliance with the intended config.
Pretty awesome, right? That’s hierarchical configuration at its core. There are other features from getting granular with sectional exiting, command ordering, or idempotent commands; to targeting specific parts of configuration with a tagging mechanism. I’ll explain those in future blogs.
Hierarchical Configuration is on github, code documentation is available here, and you can ask question on networktocode.slack.com, #hier_config.