Skip to content

Lab 09 - Discovering Extensibility

In this lab we will discuss a number of extensibility features within Nautobot, including the Change Log, Custom Fields, Computed Fields, Custom Links, Relationships and Export Templates.

Table of Contents

Lab 09 - Discovering Extensibility

Task 1 - Review the Change Log

When objects in Nautobot are created, edited or deleted, the changes are recorded in the change log.

Step 1-1 - Login via the web browser to Nautobot

If you have not already, use a web browser to navigate to your instance of Nautobot at https://{{ your pod }}. We will be using the Nautobot GUI for the remainder of this lab so there won't be a need for a terminal. Log into Nautobot by using the login option in the upper right of the Nautobot homepage. You can log in as the superuser you created in a previous lab or the superuser account included with your lab environment, the credentials for this account will be provided by the instructor.

Step 1-2 - Access the change log

From the Nautobot homepage, a list of recent changes is displayed in its own box on the right hand side of the page. Scroll to the bottom of the changes and click the View All Changes button to open the change log. The changelog can also be found under the Extensibility drop down menu.

Step 1-3 - Overview of the Change Log

The change log list default view has the following columns, Time, User name, Action, Type, Object, Request ID. If not all of these columns are of interest, the displayed columns can be edited using the Configure button in the upper right (just like all other list views).

In the upper left of the list the retention period is displayed, in this case it is set to 90 days.

When an object is created, updated or deleted a new change log object is created to track this change, this object is what is being referred to in the Request ID column.

image01-1

The change log doesn't simply store the information seen here in the list, it stores the actual changes to the object itself. Click on any link in the Time colum to be taken to the detail page for a particular change. In my example below, you can see the max value for a Min/Max rule has been changed from 25.0 to 15.0. The red area indicates what was removed and the green shows what was added.

At the top of the Difference box, there are Previous and Next buttons that allow you to move through the changes to the object in order to see how it was modified.

image01-2

In this example an object was created, which means there was nothing to remove.

image01-3

Step 1-4 - Update the change log retention period

Click on your logged-in username in the upper right of the page and select Admin.

image01-4

Click on Config

image01-5

Scroll down to Change Logging, update the value and click the Save button at the bottom of the form.

image01-6

Unlike other forms in Nautobot, after saving this form you will remain on the form page, however a confirmation banner is displayed at the top of the page after a change has been successfully applied.

image01-7

Task 2 - Custom Fields

Custom Fields are attribute-level data with which you can augment the existing data model. For example, say you needed to store a ticketing number along with each Device, so it can then later be correlated with an internal support system. This is certainly a valid use case, but not common enough to necessitate the addition of this field to the core Nautobot data models.

Step 2-1 - Add a Custom Field

Click on the Extensibility menu drop down and select Custom Fields. There are a few Custom Fields in the list, feel free to look at those if you like, we are going to create our own. Create a Custom Field using these attributes:

  • Label: Ticket Control Number
  • Slug: ticket_control_number
  • Type: Text
  • Weight: 100
  • Required: True
  • Move to Advanced tab: True
  • Content types: dcim|device
  • Validation regex: ^[0-9]\-[0-9]{5}$
  • Description: Enter the ticket control number for the group this device belongs to. The number must be in the following format 0-00000

Note that the slug for Custom Fields uses underscores instead of dashes. This is because the slug can be included in the REST API and GraphQL, so it needs to be a database-friendly name to work optimally with those features.

image02-1

Step 2-2 - Edit a Device and add data to the new Custom Field

Open the form to edit the attributes for one of your stadium Devices. Scroll down the form until you see the Custom Fields box.

Enter a valid value into the field and save the form.

image02-2

The field will not appear on the first tab of the detail page because we set the Move to Adavaned tab attribute to True. Click on the Advanced tab to see the new Custom Field value. It can be beneficial to put data here if most users will not need the value, especially if it is primarily read by other machines/systems.

image02-3

Task 3 - Computed Fields

Computed Fields function similar to Custom Fields but instead of a value provided by users, a Computed Field displays a data that is computed from other values stored within Nautobot and merged into a Jinja2 template. There is already a Computed Field in use

Step 3-1 - Create a new Computed Field for Circuits

