Nautobot Next: Foundational Features, Built for Scale

Hello, welcome everybody as we get joined in here for our webinar today. Glad to see you all here. Just uh we’re going to give it a minute or so as we wait for everyone to join. It always does take few seconds for everyone to join in from the waiting room. So looking forward to having a great webinar with you all today. Good to see so many of you out there already. Uh we do have a kind of a fun thing for you all today which will be a little poll here to get us started.

So uh while we’re waiting for folks to join, if you could please um go ahead and help us with this poll and then uh we’ll kind of see how the responses are from the group as uh as folks start to take it. So um for those of you just joining, please do uh fill out this webinar poll that we have here as we wait for everyone to get joined into the room. Uh we’ll get started in just about a minute, but uh this way you have something to do while we wait.

should be uh interesting to see the results from the group here which is uh where are you in your Nautobot journey today uh maybe you haven’t installed it at all maybe you have installed it but just getting started are you actively using it but just in your lab and and then maybe you actually have it in production and then finally like are you using any custom-built apps or other uh plugins that you might have had so I’m just kind of curious to see general consensus from the group where we’re at here and uh just waiting for those to join in and And for those of you just joining, please uh do give us an answer on the poll.

That’d be really great for us. Uh something interesting to get here from the group as we get started. Okay. Uh going to go ahead and get started on the webinar and we will look at the results but just in a minute here. But uh as we get started here, we’re going to be going over our is part of our Nautobot Next series today. The uh foundational features and and the fact that Nautobot is really built for scale. discovering how to make the most of Nautobot’s native capabilities to accelerate your automation journey.

Uh we’ll do some introductions and then we’re going to talk about the uh object features within Nautobot, the API features, our pre-built jobs uh that come with Nautobot core and then the idea of git repositories and how those are linked into Nautobot and then of course Q&A. Uh as always, please do use uh the reactions. It’s really helpful for us to be able to understand uh parts of the uh webinar that you’re responding to or you’re finding interesting. So, use the reactions. They’re down there on the bottom depending on where you have your Zoom bar.

Uh but you can let us know, you know, things that you’d like or things that you find interesting. As well as um also just a reminder that we do have the chat disabled. So, please use the Q&A box for any questions that you have for us. We love getting your questions. It’s really helpful. Uh so please do use that uh as well and that way we can make sure we get you answered as well as share your question with the group.

Uh so again for those of you that maybe have just joined if you could please uh give us an answer on the webinar poll that’d be great. Um as we get started here uh so my name is Tim Schreyack uh and I am the director of strategic transformation here at network to code. So I work with our clients helping them to understand of how we can use uh NTC services and Nautobot to really enable your business uh which is that is how do we link the technology to drive the business and make sure that everyone within the business is able to leverage that technology uh as well.

So that’s uh my purposes here and we’re going to go through the webinar today as well. Uh so let’s go ahead and look at those results and see how we did uh as we uh got all the answers either in from the group. Uh so you know great to see the the responses coming in here. So uh you know and I’m looking at this live with you all as well. So uh we have here just looks like you know most of them you’ve installed Nautobot um but just getting started.

Uh and then from there we have a significant group that hasn’t installed Nautobot uh but is uh you’re interested in exploring. So interesting to see here. Um as well as we do have a fair number of you that are actually using uh custom apps and plugins. So that’s also really cool uh that uh we have such a good amount of the group here really uh actively engaged with Nautobot. So um welcome to everyone.

Uh hopefully you’re going to find some really uh great things here no matter where you are in the journey today whether you’re just exploring or all the way up to building your own custom apps. So uh great to see that there as well. Uh so let’s go ahead and uh get into our webinar for the day and uh we’re going to start off with the object features of how you can tailor your Nautobot experience with the the capabilities within the platform.

Uh so here uh let’s take a look at some of the features that help to empower flexibility and customization. Uh really is how can we take your management strategy up a level. So first there’s the idea of data organization and access. Um these are features designed to allow users to organize network data in ways that will fit you know your specific needs. Uh we have data automation and efficiency. So these are features designed to allow our users to ac uh automate the way they generate and manage data exports and integrations from NTA.

Uh then we have the ability to uh customize to unique workflows. These are our features which allow users to really tailor the data model uh to match specific needs. Um this is a really uh useful concept and really one of the core bits of Nautobot is that Nautobot can really fit fit this uh capability within your organization to be basically an orchestrator of orchestrators. That is how do I uh stitch together all of the different systems and products and tools that you might have within your business and not can fill that gap.

Uh looking at its extensibility and scalability capabilities. really designed to evolve and grow with your business environment. Uh we have uh clients that are using Nautobot today that you know anywhere from hundreds of devices all the way up into hundreds of thousands of devices. You know our very largest clients are using 500,000 devices plus in Nautobot platforms. The Nautobot platform is very extensible and very scalable. Uh and then our usercentric design really the idea here is to empower our users to to work the way you want.

uh so that you can have straightforward customizations whether it’s for newcomers or you know deep custom uh customizations for for advanced users. Um the idea here is really to be a very flexible platform and to allow you to adapt the platform to the way you do business um as opposed to the other way around. You know sort of a lot of the off-the-shelf products expect that you adapt to it. Uh and our goal here is to really make sure the platform can work for you and what you need. Uh so let’s start off talking a lot a bit about custom fields.

Uh so storing data that’s unique to your network. So while of course the data model within Nautobot core is very very extensive and can match probably almost anything you have in your environment there are occasions where you need to create specific custom fields uh because there’s something special in your environment that we haven’t thought of or that isn’t common uh and therefore is not in the core data model. Uh so this is the capability to add a custom field very easily from the UI as you can see here in the screenshots.

