Update Your Ansible Nautobot Environment & Helm Chart

Blog Detail

With the release of Nautobot 2.1.9 and 1.6.16 came new requirements for pynautobot to include an authentication token that for some initial calls that were not previously required. So to make sure that pynautobot (and subsequently Nautobot Ansible) and Nautobot Helm Chart work with the most recent version of Nautobot, new versions have been released.

pynautobot & Nautobot Ansible

First to check what version of pynautobot you have, you can run pip list to get that environment. Here is an example of using grep to only look for pynautobot.

❯ pip list | grep pynautobot
pynautobot         2.0.2

Nautobot 1.6 Environments

If you are continuing on the LTM release train of 1.6, your pynautobot needs to be upgraded to 1.5.2 in order to continue using the Ansible modules (4.5.0). No update to the Ansible modules is required-only the underlying pynautobot version. Complete this with:

pip install pynautobot==1.5.2

Accidental Upgrade to 2.x of pynautobot?

If you accidentally upgrade to the latest version of pynautobot but intended to be on 1.x, just issue the same command as above and you will get the right version. Nothing further would needs to be done-no harm.

pip install pynautobot=-1.5.2

Nautobot 2.1 Environments

For those with the latest Nautobot application version of 2.1.9, please upgrade the pynautobot instance in your Ansible environment to the latest of 2.1.1

pip install --upgrade pynautobot

Nautobot Helm Chart

First to check what version of Nautobot Helm Chart you have configured, you can run helm show chart nautobot/nautobot to get the full information about the configured chart. There will be multiple versions you will see in the output, the chart version that matters is the last line in the output and is a root key in the yaml output.

❯ helm show chart nautobot/nautobot
annotations:

... Truncated for bevity ...

sources:
- https://github.com/nautobot/nautobot
- https://github.com/nautobot/helm-charts
version: 2.0.5

Warning – READ BEFORE PROCEEDING

The latest version of the helm chart has a default version for Nautobot that is set to 2.1.9, if you are NOT providing custom image or statically declaring the version you WILL be upgraded to 2.1.9. For more information on using a custom image please see the documentation here or for using the Network to Code maintained images with a specific version please ensure nautobot.image.tag is set to the tagged version you are expecting to use. Below are some examples for values.yaml provided to a helm release.

If you are on a 1.X.X version of the helm chart please review the upgrade guide here before proceeding.

Custom Image

nautobot:
  image:
    registry: "ghcr.io"
    repository: "my-namespace/nautobot"
    tag: "1.6.16-py3.11"
    pullPolicy: "Always"
    pullSecrets:
      - ghcr-pull-secret

Network to Code Image

nautobot:
  image:
    tag: "1.6.16-py3.11"

Update Helm Repo

Before you can use the new version of the helm chart you must update the helm repo.

❯ helm repo update nautobot
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nautobot" chart repository
Update Complete. ⎈Happy Helming!⎈

Update Helm Release

Now you can proceed to update your helm release with the latest helm chart version.

❯ helm upgrade <name of helm release> -f values.yml --version 2.1.0
Release "nautobot" has been upgraded. Happy Helming!
NAME: nautobot
LAST DEPLOYED: Wed Mar 27 20:09:47 2024
NAMESPACE: default
STATUS: deployed
REVISION: 3
NOTES:
*********************************************************************
*** PLEASE BE PATIENT: Nautobot may take a few minutes to install ***
*********************************************************************

... Truncated for bevity ...

Conclusion

When issues do arise on playbooks that were previously working fine, it’s best to give your dependency software packages a quick update. Hope that this helps. Happy automating.

-Josh, Jeremy



ntc img
ntc img

Contact Us to Learn More

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

NTC Templates – Data Model Update

Blog Detail

The NTC Templates library has a major overhaul for the templates going on that is going to create the need for a major release. As part of the planning for the 4.0.0 release of NTC Templates, there is an updated set of data models that are being applied for network device templates. The project is moving to a single common data model, which will allow for the transformation of the data into a single model that is common across the various vendor textFSM template. This is going to make all of your data structures look the same whether you are using Arista, Cisco, Juniper, or other vendor CLI within your Ansible or Python automations. The planned release date is October 10th.

