In the past few months, many of us here at Network to Code have been investing a lot of time with Nautobot Version Control. The ultimate goal with adding version control to Nautobot is to make network automation safer by bringing proven Git– and GitHub-like workflows directly to Nautobot.

Along the way, we’ve created a lot of content in order to showcase how the version control capability can benefit Nautobot users and those looking for safer ways to manage data. This week’s post serves as an aggregation for all the Version Control related content to date.

Below, organized by content type, are hyperlinks to each piece of content that has been produced over the past few months.

Code and Documentation

• Version Control repository
  • This holds the open source code for the Version Control integration.
• Version Control documentation on readthedocs.io
  • These are the official docs for the integration.

Blogs

• Database Version Control with Nautobot
  • This blog discusses the value that Version Control brings with its Git-like workflows and how those workflows fit into existing Nautobot capabilities to keep network automation data clean.
• Nautobots, Roll Back!
  • This post discusses the business and operational value in allowing users to review changes to SoT data prior to pushing them to production, and then to quickly undo that set of changes if needed.
• Keeping Data Clean with Nautobot Config Contexts, Schemas, and Git
  • This post is not Version Control related explicitly, but it does discuss Nautobot features you can leverage that complement the Version Control workflows.
  • These features, especially when paired with Nautobot Version Control app workflows, provide a layered, defense in depth to keep your automation data clean.

Videos

• YouTube Version Control playlist
  • Intro Series: This series of videos introduces the user to the Version Control with Nautobot, its use cases, and how to use the app.
    • Unit 1: Defining the problem at hand
    • Unit 2: Bringing version control to Nautobot’s database
    • Unit 3: Navigating the top-level Version Control menu
    • Unit 4: Managing pull requests with Version Control
  • Demo Series: This series of videos provides demonstrations of how to set up a demo instance of Version Control with Nautobot, workflows enabled by it, and how to interact with Version Control programmatically.
    • Unit 1: Setting up a demo environment
    • Unit 2: Version Control enabled workflow demo
    • Unit 3: Version Control: Jenkins CI pipeline added
    • Unit 4: Using the Version Control API

Our Nautobots, Rollback! post in late August introduced the community to Dolt databases and the workflow Dolt databases enable in Nautobot. Dolt is enabled in Nautobot via the Version Control app. This post will discuss the value that the Version Control app brings with its Git-like workflows and how those workflows fit into existing Nautobot capabilities to keep network automation data clean.

Data Hygiene

In a network automation context, clean data is correct (error-free) and properly formatted to be usable by the automation.

A process to achieve and maintain clean network automation data would have these general steps:

• Have more than one set of eyes on the data and/or checks and balances prior to adding/removing/changing data
• Get data into a consistent structure/format
• Ensure the ability to remove bad data

As a practical matter, no single magic bullet exists to perform all these steps: clean data requires a multi-tiered approach. The Version Control app adds value because it enables Git-like workflows for changes to production data.

Version Control Workflows Enable Better Data Hygiene

Nautobot running a Dolt database brings Git-like workflows to Nautobot, allowing a more collaborative process to get changes to network automation data into production. This collaborative process includes explicit checkpoints for review, discussion, and approval of changes to production data.

The Nautobots, Rollback! post introduced the comparison below, contrasting a Dolt-enabled Git-like workflow for database changes to a non-Git-like workflow.

Version Control’s Dolt database brings capabilities and workflows that were previously not available in database-backed solutions.

There are two main benefits provided by the Dolt-enabled workflow:

1. It creates an explicit checkpoint for data review prior to merging changes to the production data.
2. If there are problems with new production data, a user can quickly and easily roll back parts of the merge, or do a wholesale rollback of the entire merge.

The Git-like workflow results in cleaner production data and allows for troublesome data merges to quickly be undone.

Both the conversations around and reviews of pull requests help ensure clean data enters production.

Being able to quickly and easily revert data changes in part or wholesale reduces the time required to fix mistakes.

Programmatic Access

As is true with any automation-centric platform, the Version Control app has extensive REST API capabilities.

Branch-Specific Data

The Version Control app allows multiple branches to exist, and it will often be necessary to programmatically query a given branch for information. This app allows programmatic REST queries for data in specific branches via the dolt-branch keyword in the header.

Here is some simple example code that queries the cdg-edge-augment branch for all devices with an edge role in the cdg site:

import requests

from pprint import pprint

url = "https://internal-dolt-server/api/dcim/devices/?site=cdg&role=edge"

payload={}
headers = {
  'Authorization': 'Token nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn',
  'dolt-branch': 'cdg-edge-augment'
}

response = requests.request("GET", url, headers=headers, data=payload)

pprint(response.json())

Here are the results (heavily edited for readability!):

{'count': 3,
 'next': None,
 'previous': None,
 'results': [{
          ---<snip>---
              'display': 'cdg-edge-01',
          ---<snip>---
              },
             {
          ---<snip>---
              'display': 'cdg-edge-02',
          ---<snip>---
              },
             {
          ---<snip>---
              'display': 'cdg-edge-03',
          ---<snip>---
              }

Here are the results of the same script, but with the 'dolt-branch': 'cdg-edge-augment' header info removed:

{'count': 2,
 'next': None,
 'previous': None,
 'results': [{'asset_tag': None,
          ---<snip>---
              'display': 'cdg-edge-01',
          ---<snip>---
              'virtual_chassis': None},
             {'asset_tag': None,
          ---<snip>---
              'display': 'cdg-edge-02',
          ---<snip>---
              'virtual_chassis': None}]}

The cdg-edge-augment branch has an additional device (cdg-edge-03) that the main branch does not.

Version Control-specific API Endpoints

The Version Control app also has specific API endpoints for querying the following:

• Branches
• Commits
• Pull Requests
• Pull Request Comments

Test Drive the Version Control App Youself!

This app is still very much in the development phase and is not officially supported (as of the writing of this blog), but you can still test-drive the current functionality in a dev/test environment. The public repo is available on GitHub. There, you will find instructions for setting up the dev/test environment.