Uh and it’s something that we can do uh anywhere we want in the database. So that is you can add a custom field to any component of the database that you would like and it is a full first class citizen. Uh that is it is not uh relegated off into some side area where it’s not accessible by the API maybe for example uh or available in a job. No, not custom fields are full first class citizens. They’re available via the API. They can be used in a Nautobot job. They can be used just like a native core model field.

So there’s no difference from a using uh perspective or even the way they’re stored in the database uh between a custom field and something that’s available as part of the core model. Uh so this is really gives you a lot of flexibility to adapt the uh fields that you store to things that you might need. Uh so again uh just something that’s available for you here. You will find this under the extensibility uh menu section as you can see here on the left hand side of the screen and it’s going to be custom fields.

We can add that and then assign out uh what type of content it contains and where it should be and then even for you there’s some some basic validation that you can do here right as you create it uh that you might want to set on that custom field. Uh this is one of the the key elements of the concepts within Nautobot is this idea of data validation and data integrity always important. We want to make sure that we have good data in the database. Um because invalid data is worse than no data, right?

So we want to make sure we use these fields where possible so we can have that idea of uh good clean data in our database. So let’s take a look at how we might actually use them and how they show up. So here we can see on the uh device object page uh we’ve got two uh newly added uh custom fields that let’s just say we created and um we can see you know as an example here we’ve got you know these values in it and of course if if a user were to enter in some values for them and we had put those uh maybe a reax rule on there and the uh the user is trying

to enter some data that does not match that reax um it will not be allowed and you will get a warning message indicating that the value does not match the uh data integrity rules, data validation rules, and therefore it’s going to be rejected. Uh now, this applies regardless of how you try to enter the data. Um it doesn’t matter if you use the uh UI like uh we might see here in the in the in the webinar uh or uh perhaps via the API.

Maybe you’re trying to send a REST call and try to enter some data that doesn’t match that data validation uh rule. uh it will also be rejected and a message will be returned uh via the API indicating that um it has been rejected because of that data validation failure. Uh so it doesn’t matter how you try to enter it, it’s not going to be allowed if it doesn’t match the validation rules. So uh really great there way of making sure that we begin to filter out and have good clean data all the time being entered in.

Now let’s talk a little bit about our computed fields uh as opposed to custom fields, right? uh this is how can we use uh ginga templates to populate attributes dynamically into Nautobot. So the idea here is that we want to be able to say combine uh two other attributes or fields uh within the Nautobot database most likely um and and build those into a single field. So uh unlike a a custom field where we’re storing static data uh computer fields are rendered dynamically.

So uh we can have different use cases here where this might make sense whether it’s uh you know maybe creating a human-friendly label uh to easily consuming you know metadata. Uh so again we’re going to go under the extensibility menu and we will find that just below the custom fields here we have computed fields.

Uh so this could be really useful I think you know particularly if you have uh some standards in your environment for perhaps uh port descriptions uh or device names that uh include building those uh fields from a collection of other fields. Uh so here in a case we’re looking at something where hey we want the name of the thing and the serial number of the thing you know maybe that maybe that’s the host name of the device maybe that’s your standard uh or if you were thinking of port descriptions on interfaces right you might also do something uh similar to this where you’re perhaps using a series of of existing fields in order to build that.

And so then rather than having to manually enter that we can just dynamically create it here. Uh the idea being here so that now we’re not having to do things multiple times. We’re in ensuring consistency uh and getting uh good clean data all the time because we don’t have to actually enter this right. So we don’t have to worry about people making a copy paste error or perhaps you know not following the appropriate standard. We’re just doing it for them. Right?

So really easing our lives as well as driving consistency and clean and clean data into our environment. Uh really really useful uh concept here. And if you’re not using this today, for those that maybe are are using Nautobot already in production or um you know even going into the custom uh custom objects, uh this is a great thing to add into your repertoire as you look at it. Now uh so let’s see I just have a couple of questions here coming in while we’re talking about custom fields.

I think kind of interesting to discuss you know are hey are the custom fields uh added to Nautobot accessible to network monitoring tools also? Absolutely. So anything that we create in Nautobot is available via the API or the GraphQL endpoints. Uh so yes, custom fields are full first class citizens. There’s no difference between them and any other field in Nautobot. Uh does not allow the creation of custom nested fields to specify nested details. Uh I’m not sure I quite get the concept of what you’re trying to achieve there.

Uh so AJ, if you could uh maybe just give us a follow-up there, maybe explain a little bit more about what you’re looking for on those details. Try to answer that for you. Uh but uh yeah, that I’m not quite sure what you mean by the idea of nesting the fields. So just give me a little more details there on what you’re looking for and I’ll try to get that answered for you. Okay. So uh carrying on with the computed fields as we think about them in action, uh they as we start to use them, right?

Here’s an example of that one that we just had where we were taking the name and adding in that uh serial number at the end there. Right? So again, we’re seeing it here uh right as part of that uh device page in this example. Uh so and you know we did kind of shorten that that screen cap there. So it is a little bit easier to see that. Um but it would be it will be on the uh device page where you’ll see the computed field section and you can see where they are.

uh some ideas, you know, of things that you might use them maybe, you know, for device age or warranty status, you know, interface summaries, uh any number of cases where these might be useful. Um and as you start to think about the possibilities, you can see, you know, a lot of times in our environments, we have uh fields where we build them from a series of other fields. Uh so this is a great way to take advantage of that within the database um and be able to leverage this concept.

Now tags uh simultaneously one of the single greatest uh concepts within Nautobot or any other database and also one of the worst concepts. Uh and that is simply because they are so powerful and yet so flexible. Uh so we want to be really careful with how we use tags and how we create them. Uh because what happens with tags inevitably uh as soon as you have more than one person creating tags, you’re probably going to have duplicate tags.