Thank you to Michael Bear who helped significantly spearhead this effort, with the full support from the NTC Team.

NTC Templates History

NTC Templates is one of NTC’s oldest and most popular open source libraries. It is used across many automations to provide a structured data format from CLI unstructured text. It is available and incorporated with many common tools used to automate networks every day, including the capability to use it with AnsibleNetmikoScrapli, and others.

There have been some changes over time, but overall, the library is the go-to place for taking unstructured CLI output and converting it into structured data for use in your Python applications (Ansible as well, which is a Python library).

Data Model

With the 4.0.0 release of NTC-Templates, many of the individual templates are being updated to a common data model for various components. Anywhere there is the use of VLANs, for example, previously you may have seen any of the following textFSM keys:

  • VLAN
  • VLAN_ID
  • VLAN_TAG
  • TAG
  • VLAN_NUMBER
  • VLAN_NAME

Now, each of these will be migrated into a single data model with VLAN_ID being anything that represents a VLAN numerical representation, and VLAN_NAME wherever a string identification of a VLAN is made.

The same can be said for MAC addresses and prefixes. With MAC addresses there were places that would just be MACMAC_ADDRMAC_ADD, and so on. The names of the keys are no longer going to be shortened. In sticking with the Zen of Python, these are going to be much more explicit.

What Do I Need to Do?

At this point, there are two options for being prepared properly. If you are writing your first automation applications, let’s move forward to 4.0.

Stay at 3.x

First, if everything is working well for you and you wish to remain on the 3.x templates, you need to make sure to pin your dependencies for the NTC Templates library to 3.x. If you are using requirements.txt:

ntc-templates>=3.0,<4.0

With poetry:

ntc-templates=^3

Update to 4.0

If you are looking to move forward to the common data model, you will need to update your automation applications and playbooks that leverage the keys. Take a look at the updated templates if you are working on Layer 1 – 3 components, such as VLANs, MAC addresses, and IP addresses. Put the automation through the paces and update as necessary for the keys.

Summary

The updated NTC Templates have had some strong updates over the years. Many contributions from the entire Network Automation Community. The move to this while somewhat painful at this particular time will reap many benefits to the years to come. This now will help enable automation capabilities such as:

  • Pre-post comparison of different device types
  • Comparison between different device types (including those from different vendors)
  • Consistency for new onboarded templates
  • Simplified downstream automations

Conclusion

Thank you, and let us know if you have any questions. In the #networktocode channel on the Network to Code Slack workspace.

-Josh



ntc img
ntc img

Contact Us to Learn More

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

Nautobot ChatOps Cookiecutter

Blog Detail

One of the biggest challenges when working on any project occurs right at the beginning—from getting the base framework to work all the way to the CI process once the main code is written. It can be daunting to have this on top of writing the actual code that is accomplishing the intended goal. Cookiecutter is a well-known project that can get you past this initial conundrum of “where should I begin?” It effectively creates a templated code repository that adheres to standards and best practices. This gives you a repeatable experience each time you start a new project.

Today we introduce the first NTC publicly available Cookiecutter project to help with the structure and framework for Nautobot ChatOps capabilities. Cookiecutter templates can help you get started writing code much faster, and the Nautobot ChatOps Cookiecutter project is a great example.

Nautobot Plugin ChatOps Cookiecutter

What is the value of this project? It is meant to get you started on your way of creating Nautobot ChatOps commands quickly. When running through the Cookiecutter template, there are a few questions that will help dynamically create content within the final “baked cookie” project. This will create a new repository that will be the new chatbot that you can then install into your Nautobot instance. For more on building your own chatbot, take a look at the blog post on Creating Custom Chat Commands.

What Is a Cookiecutter?

So, what is this Cookiecutter? It is a Python method of creating new projects/files from a templated base. Cookiecutter is an open-source command line tool to create projects from a project template. You can learn more on the Cookiecutter GitHub and ReadTheDocs.


Conclusion

What will your first ChatOps baked cookie be for?

For questions along the way, feel free to check out the #nautobot channel in NTC Slack.

-Josh



ntc img
ntc img

Contact Us to Learn More

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