Too Good To Be View!

Welcome back to the series that focuses on applying the Model View Controller (MVC) software design principle, using the Django framework, to network automation using pyATS. In my previous post, we connected the Model, a PostgreSQL database table, to the Controller, a piece of Python code. And we introduced a View to present an HTML page with both a button and an input text box allowing users to trigger network automation.

This post focuses exclusively on a set of various Views, which are HTML pages that present to stakeholders a the network state PostgreSQL data in business-ready documents. The goal here is quite simple: to capture (done), transform (also done), and present network state (traditionally consumed via standard CLI output) to whoever needs it, in whatever format they need it in.

Planning

Here are the high-level plans, presented as pseudo-pseudo code, to outline some of the different ways we can make the data accessible to different stakeholders. Remember, we have both a PostgreSQL database full of rich network state data and a Pythonic way of accessing it easily in Django. You will not write a single SELECT statement with Django – it’s actually just another Python library call to access your database. One reason why I love Django is not only do I have this amazing Python-driven backend, but Django includes a templating language that lets me pass this PostgreSQL data into my HTML pages! With all this in mind, let’s build the following Views to liberate and democratize the state of the network.

In this article we will start with two fundamental functionalities – Enterprise Search and Network Change Detection.

• Search
  • Standard Search Engine – can we provide input boxes to users to let them search for fields in the network state database?
• Changes
  • Can we detect changes between the running / live network state and a set of records in the database?

Enterprise Search

Let’s start with Enterprise Search. This may sound challenging, but with the right Django tools, it’s actually straight forward. First, in our merlin/urls.py, we will include the path to a new self-contained search application with its own urls.py and views.py files respectively.

The urlpatterns we have set up include both a landing page (Search/) as a view (as_view()) with a name of search as well as the results page (Search/all_results). Next, we need to build these two Views in the views.py file in the same search folder.

There is a bit to unpack here. First, we have imported “TemplateView” and “ListView” from the Django generic views. We are also importing “Q”, which is a powerful “OR” operator (as in AND / OR), and our ShowIPIntBrief model.

The first view is the landing page for Search rendered from a Django template called “search.html”. The second view is rendered from a different template (the results template), and includes a function that takes the user’s query (self.reqeust.GET.get(‘q’)) input in the HTML page and then performs the search, or filter results, in a QuerySet against the PostgreSQL.

The results, meaning any positive “hits”, will be returned as an object list. This list is made available to the search_results_all.html template to present to the user. Let’s look at the two templates.

Recall that all of our Django HTML templates extend a base.html file which allows us to inherit scripts and logos and such downstream in all other templates. In my project you will see various bootstrap and data tables scripts—we’ll talk about their implementation shortly.

There is a direct connection here with the input name = “q” line and our View; again, the trinity relationship between URL / View / Template. This seems simple – and it is! Here is how this page renders.

A user then enters a search term. In this example it’s “105.”

The user’s search for “105” yields a hit in the Show IP Interface Brief Hits and is presented in a datatable – a fully functional, paginated, searchable, sortable, HTML table on steroids. We can use the buttons to reduce columns, copy to the clipboard buffer, generate a CSV file, Excel file, PDF file, or even send it directly to the printer, right from the Enterprise-grade Search results. This is what I mean by business-ready documents and using the power of parsed structured data to liberate and democratize network state data.

Network State Change

“What changed?” is easily the number one question in all of Information Technology in response to a problem. Using the power of a database we can capture the live running configuration of the network and compare it to a specific set of database records. In this case, for simplicity, let’s use the “latest” records as a benchmark. Again, just think of this as an SQL challenge more than anything, but we will use the Django Pythonic abstraction, and our trinity of URL / View / Template, to accomplish this.

For the sake of brevity, I use the same “button / text input” in my Changes to allow users to find changes for all devices or some / one device. There is a /Changes URL and a results URL. But the real importance here is the View and how we can perform this differential.

Again, the real magic is in the View above, where we first use the ShowIPIntBrief.objects.latest(‘timestamp’) as a filter to then perform a QuerySet, which records only the latest records (current_interfaces). Then, we trigger the pyATS job to capture and transform the data, and create a new set of records (latest_interfaces).

Because these are both QuerySets we can use Django’s built in .difference function to compare these records in both directions (interface_removals and interface_additions). We pass these differentials into the Django HTML template to be rendered for the user.

We are just getting started with Views. I wanted to demonstrate two very powerful, but relatively simple, functionalities we can provide the business and its stakeholders – Enterprise Search and Network State Change Detection – but there are many more Views to come. Stay tuned to this ongoing series!