um and or we will have situations where someone creates a tag where one person did it with a capital letter and the other person did it with a low a lowercase letter, right? For example. Uh so we want to be really careful with how we create tags, who’s allowed to create them and how we use them. So always keep that in mind. Tags are incredibly powerful and they’re also really really dangerous depending on how you use them.

Uh, so we want to make sure we’re super careful with them, but they absolutely provide a tremendous amount of power and flexibility with how we can put in metadata within Nautobot. So they’re perfect for categorization, uh, allowing us to filter results or filter the data that we want to pull back when we’re creating a query.

um you know particularly when so let’s say uh you know a native field doesn’t match your specific use case or maybe you want to flag uh you know uh something as like an NTP server for example or your your collection of NTP servers you might assign a tag to an IP address for example right that say hey this is my NTP server might be one use case uh so there are different ways in which you can use tags um again super flexible uh and that’s probably the greatest thing about them um and also the worst thing about them at the same time right uh so really uh powerful here for you.

Uh and always keeping in mind as you’re creating tags, pay attention to that content type. Sometimes this can catch you up uh where you know you created a tag and then you go to try to use it and you’re like, “Hey, it’s not it’s not available to me. Why?” Uh probably because you forgot to select the appropriate content type when you created that tag. So if that happens to you, just don’t forget, go back, edit that tag, and then add in whatever content type that you’re trying to use the tag on.

Uh so that you can make sure that it’s available to you. Um you know, don’t don’t go go create a new one. you’re just going to make that problem worse, right? Um, so always double check that, right? It might just be that you forgot the content type. That’s pretty common there. And also kind of interesting here, right? We can also use tags with dynamic groups. Um, so pretty interesting idea there as well. And we’ll just talk about dynamic groups here coming up shortly. Okay. And exactly. Let’s move into the dynamic groups. Perfect segue there.

So, uh, tags, amazing better dynamic groups. A lot of times the reason you’re creating a tag is because you’re trying to group uh a series of things and you want to be able to filter on that. So you want to say hey give me all the as I used earlier the example give me all the NTP servers and you want to just pull that via the tag. Well there’s a better way and that’s with a dynamic group. Dynamic groups are a lot more controllable. They are less of the let’s say wild west if you will like a tag is.

Um and you can achieve similar concepts but in a better way with dynamic groups. If you’re not using dynamic groups today and you’re an advanced uh Nautobot user, take a look at them and definitely start thinking about how you might use them because I’m sure you can use them in your environment. These are really powerful. Virtually everyone that starts to get more advanced into Nautobot using dynamic groups at some point. Uh they give you a way to group objects together automatically based on the filter criteria.

Um so now I no longer need to manage the membership of this group by hand. So essentially what that means is if I add a new device or some new object in the database that matches the filter type set for this for this dynamic group that object will automatically become a member of the dynamic group. So think about that right let’s say here in this example we’re saying we’re going to create a dynamic group that’s going to be able to tell us all the lab equipment. So here you can see the content type. We set it to be a device.

Uh and we’re going to create a filter that’s going to uh pull in any device that belongs to our lab. Uh so now uh instead of having to you know maybe use a tag or maybe use a location because maybe maybe you don’t have a you know good consistent location uh we can now just pull on this dynamic group and we’re going to get all the devices belonging to the lab in this example. Right?

So really powerful way here to uh set up this concept of using groups to be able to get back all the things we need um in perhaps whether it’s rendering configuration or whatever the case may be. Uh so to create a dynamic group you’re going to go under the organization uh menu tree and go to dynamic groups. Um and of course you you can hit the little blue plus sign there and we’ll be then be able to start adding in all of the details around this particular group. uh and we are going to need to specify the filter, right?

That’s the the key part of the uh concept of the dynamic group. That’s how we’re determining who belongs to uh the dynamic group. And of course, as you can see here, we can also nest them, right? So, we can have child groups underneath our uh parent groups as well. Uh and we can filter on things like uh RO or site status or any combination of those things. Basically any filterable field uh we can use as the way that we create uh that uh filter to extract data into or to extract who belongs to the group.

Uh and again you know this is not like a static group where you statically define it and then you have to manually maintain that. You maintain membership of the dynamic group by appropriately creating your filter and then members into the group automatically get uh populated in as required and it is instantaneous. a new member uh joins the database that that matches the filter, it will immediately become a member of the dynamic group. So there’s no delay in that whatsoever.

So again, taking a look at what they uh look like as we start to use them. Uh here’s you know an example of uh a group that we created and uh any device that is added to our Jersey City uh location which is our lab will also be part of the lab equipment dynamic group. So we can see here here’s that filter where we set that uh Ginga filter here setting the location and if it matches Jersey City um it will become a member of lab equipment. Now as you think about this uh what’s cool here right is you can set more than one thing as your filter.

Uh so you have a lot of power here, right? Perhaps your loc your lab is is located in multiple uh locations. Uh and so which case you might have a list of of locations here rather than uh just one. Uh or there might be some other criteria that determines that uh it belongs to the lab, right? So you could uh list that out here as well. So not only just the location but also something else might be available or might be required in order to appropriately uh set the uh membership within to the group. So you have lot of flexibility here.

or how you might use that. Uh and then we can also use uh dynamic groups uh to in to initiate uh automations based on that group membership. Uh you know perhaps uh we have a maintenance job which uh executes against our uh access switches which are in the active state you know for example. So then uh we can now say hey we want to get all the access switches that are in the active state and we’re going to and then we’re going to go run some maintenance against them for ha perhaps for example right so lots of flexibility how you can use the idea of a

