Nautobots, Roll Back!

Network Engineers know that working at the device CLI in a production environment can be stressful, depending on the device’s OS. On some operating systems, the changes you make at the CLI are live the second you hit <Return>. There is no opportunity for review, and in the event that something goes wrong, you must explicitly undo each change you made.

Conversely, there are some OSes that allow you to stage your changes prior to making them live. Juniper’s Junos is one example: you can make changes at the CLI, review the changes, and then deliberately commit the changes. In the event something goes wrong, you can quickly undo your changes en masse via a roll back operation.

Because your SoT data is the heart of your network automation, there is business and operational value to 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.

Nautobot running a Dolt database is for SoT data as Junos is to the production configuration:

  • it allows you to explicitly review your changes prior to pushing them to production
  • it allows you to roll back (undo) the changes if there is a problem

What Is Dolt?!

Simply put, Dolt is Git for data. Dolt marries MySQL databases and Git versioning; it supports clonebranch, and merge functions.

These Git operations on the database enable additional checkpoints prior to changing the production data.

Dolt Is Coming to Nautobot!

Network to Code is working with Dolt to enable Nautobot to run a Dolt database. Adding Dolt’s Git-style database versioning to Nautobot helps mitigate business and operational risk.

Review Data Changes Prior To Production Rollout

The data in your SoT is nothing short of a critical business asset because it enables your network automation. Having explicit review of any changes to SoT data adds a layer of assurance that the data will remain clean, and that business-critical automation that relies on clean data will remain operational.

Dolt’s Git operations allow users to create a branch to hold proposed changes. A user can make changes in the branch without affecting the production/master data branch. Each change is represented by a commit to the branch the user is working on. Once the proposed changes are complete, the user creates a pull request (PR) for review.

commits

The reviewer can easily view the specific changes; if the reviewer approves the changes, the branch can be merged to master. Only when the branch is merged to master will the changes be propagated to production.

diffs

Roll Back Data Changes If Necessary

Even with the extra assurance Git workflows provide, organizations need the option to quickly revert to the last known good state in the event that the new data has bad or unexpected results. Nautobot running a Dolt database gives users the option to quickly conduct wholesale roll backs, undoing parts of (or an entire) merge.

rollback

A Sample Workflow Comparison

With the above as context, compare the workflow for Nautobot running Dolt to a non-Dolt database implementation:

DoltNon-Dolt
Create new branch from Master———–
Switch to new branch———–
Make changes to dataMake changes to data (changes are immediately active)
Submit a PR* 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

The Dolt workflow is much more deliberate and has more built-in process safeguards than the non-Dolt workflow, protecting the integrity of the data.


Conclusion

In the coming weeks we will be releasing more information about this exciting new Nautobot app. Stay tuned!

Thank you, and have a great 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!

Author