Skip to content

🏠 Home#

GraphQL - Aliasing

One of the features that I find myself using periodically that I think is underrated as far as using GraphQL is its ability to alias return keys in the response. This can be extremely helpful for developers writing applications, as it allows them to have the API response with the keys they are looking for. I have found this feature particularly useful when working on applications like Meraki and Nautobot together. In Nautobot a place is typically defined as the key site. In the Meraki world this is commonly set up as a network. Without GraphQL's alias feature, the developer would need to translate this data over.

Let's explore two scenarios where a developer might choose to alias the response from GraphQL:

  • Quick translation between systems
  • Response from multiple queries

I will demonstrate the capabilities of these scenarios using the Nautobot demo instance at https://demo.nautobot.com. For each of these, make sure that you have logged in already before going to the GraphiQL page.

Automation Inventory

This is a topic that I'm fairly opinionated on as of late is looking at what should be maintained within an inventory and the strategy of how to set up the inventory.

For the case of this blog post, I am going to use the term playbook to represent the automation being run. This is yes an Ansible term, but also apply this as your automation run that is using Nornir or any other automation framework.

  • 3 min read

DevNet Expert - Starting Point

This week Cisco announced the DevNet Expert certification exam. This exam and certification is something that I have been looking forward to for a long while. Dating back to the announcement of the certifications that were being provided. This was announced at Cisco Live 2019 in San Diego. I had started to lose some hope that this would become a reality with how long of a delay from the initial announcement to the announcement of availability. But it is now here. So here we go.

  • 8 min read

Nautobot Jobs - Your Custom API Endpoint

One of the best features of Nautobot as a Network Automation Platform is the ability to create your own custom code. This is executed via a job. What makes Nautobot unique is its ability to integrate with a Git repository to get those jobs and code for use into Nautobot. This provides perhaps the simplest, authenticated, and logged methodology for building your own API endpoints.

Nautobot supplies an API endpoint to start execution of jobs. The big deal about why you would want to do this inside of Nautobot (even if you do not have any other data inside of Nautobot, but you should add data, it is a perk) is that you get an authentication mechanism with the Nautobot token setup and a logging mechanism. With Nautobot user accounts you can create tokens that will handle the API authentication. This is helpful that you do not need to add that into your own Flask, FastAPI, or Django application yourself. This is the same for the logging mechanism. Every job execution provides a log of the execution and the result.

  • 2 min read

New Book - Open Source Network Management

Earlier this month I was able to hit the publish button on a new book - Open Source Network Management. The book dives into getting started with several open source network management tools. It is meant as a guide to help further your experience with using and installing open source tools, all on a single VM/host. The size of the host is meant to have minimal capital investment, in the way of a single NUC or a minimal VM deployed on a hypervisor in your environment.

The book is published on LeanPub, which is a publish early, publish often marketplace. The book is digital only, with PDF, ePub, and mobi formats available. Currently the book is indicating 80% completeness, with most of the technical content in place already! There are mainly soft edits in this early version.

Nautobot Ansible Collection: Devices

All of the work through the modules thus far in the series have brought us to what we all want to see. How to get or update device information inside of Nautobot. Adding of sites, device types, device roles are required to get us to this point. Now you can see how to add a device to Nautobot using the networktocode.nautobot.device module.

There are many optional parameters for the module specifically. I encourage you to take a look at the module documentation (linked below) in order to get a good sense of all of the options available. The required parameters for a device that is present are:

  • device_role
  • device_type
  • name
  • site
  • status

An important caveat for me is that this is something that should be done with rarity. Only when truly adding a device to Nautobot, in a programmatic way this should be used. I do not advocate for running this module constantly based on your devices. The idea is to get Nautobot to be your source of truth about devices, not to have devices be the source of truth and updating Nautobot.

So where do I see this being run? I do absolutely see it being a part of a pipeline or a service portal. The idea being that the service portal has a request for a new site to be turned up. That in turn kicks off an Ansible Playbook that will make the necessary updates to Nautobot, and is done in a consistent manor.

Nautobot Ansible Collection: Device Types

A device type is the next piece in the Nautobot Device onboarding requirements. The device type corresponds to the model number of the hardware (or virtual machine). This is where you are able to template out devices during their creation. So if you have a console port on a device type, that console port will be created when you create the device. However, there is NOT a relationship built between the device type and the device. If the device type gets updated after the device is created, the device itself is not updated.

Nautobot Ansible Collection: Device Roles

A device role is aptly named, the role of the device. This is likely to be something that is meaningful to your organization and could change. For example you may have the 3 tier system of Core, Distribution, and Access layer environments. These are just fine. So you would want to have the roles there to reflect this reality. You may have leaf-spine environments, there are two more roles. And in my past I have also had roles that would indicate that there are dedicated DMZ, WAN edge, Internet edge devices. So this is the place to set this.