dynamic group as a filter to uh run you know a job against as a perfect example of how you might use it so lot a great great feature here really practical in the real world uh if you are not using it today take a look at it um I’m I’m sure you will find a way in which it makes sense to use in your environment and will make your life easier and better. Yeah. Saved views. Um the idea here is, you know, hey, not a robot should adapt to what you and your users and your community within your organization require.

Uh so we want to be able to enable you to not only do that and doing things like custom fields and computed fields, um but also to be able to save the views within the UI on a per user basis. Uh so here we’re able to uh you know basically save however we like to see and interact with Nautobot because different users have different uh use cases and you know maybe there are some things you care about and some things you don’t care about.

Uh so we can adapt that uh because you know quite often especially depending on your role there’s only going to be a certain subset of device attributes that make sense for you. You really don’t care about the rest of the stuff. It’s just cluttering up your screen um making you scroll left and right or up and down way more than you wanted to. Um, so we can save those views uh here and and and then you not have to uh keep looking at or redoing that every time we come in.

Uh we can store uh search filters uh column selection, our sorting preferences and our pageation settings all within the saved view. Uh so to create a saved view uh first we’re going to go into any object table in Nautobot. anywhere within Nautobot essentially where you’re seeing a list of something uh would be an object table and you’re going to uh refine your view to however you prefer it.

Uh and then you’re going to uh open the drop-own menu here at saved views and you’re going to go to save as a new view and give it a view name and hit save. It’s really that simple. Uh these are going to be user specific by default. Uh so everyone can have their own you know personalized experience but you can also enable the is shared checkbox here if you want to share it with others right so uh perhaps uh maybe the uh DC ops team has a view they would like and so one of the DC op members or or maybe you know you as a as a manager of Nautobot and

create a view uh that should be shared with all of the DC ops folks or you know likewise maybe the tier one or you know what have you right you might have different views that make sense for different teams so we and share those. So then people don’t have to go recreate that wheel. Um they can just you know easily use that that uh saved view as well. So helps you uh you know reduce friction, little bit of toil saved there uh and get you focused on on what you need to do in order to do your job. So really powerful concept there.

Sometimes it can be easily missed. Uh we can forget about that. So we just wanted to remind you hey you know you have this really cool idea of using save views. Um so here’s just an example of what that might look like. Uh so you know here you know at the top of the screen we see what uh you know the circuits uh screen looks like normally by default and it’s got a whole bunch of stuff and you know maybe in my role I do not care about you know side A and side Z. Um and that means I’m not seeing stuff that I do care about.

So I can go ahead and you know modify that view and and get it down to just the things I care about which is you know let’s say just the data that was installed and its commit rate depending on you know what role I serve in the organization. So, u of course all that data is still available to you. Uh if for some reason you needed to see that, right, you could just exit that save view uh and and and be able to get back to what you uh you might need to find in the database or whatever information you were looking up for as well. Uh so let’s see.

I just pause here any interesting questions as we’re here on the uh view section. Uh can filter criteria allow Ginger syntax as well? Uh so the filter criteria is based on our uh uh there on our JSON and I believe the answer is yes. I’m going to need to double check on that one. Uh so if the folks here with me on the call could help me with that one. I believe that I believe the answer is yes to that but I think we’ll get some answers here from uh some other folks here that are joining me here on the webinar today.

Uh for you there AJ uh do not do ducks detail the filter syntax? Absolutely. Yes. So you will find those in the Nautobot documentation. So yes, we’ve absolutely got that there for you, Jason. And then uh let’s see uh does the custom field able to do calculations on other devices data? For example, like adding allocated draw on all the racks. Uh so I want to create a computed field that will do a calculation. Uh I don’t think you can do Python on a computed field. If I’m wrong on that, uh Chris, could you just double check that for me?

Um I cannot remember if you can do Python on a computed field. So the answer will be if if if you can do Python on a computed field then yes. If you cannot then it will be a no. Uh so that one we’ll just need to double check that. We’ll get you an answer there for that as well. Eric uh and then finally here while I’m on the questions I’ll just look at AJ’s looks like you clarified that there earlier.

So the custom nested fields will be like nested location information as a country and then a state and then a city as a location for a network device. Um we’ll need to get you some more details on that one there as well. So AJ, we’ll we’ll get you an answer on that. So just give us a a few minutes here. We’ll get some answers for you. Okay. Uh let’s take a little bit look into um exporting templates uh as we think about how we might want to uh get data out of Nautobot.

So export templates allow our you as a user to create a custom template to be used when exporting object data from Nautobot. uh the templates are accessed from the extensibility menu. Um and then you would go to export templates. So the templates are associated with a particular type of object and in this case you know in the example we’re we’re associating with here with devices and and then we can now create a ginga template which is uh which defines the data should uh that how it should look when we export it.

Uh so essentially what we’re doing is putting in a view if you will on the data that we export from. Uh so here you can see this example where we’re using Ginger to define what that should look like and of course because it’s Ginger we have a lot of power in what that could be um as we export that. So here we’re saying hey I want to get out the uh devices from Nautobot and I want them to be exported in this particular format here and you know obviously you can see we can do for loops we can have if statements so we can do filtering um as well as then we can specify exactly uh how we want that data to come out.

So uh could be really useful here. So rather than having to say filter this uh in whatever uh tool that you’re using to export the data from Nautobot now you can just grab that specifically. This can be very very useful especially if you’re operating in a really large environment with a lot of devices or data within Nautobot. Um being able to filter down to uh extracting just the data you need can be very powerful because it can save a lot of time.

uh if you’re pulling let’s say hundreds of thousands of objects out of the database that will take you know a few seconds right and if you can filter it down to just what you need uh directly within uh Nautobot that can really uh speed up things as well as just make your life easier on whatever that external tool is that you’re using with Nautobot or perhaps you’re able to export it in such a way that actually you know your user is happy with that report and that’s all you need to do um that can also be useful as well so depending on on the purpose of why we’re exporting from Nautobot this way either way can be very very powerful.