Click on the Extensibilty drop down menu and select the green button next to Computed Fields to open the Add a new computed field form. Create a new Computed Field with the following attributes:

  • Content Type: circuits|circuit
  • Label: Circuit id-Type
  • Slug: circuit_id_type
  • Template: {{ obj.cid }}-{{obj.type.name | upper }}
  • Weight: 100

In the Jinja2 template the object is referenced using obj and its attributes are accessed through dot notation and field name. This is the same field name as noted on the CSV bulk import tables, and that we used on the Min/Max validation rule form. In the case of obj.type.name the name of a related object type is being referenced. At the end is a filter | upper which simply changes all the characters in that variable to upper case.

image03-1

Return to the Circuit list and select any circuit to see the new computed field.

image03-2

Step 3-2 - Update and existing Computed Field

Click on the Extensibility drop down menu and select Computed Fields. From this list click on Ansible Network OS to open the detail page, and finally, click on Edit to edit the Computed Field.

The Template for this field is using a series of if/elif statements to check for the slug of an object, and then return a string value based on that slug. The else section of the template is empty as is the Fallback value.

Update the template to include an else:

{%- if obj.slug == 'arista_eos' -%}
arista.eos.eos
{%- elif obj.slug == 'cisco_asa' -%}
cisco.asa.asa
{%- elif obj.slug == 'cisco_ios' -%}
cisco.ios.ios
{%- elif obj.slug == 'cisco_xr' -%}
cisco.iosxr.iosxr
{%- elif obj.slug == 'cisco_xe' -%}
cisco.ios.ios
{%- elif obj.slug == 'cisco_nxos' -%}
cisco.nxos.nxos
{%- elif obj.slug == 'juniper_junos' -%}
junipernetworks.junos.junos
{%- else -%}
unknown
{%- endif %}

Also, update the Fallback value to "Unable to render".

image03-3

After saving the changes to the Computed field, return to the Platform list (under the Devices menu) and click on PAN-OS to open the detail page for that Platform to see the updated value in the Computed Fields box.

image03-2

Custom links allow users to display arbitrary hyperlinks to external content within Nautobot object views. These are helpful for cross-referencing related records in systems outside Nautobot.

Let's create a button on the Tenant detail pages that opens a new window with a filtered list of Devices. Click on the Extensibility Drop down menu and select Custom Links. Create a new Custom Link with the following attributes:

  • Content Type: tenancy|tenant
  • Name: Devices filtered by Tenant
  • Text: {{ obj.name }} Devices
  • URL: https://pub11-pod01.cloud.networktocode.com/dcim/devices/?&tenant={{ obj.slug }}
  • Weight 100
  • Button class Info (aqua)
  • New Window: True

Custom Links allow for the use of Jinja2 so, we can create the link in a reusable way.

image04-1

Return to the detail page for the Nautobot Football Stadiums Tenant by clicking on the Organization drop down menu, select Tenants and then click on the Nautobot Football Stadiums Tenant. The new button will appear just above the Stats box on the right side of the screen.

image03-2

Click the button and a new window should open with the filtered list of Devices.

image03-2

Task 5 - Relationships

Sometimes it is desirable to create a new kind of relationship between one (or more) objects in your source of truth to reflect business logic or other relationships that may be useful to you but that haven't been defined. This is where the Relationships feature comes in: like defining custom fields to hold attributes specific to your use cases, relationships define specific links between objects that might be specific to your network or data.

Step 5-1 Create a Relationship

Click on the Extensibility drop down menu, and select the green button next to Relationships, to open the Add a new relationship form. Create a new Relationship with the following attributes:

  • Name: Circuits to Edge Devices
  • Slug: edge_device_circuits
  • Type: One to Many
  • Source type: circuits|circuit
  • Source Label: Edge Devices
  • Destination type: dcim|device
  • Destination label: Circuit
  • Destination filter:
    {
        "role": [
            "edge"
        ]
    }
    

This relationship will allow for multiple devices to be associated with a Circuit, but only one Circuit to be associated with a given Device. The destination filter will filter the Devices shown in the form and only Devices with an edge role will be displayed.

image05-1

Step 5-2 Associate the new Relationship with a Circuit and a Device

Return to the Circuits list by clicking on the Circuits drop down menu and selecting Circuits. From here, select the new Circuit we created in a previous lab, cox-123456789 to open the detail page for that Circuit. Notice that there is now a Relationships box.

image05-2

