Database Version Control with Nautobot

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.

DoltNon-Dolt (PostgreSQL/MySQL)
Create new branch from Master———–
Switch to new branch———–
Make changes to dataMake changes to data (changes are immediately active)
Submit a pull request for review———–
Review changes———–
Refine changes based on PR feedback———–
Deploy changes deliberately (Merge)———–
Assess changes to production environmentAssess changes to production environment
If there are problems, immediately roll back to last good stateIf there are problems, undo the changes manually or via external automation

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.

pr-conversation

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

revert-page

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
Version Control-specific API Endpoints

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.


Conclusion

Keeping network automation data clean is important because it affects how well the automation can implement desired network state. Nautobot’s innovative Version Control app provides another layer of data protection to Nautobot’s existing data-protection measures to keep your network automation data clean.

Thank you, and have an awesome day!

-Tim



ntc img
ntc img

Contact Us to Learn More

Share details about yourself & someone from our team will reach out to you ASAP!

Thanks for submitting the form.

Author