So great flexible tool here allowing you to adapt not only the view within the UI but also the views that you might see as you export data into something like you know a CSV or any other format that we can export from not as far as how we get to them. Uh you can see here on the left hand side uh we’ve have the uh custom export uh templates and they uh on the right here we can see the the the rendered result of what an example of what that might look like.

So here we’re just showing you know what that that previous one that we built what that looks like. You can see here a nice list um and you know pretty consumable report. You know it’s not fancy but it gets you the data you need um in a very consumable way and you know then importable into some other tool if that’s what you’re looking for or maybe you’re just looking for the report. Um and now I can see those details and have those there for me. Right? So uh here you know we chose the ASKI table. You can of also export as a CSV.

Uh so that would be uh your choices as you go into the uh export section under uh the uh templates that are okay. That’s a bit about the object features within Nautobot. Let’s now move on to talking about our Nautobot API and how we can use it to uh integrate uh Nautobot within our organization, perform orchestration and just you know build uh on top of that, right? Uh very powerful features here within Nautobot between the rest API and the GraphQL endpoint.

Uh one of the first things we did when we created uh Nautobot was to add in this GraphQL capability uh which is really powerful as well as the REST API. So probably most of you are familiar with REST APIs. This is how we can get access to uh data within the database. Um it exposes um all of the create, read and update and delete endpoints for virtually all the objects within the database. Um and we can see a list of those endpoints uh documented via the open API or swagger interfaces. Um and also includes native support for pagionation.

Um some of the you know features available via any REST API right is that you can manipulate one object type at a time. Um so you know hey I I want to add a device uh type or object I want to delete a device object whatever it might be but I can only do device object. Uh and you know that resource is therefore going to be you know indicated in the URL and it’s great for large volume. Um, but of course when we’re doing REST APIs, we are limited to just that that single uh endpoint that we might be accessing at any one time.

So if I need to uh update or retrieve multiple things, I’m going to have to make multiple calls to the REST API to get all of that data. Um, and that’s where GraphQL comes in. Particularly when I’m trying to query data from Nautobot. Um, gra the GraphQL endpoint is far superior to the REST API most of the time.

Um, and the reason for that is GraphQL is is essentially like a REST API if you’re not familiar with it, but it gives you the ability to use a query language to create the query you want to send to the database and be able to get multiple objects back all at the same time. So, let’s say I needed to get device information and interface information from Nautobot for whatever I’m doing. that would be at least two API calls uh that I would have to make depending on the data that I wanted to get back from Nautobot.

In the GraphQL uh example, I would simply form my query that included the device and the interface uh objects and I only make one call to the database instead of making multiple calls to the database. The other cool thing though is I can not only say I want multiple things, I can filter. So I can reduce the amount of data that I receive back from Nautobot to only the data that I need. So I can get all the data that I need and only the data that I need.

And if you’re working in a large scale environment, this can make a dramatic difference in the speed at which you retrieve data from the database. Uh you know, let’s say you happen to be in a really large organization and you had a 100,000 devices in your uh in the database. uh if you were to go do a REST API on that, that’s going to take a second. Uh versus if you’re using the GraphQL endpoint, you might filter it down to just what you need.

So perhaps you need some device information with some interface information, but you only need it for the Jersey City location like we looked at earlier. In that case, you’re going to enter, you’re going to include that Jersey City location filter as part of your GraphQL query. And now you’re only going to get back, let’s say, 500 devices because that’s how many you happen to have in your Jersey City site rather than getting everything back from the database, right?

So really, really speeds things up, makes your coding life a lot easier on whatever you’re doing external to Nautobot. So it can be really powerful for you there to really make things easier as you work with data from Nautobot, whether you’re extracting data from Nautobot or pushing data back in. um you have the rest API endpoints available for you and you have the GraphQL endpoint available for you. So really uh powerful features there as well.

Now let’s talk a little bit about northbound versus southbound APIs and what that means from a Nautobot perspective. So Nautobot does absolutely have both um and we have the uh northbound side. This is how we’re going to retrieve uh data from Nautobot. So here’s some examples of what we commonly see at a lot of our clients that they’re doing with the northbound API uh using for example uh the northbound API to allow uh service now to extract data from Nautobot to be used as part of you know maybe ticket creation for example.

uh or we want to say uh hey uh service now is updating Nautobot that uh a new router has been added into the service now CMDB and so therefore we need to push that into Nautobot. So either way uh service now could either extract data from Nautobot or push in uh using that northbound API and again doesn’t matter if it’s service now maybe you use uh you know remedy or uh you know jira whatever tool it is that you’re using and it doesn’t have to even be an ITSM tool like we have listed as examples here right whatever that you know where that external tool is

from Nautobot uh will be able to access that northbound API for retrieving of data or pushing of data in and Now the southbound API this is how we’re using uh from Nautobot to push out right so now instead of Nautobot uh being the recipient or uh delivering or being requested now Nautobot is pushing out to other tools. So this is how we communicate with external tools uh from the Nautobot perspective.

So you know maybe one example might be you you want to trigger uh an enh Ansible playbook uh that uh changes some QoS policy applied to a device interface you know when the bandwidth attribute in Nautobot has changed you know there might be so you know let’s say in this example you are updating dynamically into your environment based on some event that occurs within Nautobot now uh when that change occurs uh we can use that as the trigger to have Nautobot then go make that call out bound from Nautobot to whatever it might be.