Click the Edit button in the upper right of the detail page, and scroll down the edit form to see the new Relationship field is available. Click on the drop-down menu in the field and only edge devices will be displayed. Click on an edge device for your new stadium and save the form.

image05-3

The detail page will now show that 1 Device is associated with the Circuit.

image05-4

Click the link to open the list of Devices associated with this Circuit via the new Relationship. The same Relationship will appear on the detail pages for Devices that have an Edge Device Role, but will not appear on the detail pages of Devices with other Device Roles.

image05-5

Task 6 - Export Templates

There is a green Export button on Nautobot list views that allows data to quickly be exported to a CSV file. It can be beneficial to control exactly what is exported, this is where Export Templates can help. Export Templates allow for the use of Jinja2 to control the export.

Step 6-1 - Create an Export Template

Let's create a simple Export Template that will export a text file containing specific Rack information. Click on the Extensibility drop-down menu and select the green button next to Export Templates to op en the Add a new export template form. Create an Export Template with the following attributes:

  • Content Type: dcim|rack
  • Name: Rack Site and Height
  • Template code:
    {% for rack in queryset %}
    Rack: {{ rack.name }}
    Site: {{ rack.site.name }}
    Height: {{ rack.u_height }}U
    {% endfor %}
    
    image06-1

Step 6-2 - Export and download using an Export Template

Return to the Racks list by clicking on the Organization drop-down menu and selecting Racks. From the Racks list, click on the small arrow that is now available next to the green Export button in the upper right of the page. Click on Rack Site and Height to download a text file using the new Export Template.

image06-2

Open the downloaded file to view the format generated by the Export Template.

image06-3

Task 7 - Dynamic Groups

Dynamic Groups are not an extensibility feature per se, but it makes sense to discuss them after covering the other models and filtering options.

Dynamic Groups provide a way to organize objects of the same Content Type by matching filters. A Dynamic Group can be used to create unique groups of objects matching a given filter, such as Devices for a specific site location or set of locations. As indicated by the name, Dynamic Groups update in real time as potential member objects are created, updated, or deleted.

Step 7-1 - Create a Dynamic Group

Click on the Organization drop-down menu and click on the green button next to Dyanmic Groups top open the Add a new dynamic group form.

image07-1

We are going to create a group of all edge devices in the Nautobot Football Stadiums Tenant. Start by creating a Dynamic Group with the following attributes:

  • Name: Edge Devices
  • Slug: edge-devices
  • Description: Edge Devices in Nautobot Football Stadiums
  • Content Type: dcim|device

Note that the Filter Options are currently unavailable. We cannot add filtering options until after the Dynamic Group is created.

The detail page for the new Dynamic Group shows that no filtering has been applied and all 439 Devices are part of the group.

image07-2

Click the Edit button to return to the Dynamic Group form and scroll down the Filter Options. Inside Filter Options are the Object Fileds. Set the Role to edge and the Tenant to Nautobot Football Stadiums and save the form.

image07-3

The detail page for the Dynamic Group now shows only 11 Devices, click on the tab to see the list.

image07-4

Step 7-2 - Use Child Groups for more complex filtering

Using the same procedure, create two new Dynamic Groups with the attributes below. This will require the forms to be saved and then re-opened.

  • Name: AUS01 Devices
  • Slug: aus01-devices
  • Description: Devices at the AUS01 Site
  • Content Type: dcim|device
    • Object Fields:
  • Site: AUS01

  • Name: Leaf Devices

  • Slug: leaf-devices
  • Description: All Leaf Devices
  • Content Type: dcim|device
  • Object Fields:
  • Role: leaf

Next, create a new Dynamic Group with the attributes below. This will require the form to be saved and then re-opened.

  • Name: AUS01 Leaf Devices
  • Slug: aus01-leaf-devices
  • Description: Leaf Devices at the AUS01 Site
  • Content Type: dcim|device
  • Child Groups:
  • Restrict (AND) - AUS01 Devices
  • Restrict (AND) - Leaf Devices

image07-5

On the detail page for the new Dynamic Group, the Related Groups has been updated, and the total Group Members for each group are listed. We set two AND conditions for the filter, so for a Device to appear in the Dynamic Group AUS01 Leaf Devices, it must also be a member of Leaf Devices and AUS01 Devices. Using child groups for this particular example wasn't strictly necessary as we could have simply added more filters to AUS01 Leaf Devices, but the idea is to keep it simple and show how child groups work.

image07-6