And you can see some examples over there on the right hand side of of tools that you might use uh and to to to uh access from whether it’s something like DNA uh center or AWX or you know tufin IP fabric any number of examples um you know even something like cloud vision uh you know really interesting use cases here as far as like how we can use Nautobot to interact with external tools via its southbound API and again everything those are just examples as you see here on the screen these are not limitations basically any tool that’s got an API I uh we can interact with from Nautobot and the same inbound into Nautobot.

Any tool that has the capability to access uh an API can be used here. So what you see here on the screen are not limitations. These are just some common examples of things that we see a lot of times at our clients. So let’s take a look uh here as an example of you know what that might look like in uh using the northbound REST API here in a demo. So, uh, we’re going to, uh, first just kind of take a look, uh, as we had talked about earlier here within Nautobot, what does that API look like?

Uh, so I just wanted to explain, uh, quickly and easily here. If you go down to the bottom of any Nautobot screen, you’re going to see down here at the bottom, we have the API link and the GraphQL endpoint link. So, these are the easiest ways to get to these. If you don’t favorite them, uh, you can always come down here. They’re right here for you. So, here’s the API link, and I do have it launched already over here on this tab. Uh we can see here what the GraphQL end sorry the swagger interface looks like.

Uh pretty cool here because you can not only uh explore and see what the documentation is around the API endpoints you can also test them out. Uh so if you’re not familiar with uh the um uh Swagger interface it does give you the capability to actually do a test on those right. So you can uh actually run the get uh here from within Nautobot. uh if you were to authorize it with appropriate token, you could also then go and even do uh puts or uh uh and you know actually updating information into Nautobot as well.

So pretty cool feature here that you can test it out from within Nautobot. Uh so and this is the uh root here of the of the tree. So if you were to do some exploring around, you would be able to see all of the API endpoints of course that we have available. It’s basically going to be every single object that’s in the database. Uh so you might want to do some searches or finds for the things you’re looking for particularly. Uh but you know a lot of detail here for you.

Basically every endpoint is available for you to do tests on to play around with to understand how the API works. If you’re doing some developing or testing this is a great way to understand that. So, as an example here, let’s just take a look at let’s say we wanted to actually go, you know, start using this and we’ll we’ll do a test using Postman just to kind of show you what it looks like from an external uh perspective, not just from within uh AP uh from within Nautobot.

So, if we want to get started here, the first thing we’re going to need to do is create a token. Uh so, if you go down into the user, um then you’re going to go to profile and you’re going to go to your API tokens uh section here and we’re going to add one. As you can see here, we have a have a few here, but let’s just add a new one. Uh, so we’re going to say, hey, we’re doing a webinar and we need a token for that. Uh, and then we’re also going, you have the option whether or not you want to set some expiration date on that.

And perhaps you wanted to put a description in so you understand why you created this token can be pretty useful. Uh, so let’s go ahead and create that there. And now we will have the uh token. But of course, as you see here, we do have that data validation which uh indicates that I did something wrong. So, let me just uh I believe it’s because I put a space there is does not like that. Uh so, let’s get that created in here. Oh, it’s because I was putting it in as the key. Sorry about that. And not the description.

I was supposed to put it down in the description. I knew that, but uh mistakenly did that there. So, I’m going to let it dynamically create the key for me rather than uh try to do it myself. So, now we’ve created that token key and now we need to uh start to take use of it. Right? So, uh, I’m just going to use the handy copy button over there so I can get that copied. And we’re going to now pivot over to the Postman side of the world to see what that looks like. So, in this case, let’s just say we wanted to do a get against our users here.

And I did already pre-populate that in just to make it easier here in the webinar. Uh, and so I’m going to provide the authentication of the token here within my uh, uh, call to the API. And we’re going to send that out. And as you can see here, here’s the results. Now, of course, they’re coming back in JSON format. So if you uh you know pop this into a JSON uh uh interpreter, it could be a little bit easier to understand, but you can see the details that are coming back here. Of course, this is primarily intended for machines, not for humans.

Uh so you, you know, of course, we’re looking at some JSON detail, but you get the idea there of how you might test that out and prove that the API works external to Nautobot um not just from within the uh Nautobot interface. So now we can see that response there and uh we can use this in whether it’s you know we’re writing our scripts uh you know perhaps you want to pull some data into uh some script that you’re writing external to not um great way to do that uh we could get back you know all the devices we need and all of those things that we might need there uh as we look at using the Nautobot API.

Okay, so let’s take a look at some of the pre-built jobs that are available within Nautobot. These are jobs that just come as part of the Nautobot core and even some that get installed later along as you start to install applications within Nautobot as well. These can be really useful for you um depending on what they’re there for. Now these jobs here primarily exist for purposes within the UI to help things move along but they are available to you to use as well just as a user.

Uh so something to uh always keep in mind sometimes you know there’s something you want to do especially when you’re doing bulk operations uh where hey there’s pro there might already be a job available to do that thing uh so and that can be a lot easier to use the job rather than say go through the the UI directly and you know some great examples I can think of here is hey I want to go remove a series of devices based on some criteria you might want to just use the bulk delete objects job that can really make your life a lot easier or the same with you know editing you know, I want to make an update.

Maybe I want to go change all device descriptions to match some specific thing. Uh here we could we could use easily do that via the bulk update job. So different ways in which you might use these jobs. Um and they can all be run from within the jobs menu tree. Um so you’re always going to go to your jobs uh screen here and then we have th those will be available for you in that UI. uh you know other existing ones here.

Uh some you know maybe you want to import maybe you want to do a cleanup on your logs uh any number of cases where we have things that can be really useful to us to be able to get things done more efficiently um and and and and better in the way that we’re doing our jobs, right? So just thinking about you know whether or not you know how to create a job or not doesn’t matter. These are already there for you to use. You can just consume them. You don’t have to worry about creating one.

Let’s drill a little bit into git repositories uh as well here. So we’re going to start to think about how git repositories are linked in Nautobot and then we’ll also look at an example of of using a job as part of that git repository concept. Right? So, Nautobot can synchronize between an external git repository um as to in order to import and manage our network related data, execute jobs, uh generate config files and more. Right?

So, we uh are enabling the idea of version controlling and collaborative management practices within your organization. really helping you to create those devop workflows as you use Nautobot and you want to version data or concepts from Nautobot or to Nautobot. So n repositories are managed in Nautobot under the extensibility uh menu tree and you will find the get repositories submen. From here you can view manage all synced git repositories. Um and it doesn’t matter whether they’re public or private you can you can support we support both.

Um for the private repos you will need to configure a secret and a secret group uh in order to store those appropriate credentials but otherwise the access would be the same whether it’s public or private once you get those credentials in there for the private repository. Uh repository folder structure does matter. So for example uh Nautobot expects a jobs folder directory at the root level if the repository contains custom jobs. So what do I mean by that?

That means as we look at the idea here within the screen of get repositories right we have the URL of the repository uh the branch that we want to uh pull from um and then its purpose in life here on the Nautobot side of the world right so if we say this particular repository serves the purpose of jobs then Nautobot is is going to expect uh let me just get back to the appropriate slide there uh Nautobot is going to expect to uh a folder with uh jobs at the top of that repository. So just keep that in mind as you’re creating repositories.

Uh as you select what the provides field is that is going to determine what Nautobot is expecting within that repository to find in order to locate the appropriate data. Uh so this means that you can potentially have a single repository that provides more than one thing uh because of that folder structure. So that’s where you get that idea from there. Um but generally speaking we do recommend as good practice that you would use separate uh repositories for different provides here on the Nautobot side. It’s not required.

You do have a lot of flexibility there but it is what we see generally as good practice. You want to separate these out just for ease of use for humans to keep things more organized and more structured. So you can see that down here in the bottom as we start to if we were to add a new one we’re going to you know populate in just a name that we’re going to call this thing here on the Nautobot side of the world.

what that URL is, the branch we want to uh pull from, and then finally uh you know what purpose does it provide here on the Nautobot side and of course secrets if we were doing uh a private repo. Uh we can use repositories for you know automating and managing jobs. Uh we could uh keep custom configuration uh under version control. So perhaps you want to have a YAML file that stores some data over in Nautobot and then you want to pull that into a config context within Nautobot as an example.

data that comes into Nautobot does not have to come from the Nautobot database. Uh it could come externally from say a yaml file that you store in get. It’s perfect example of how you might use that. Uh we see often see people doing that for things that you want to control more carefully. Uh so perhaps you want to have uh you know your NTP servers listed uh in a YAML file rather than storing them in the Nautobot database. That’d be one way you could do that.

uh we can also enable our CSC pipelines to you know automatically update Nautobot content uh via this concept right so pretty interesting ideas here that come using the get repositories uh in uh our environment so let’s take a quick look at just kind of you know how we might do that and what that looks like uh so we’re going to go into our uh Nautobot example here again and we’ll go back into extensibility and we’re going to go into those get repositories and in this case let’s go ahead and add a new repos repository.

So, we’ll go to add add repository and we’re going to uh create one here. We’ll just do it for our webinar jobs. Let’s say maybe we want to use uh the Git repository as a as a way to sync jobs, right? So, here I’m going to just quickly copy a uh a URL that we’ve got. And this one actually is part of our 100 days of Nautobot if you’re not familiar with a really great uh course coming from Eric Chow here at NTC. Um so, please do uh check that out if you’re interested. uh it’s really excellent way to get familiar with Nautobot.

Now in this case it’s a public repo so I don’t need to worry about secrets and I’m going to say that it serves the purpose of jobs and then I’m now going to go down and uh create and dry run. So this means that it’s going to uh create the concept within Nautobot and it’s going to do a dry run of pulling in data from that repo. It didn’t actually pull any data in because we did the dry run, right? It’s just a test make sure all works. Um, and we can see here what it would have done. And we see everything is cool. So, okay, great.

Uh, that did work as we expected. So, now we can go ahead and sync it. If there was a problem, we’d want to go resolve that. You know, maybe it is it’s a private repo and you accidentally put the wrong um uh secrets in or perhaps maybe the uh menu tree wasn’t sorry, the folder tree wasn’t properly created over in the repo. We would be alerted to that and we could fix that before we proceeded. Right. So, now we’re going to go ahead and sync that. um and actually run it.

So we can see here now we actually went out and pulled all of that data uh from that repo, brought it into Nautobot and here we have a complete. So now we can actually go over to our jobs and we’re going to take a look at what that looks like now. Right. So what happened after we did that? Uh so we’re going to see as we uh scroll down here the the uh jobs have now been added into Nautobot and we’re going to find them way down here at the bottom since it was a webinar jobs, right?

And you can see here here’s the job that was uh synced into Nautobot. Now uh you’ll notice that it is not enabled. Um and that is by design. Uh so by design whenever we add a new job in Nautobot, it is not going to be automatically enabled. And that’s because we want to make sure that you are intentionally doing the what you’re about to do because jobs are really powerful and we don’t want to accidentally bring something in that we didn’t intend for. So we’re going to go ahead and enable that. Um, and then we’re going to click on the update.

And there we go. So, that should have actually, and that’s right. Um, I intentionally, uh, left this here just to remind us that, hey, sometimes we forget to do things within Nautobot. Um, and the great thing about Nautobot, we’re going to tell you that. We’re going to say, hey, this field is required. So, we’ll just go ahead and now select that. Um, get that updated. And now we should actually get a successful update and enable that job correctly. There we go. So, now we can see, hey, it’s enabled. It’s no longer grayed out.

And now we can go ahead and execute or run it. Uh so we took care of that. So now let’s uh now let’s actually go and do it. So we can do that either by clicking the blue play button over here or you could also you know drill into it um and see here you know where we see that queue there and we could run it here from you know either place right so as as within all things within Nautobot there’s usually two places you can execute from either that shortcut at the beginning or if you drill in you can also execute as well.

And of course by coming into it we can actually see the details and hey we went out we actually ran that job and you know synced uh the uh in this case it was pulling in additional jobs uh from uh the get repo is what this job actually did right so uh great features available for you here within the Ottawa platform. Now I know we all have been asking questions and I did a little different on this webinar here kind of interacting with you as we went.

Hopefully you enjoyed that and were able to get some uh you know answers to you more uh quickly as we went through when it was relevant in your mind. Um any other questions please do pop them in here for us uh as we come up to the end of the webinar. Um this is the perfect time for that as we have Q&A. So again as I note mentioned I know I know that we hit those there for you. So any other questions please do pop them in uh as we complete. I’ll definitely get you answers here before we finish out if you have any other additional questions.

Uh so just a quick recap. Hey, we went over those object features. Uh we took a look at the API and its capabilities north and southbound, some of the pre-built jobs that come with Nautobot and of course the idea of using Git repositories and why you might want to um within Nautobot ecosystem. Uh for those here joining the webinar today, uh we just wanted to quick talk about Nautobot extensibility workshop.

So if you enjoyed this uh webinar that we had, but you want to go deeper um and spend some time really understanding how you can use Nautobot and extend it to uh adapt it to your environment, this is a great way to do that. Uh get signed up for the course here and we’ve got a cool feature here for you. You can save $100 off that course with the code you got down there on the bottom, the webinar 100. So definitely uh get think about taking this course. It’s really detailed. It’s really practical.

Um, and it’s going to give you stuff that you can start using immediately as far as how you can start to consume Nautobot and leverage it better in your environment. Uh, just got a quick question coming in here from uh, Sean as well. So, thanks for that Sean. Uh, could you use the GraphQL query along with the job to create and push a network config to a device? Is that recommended or would you suggest a different method? So, it’s possible absolutely right.

So you could uh have some external uh uh tool or script that is uh create doing a graphql query uh then populating that in and then using that to feed into a Nautobot job. That’s absolutely possible. Yes, the platform is super flexible. Uh but you might not need to do that, right? So one of the things you can do within your Nautobot jobs is you do have direct access to the database as part of your job in your Python code. Uh so you don’t actually need to perform GraphQL queries within the job itself. Hopefully that makes sense, right?

So it depends on how you’re executing the job. Uh if you’re executing the job externally, that is you have some external code that needs to run and process and then it’s going to feed data into that job in order for the job to do work. Uh that would be one way and in that case you would use the GraphQL query but generally speaking probably most of the time you can run that uh job directly on the platform itself.

that is in the job you have direct access to the database within your Python code of the job and therefore you don’t actually need to run a GraphQL query. So hopefully that makes sense. Uh you would probably most likely not need the GraphQL endpoint in that case. Um but depends on how you’re executing the job and how you’re using it. So it’s going to be flexible there. Um you can always uh chat with us in the public slack if you are not uh on not support or on not cloud.

But if you are a uh me uh consumer of Nautobot cloud or have Nautobot support from NTC of course just open a ticket with us and we’ll be happy to uh you know get on uh with you and help you figure out what’s the best way for you. Another question coming in here uh let’s see there’s prerequisites source of truth and not fundamentals workshop or introductory knowledge of Nautobot this training has prerequisites there’s no upcoming run or training on it. Uh looks like Christy is typing an answer for you there so I’ll let Christy answer that.

Um but uh absolutely we can work with you on that. So don’t worry about that. Chris is going to get you the details on that. Okay. Uh as I had mentioned earlier as well, we do have the 100 days of Nautobot with Eric. Uh really really great self-driven self-directed course. Uh it includes practical applications, practical labs that you go through with and it takes you through uh the basically very detailed work within Nautobot. It gives you a little bit of work to do every day for 100 days.

Uh so it’s not overly uh difficult each day as you start to break down the overall concepts and by the end of the 100 days if you stick with it and make it your way through the process you will have gained a tremendous amount of knowledge uh and concepts within Nautobot. Uh so segment one within the 100 days covers Nautobot jobs basics. Uh segment two goes over advanced topics with Nautobot jobs. Um and then segments three and four are all about Nautobot apps. Right?

So again we have an intro to Nautobot apps and then some detailed uh topics within Nautobot apps and one of the common questions we get is a job versus an app. So both are based on python code. Uh Nautobot job is a relatively straightforward way to add some python code to Nautobot to do some work whether it’s uh you know filtering a query within your python code enabling business logic or just making a easier way for users to do something.

Uh those are all great uses for a job when generally speaking the reason why you would need Nautobot apps is that you want to make updates to the database model. So maybe you want to add a new table to the database uh as part of your application or thing that you want to do within Nautobot. That’s when you’re going to want to use an app. Um as well as if you want to update and inject menu trees as well. Not apps can enable that concept as well. So if I want to have a highle menu tree added in, I would use an app to do that as opposed to a job.

Those are the main reasons. There are of course other details, but those are the main reasons why I might choose a job versus an app. Uh so again, thanks for all of you for attending here today. Here’s some links to all things Nautobot. Uh if you’re looking for a personal demo, please do reach out to us. We’d be happy to get you uh linked up with our sales team and one of our sales engineers, and we can go through a detailed demo.

You can ask live questions, and we can show you all the advantages that Nautobot uh as you are working and exploring the ideas of Nautobot. So thanks everyone for attending. I look forward to seeing you on the next webinar.