Nautobot Next: Nautobot Jobs – Streamlining Repetitive Network Tasks

Hello everybody. Welcome in, wherever you are in the world. Looking forward to a really cool webinar here today for you all. Uh we’re just going to give it about one minute while we wait for everyone to filter into the room. But uh while we do that, we do have a poll for you all to uh help us out with. We’re kind of just curious to see responses here from the audience. So, as you see that poll, as you’re joining in, if you could uh give us an answer on that, that’d be great.

Um, it’s always cool for us to kind of just see where people are on their Nautobot journey. Uh, just kind of curious, I mean, just exploring, maybe you haven’t installed it yet, or maybe you have and you’re running along with it somewhere. So, just kind of interested to see where you’re at uh as we join in here. So, for those just joining in, it is taking a minute. We have a lot of people in the webinar today. Uh, so we’re going to wait about one minute as we let everyone filter in and get uh get this rolling.

So, as we wait, if you could please just give us an answer on that poll. We’ll wait just a few more seconds for everyone to get joined in before we get started here. We do have a fully packed webinar, so it’s going to be really great content for you today. Uh, looking forward to getting into this and going over it with you. All right, we are almost there. It looks like we’re stabilizing the room population. Great seeing you all today. Thank you. Uh good morning, afternoon or evening wherever you are in the world. Let’s go ahead and get started.

Uh so today this is in our Nautobot Next series and we’re going over Nautobot jobs uh oper operationalizing automation for everyone with Nautobot jobs. Uh today we’ll be hosted by uh Eric Chow and of course myself Tim Schreyack. We’re happy to take you through this webinar and today we’re going to go over some topics including what are Nautobot jobs. We’re going to take a look at the jobs framework. What does that mean inside of Nautobot? We’ll go through a demo. We’ll talk about some use cases and of course we’ll do some Q&A.

So starting into what are Nautobot jobs? Let’s kind of just lay the groundwork for this topic as we think about, you know, what exactly are we talking about? So the idea here is that Nautobot jobs combine direct access to Nautobot’s data models and execution engine with the full flexibility of Python to deliver automated outcomes. So whether you’re an experienced Python developer or just getting started, you already have what it takes to build powerful workflows in Nautobot. workflows are just repeatable, available, and secure.

So really, this is a great way to think of how I can leverage the data I have inside of my Nautobot platform and the Python environment that’s available to me. So as we think about how we move from scripts to automated operations, Nautobot jobs offer all the flexibility of our traditional scripts while adding structure, visibility, and collaboration. They make automation more scalable and production ready. And before jobs, you might have had a script on someone’s laptop or a shared drive and no idea who last touched it or used it.

With jobs, everything is actually centralized. You can version control it and even set up scheduling. So your team can execute tasks safely from the UI without needing CLI access. On the administrative control side, we have that centralized management, right? So, Nautobot centralizes your scripts so they’re easier to access and execute, moving them around from personal folders and lesser known shared locations to a central repository, providing you the ability to enhance your availability throughout the organization.

We also have direct uh network source of truth integration that is with Nautobot, right? So, direct access to the data in Nautobot. One of the major benefits is that we’re able to very easily include data from Nautobot within our Python code, access it, leverage it, and use it as part of our code in the way that we execute our jobs. It is really easy to use, right? It’s schedulable. Not all jobs can be set to execute on a schedule, which ensures that jobs can be executed in a timely fashion.

Or maybe you want to set up a job that runs in an off hours window, for example. you want something to run at 2 am every day or once a week or what have you. We can also initiate jobs from the UI so that you can execute whether uh as a user or other non-technical person right can execute jobs as well. So you don’t need to have a high technical capability to then use jobs because of that easy integration with the UI and finally teamfriendly development.

We have the idea of version control there where we’re storing our jobs in a Git repository or other repository and that could be GitHub, GitLab, Bitbucket, you name it, right? Uh and allows for easy collaboration uh because we’re able to work collaboratively on our scripts. We can share them. We can leverage them together. So instead of just one person having access to the power scripts that we might develop within our team, they’re available to everyone.

uh and so we have that equal opportunity if you will to to take advantage of the various uh code that we have written and Nautobot jobs widely applicable. uh we can use them uh no matter what it might be as our target, right? So, Nautobot itself could be a target for a Nautobot job to retrieve data or make changes directly to the Nautobot platform. Uh we can use jobs to make changes to network devices uh to collect information or push configuration to physical or even virtual devices. And finally to IT management platforms.

Whether we’re interacting with a ticketing tool or CMDB or even a monitoring system, jobs can be leveraged against any number of IT management platforms as well. So that brings us to now talking about the job framework. But before we do that, let’s just take a quick look at that poll that everyone had a chance to answer back at the beginning. Hopefully you gave us an answer on that and just kind of curious to see how we’re doing here. Uh so let’s just kind or take a look at this.

uh Eric if you have any comments as we think about this uh this poll here. So kind of similar to what we have seen similar in some of the past where a good chunk of you have not yet installed Nautobot you’re just exploring. So about 45% of you there. Um and then we’ve got the rest here in some form of using Nautobot um kind of along the journey. And it looks like we’ve got the biggest chunk kind of just in that running Nautobot in production but using jobs which that’s really great.

Great to see that you are all kind of interested in maybe learning how to use jobs even more and we’re going to definitely go through that here in the webinar today. Uh a couple of quick Oh sorry here. Go ahead. No, I was going to say it’s kind of surprising that a lot of people almost have a just kind of exploring and hopefully, you know, by the end of this webinar, you have some motivation. We could interest you enough to actually take some steps. We’re going to have tools, resources for you to get started.

So, you know, I’m excited actually to kind of reach out to people who haven’t seen the power of jobs that uh you know, we hopefully at some point we during this webinar or after that we could convert you to one of the other buckets. \>\> Yeah, absolutely. Uh I think we’re going to show you the power of using a job versus executing code external to Nautobot and you’re going to see a lot of advantages of that as we go through today. Absolutely.

Couple of quick uh housekeeping items.Oone uh please do use the Q&A box as you go through the webinar if you have any questions for us today that makes it easy for us to track those uh questions get you answers and make sure everyone can participate in those questions as well so please use that uh as well as um please do use the reactions button that you will see down there on your Zoom screen that’s really helpful for us to know things that you’re interested in things that are lighting you up things that you just you find you know really uh curious or

that you are wondering about like please use those that’s really helpful for us as we’re presenting we can really better understand and make sure that we’re uh tuning the webinar here today to things that are interesting to you all. Okay. So, with that, I’m going to hand over to Eric here to go through the job framework. Thank you, Tim, for the overview and welcome and I’m happy to see uh maybe some old friends, maybe some new people who are just interested in exploring their jobs.

So I’m happy to share this job framework with uh with all of you and let’s talk about some of the technical details for the jobs framework shall we? So um where do we store jobs? Storing jobs in the correct location is pretty essential. So for instance um I don’t know if any of you are real real estate but location just like Python and the Django framework we try to make a sensible default. So for more experienced users we want to let them know that something that just works.

So in that instance and Nautobot jobs Nautobot checks in the jobs root directory a lot of times this is your Nautobot root slash jobs for any kind of jobs for you to register. So that is a sensible default but that’s also possible to override through your environment. So placing your job file with Python scripts in that folder will automatically register for that job as long as you follow a certain format which we’ll cover in a little bit.

uh as Tim mentioned you know we could also store it in git repository synchronize it and we leverage all the features for git you know we could have some version control we could have collaboration history tracking you know bug tracking or comments all everything that git offers we could actually directly inherit through jobs if we keep them keep them in the git repository and obviously you know there’s some uh once you have jobs, you have a collection of job. This is typically the kind of flow, right?

You start with a simple job, maybe some Python script that advanced engineer, senior engineers have on their laptop. We operationalize it. We codify it into a job. Then some people say, “Hey, you know what about this feature?” So we have multiple jobs we have in the collection and at some point we have many many collections of jobs that serve the same function. Then perhaps we want to morph it into a custom Nautobot app.

So you know Nautobot jobs could be stored in Nautobot apps as well that interact directly with other apps data in within Nautobot and uh you know just becomes a very powerful feature for Nautobot jobs expose uh jobs in variety of ways as Tim mentioned the most common way is probably just going to UI uh you you have this job uh on the navigation bar when you click on it you see all the jobs that you have available and then you could execute it right there.

But also you know um we have exposed as an extension to these jobs uh job hooks which is uh kind of a derivative from uh web hooks. If you’re familiar with web hooks you know essentially something changed. It calls a call back to the hook quote unquote and then does something. So essentially a job hook is upon a data change. For example, if you add a new device, if you add a new uh location, it triggers the job and then the job does some kind of quality check.

For example, if your device has a certain hosting requirement, you know, airport code, function, numbering, uh domain name, that sort of stuff. We could actually once you have this action it triggers the job hook and then the job hook would do something automatically in the background just like a uh a junior engineer or intern right job’s your best friend when it comes to that and the job button is actually one step beyond the job hook.

So once you have that automated uh trigger option, maybe sometimes you don’t want to go through the job uh menu and then you want to have that job function triggered directly upon whichever page that you have. So for example, this is a uh show interface command and you want that job hook to be uh directly on the on the on the page where you have the interface listed, right? So then that’s where the job button becomes really powerful. Um, another way to trigger jobs is through the API. Uh, API is a first class citizen.

We have feature parity with everything you could do within the UI for the API. So certainly you could try to trigger uh, jobs through the Nautobot API and also Nautobot CLI. Jobs could be executed from Nautobot CLI. If you’re familiar with Nautobot, I know you know just from the poll we know many of you are just exploring. Um, so you know we do have a shell called nbshell. Nautobot shell that has all the uh imports necessary and um all the libraries that you need in order to get into the internals of Nautobot.

So within that nbshell you can actually execute jobs and that is a great way to troubleshoot or to dig deeper especially when just learning to kind of do a manual lever and just what do I do when you what happens when I pull this lever? What should I do? What happens when this happens? So the CLI is a very useful place to trigger jobs if you’re just troubleshooting or if you’re just learning. And the anatomy of a Nautobot job follows a very logical kind of a three section.

So the first one is the import uh we actually have a bunch of Python scripts libraries that you could just import that simplifies the creation of the job. As you could see on the example right here, we have the jobs library and all jobs are subclassing that library. So a lot of these inherited a lot of these attributes and uh functions methods are inherited from that base class. So we simply have to define, say the meta in order to leverage you know naming it into some sort of convenient way. Maybe there’s an approval required.

We just have to set it to be true or false and have sensitive variables for example. Those are all inherited from the base class. And then we have the run function within the job which is an entry point for a lot of um applications. You know if you go to HTML you know index.html that’s your entry point right? If you have some C programs you know the run method is your entry point.

So in this case the job is really the run, the function is really your entry point and that is where you define most of your job classification and uh and last is the job registration section. So this is where we actually register your job. when tell Nautobot this is where we want uh this is the job that we want to make Nautobot aware that it’s available and just from experience from you know the 100 dition Nautobot project that we’ll talk about a little bit and just from talking to the community this is probably one of the most overlooked area for

newcomers that who are just doing job for the first time and this is partially perhaps you know some of the older documentation for Nautobot 10 or 1x is that you in in the 1x era, you know, we kind of implicitly import these jobs and uh in 2, we we heard you know from the community that explicit is rather than implicit as the Python the Zeno Python says. So uh so we actually makes it explicit and if you want your job to be registered you want to have that uh register jobs.

So you know let’s dive a little bit deeper right as you could see the imports are pretty common and that’s what you do all the time uh register jobs are pretty common most of the logics reside within that uh that class so uh you know again the metadata is where you could tell some of the uh characteristics for the jobs the name you know probably a visual for uh kind of what the job does and then the run is your where you place most your workflow logic And just from you know working with a lot of customers and creating jobs myself.

Typically what you do is you you look at the run and then you put some logics in there maybe just line by line you know sequential what you want to do and once that becomes a bit uh overloaded and then you want to make it into another function and have that run run job reference that function and then uh you know keep going at it and once that reaches a certain critical point you want to create another job that does you know maybe some of the stuff that you wanted to do.

So it follows a very logical format and once you start creating you know your first five jobs right or the imports and the register become second nature and then the second the classes where you spend most of your time on. All right so when you’re defining a job in Python you could just control how it appears by setting some attributes.

Um in this case in this particular case you know we have the name of the job that appears in the description a general description of this function and from the last screen we saw like we could also have approval required and then the time limits. Um and this is at the bottom of the screen you could see this directly reference the uh whatever you know we have on the name and the description and we apply it on the UI. Not also gives you a UI for uh overwriting these.

Uh again, you know, just following Python and Django, we want to make sensible defaults. This is just about as straightforward as it gets. But, you know, we also want to accommodate experienced users. Let’s just say you don’t want to define it in the script or maybe you want the operator to have the option of overwriting it just because you know the coder has one thoughts, maybe the operator will have something more um more relevant.

So there’s also another in if you look at that pencil button you can actually go into a job detail override a lot of these characters including the name and description. All right so Nautobot jobs could also prompt for user input. This is actually one of the most powerful features for jobs is that just in a few lines of code we could dynamically interact with the users. And on this particular screen we have the object var as well as the uh choice var. So the choice var basically allows users to select uh from predefined static options.

So for example the show version is this is you know as you can see is a tuple. The first one is how it’s the first one is how it’s uh it will show up and the second one is actual thing the value that you actually pass it on to Nautobot jobs. And as you can see, we can actually have just the choice var or multiple choice var. We have the object var or multiple object v. Um it the object var lets users choose the existing object from Nautobot as Tim mentioned before.

Um one of the most powerful beside powerful functions for Nautobot jaws besides just having simple user interaction is actually to interact directly with the data that you have within Nautobot. You don’t have to make API calls. You don’t have to, you know, create your database separately. You can actually do all of that directly in um in Nautobot. And uh this is also another screen for just user inputs. A lot of times we do have a file var which allows users to upload their file.

uh we see this a lot within uh device onboarding or maybe you’re launching a new uh hub site or data center that you have to get a lot of information into Nautobot directly in a very quick format. So we have a file var, we have a CSV file. Maybe the first is your device name, primary IP, description, that sort of stuff.

And now once you have that file uploaded, then your Python logic could actually take that file file object, you know, parse it out and then do all kinds of logic with it and then bubble up the result through logs or through notification, that sort of stuff. Also uh I think this IP address fire is just another example of uh the enhancement improvement that we do within uh NTC and Nautobot project and Nautobot uh framework that you know this is more than just we take one step further from the standard libraries IP address as many of you have maybe have

used it before but um but you know we do one step further and just make it easy for people to say compare IP address make sure is the slot notation versus like a dot notation or you know any kind of verification. So that’s a great example of uh kind of enforcing the input fields you know we could have this interactive workflow with a few lines of code.

I mean if you’ve done HTML you know uh web development before you know in order to have an input you have to have a form you have to have some sort of JavaScript for submit and then redirect the user to another page for success and all these other stuff that are has nothing to do with your logic nothing to do what what you want with Nautobot jobs with just you know I know we display three lines but this is really just one line right just with one line of code you can have a file input You could have file upload.

You could have multiple choices and interact directly with the data within Nautobot. So this really makes your job reusable, safer and uh in my opinion pretty userfriendly. Again, the run method of the code is what I think we will spend the most of our time on because that’s where the actual work takes place. And um and in this example we actually have this um kind of an overview of you know what a typical job would be. I mean this is a pretty simple one but this defines the true logic.

So essentially you know the jobs should be what data should we capture either from the user or from Nautobot itself and then uh if we have any exceptions we want to bubble up the information through logs or uh and the within the logs how severe do we want to be whether it’s a warning it’s an error or something like that and then what kind of conditions we want to test. So in this particular example we saw line 23 is uh kind of defining the scope of the logic.

Line 24 directly interact with the data within the the you know the object the location objects right and then 26 define the scope for the loop where we loop over the devices where we collected and then you know 2731 would generate logs and uh it’s worth pointing out that these logs are also just built in and uh go into the normal what you would expect info warning errors that sort of stuff and line 32 to 44 you know logs error debug message whether is uh this this particular script is you take the device and you make sure it has a serial number and then it has a uh some other attributes then if it doesn’t have a serial number it go ahead and bubble it up.

So this is a very simple data quality check but this is kind of the overall structure for a lot of the jobs where we just know um have this workflow data do something with the data and display the results. So um you know I hope this is pretty apparent that with the you know the power of Python with the power of jobs there’s really uh the the ceiling is actually pretty high on what you could do with Nautobot jobs and uh as engineers progress with the automation journey I think um some Python libraries are are encountered more frequently um and Nautobot jobs because these are Python scripts they play nicely with all of these scripts you know like the device communication library.

Now we’re all big fans of Kirk’s work and I myself you know talked to Kirk quite a bit and you know just kudos to everything that he does. Netmiko simple Python library that does SSH connection to the device. Napalm multi-vendor consistent API retriever configuration data Nornir um asynchronous operations multi-threaded and uh you know have a lot of interaction with data modeling libraries.

So device modeling libraries, pymol, pars and writes yaml uh ginga 2 for template engine for python that you generate device configuration dynamically dynamically in a very structured format. Infrastructure libraries request pynautobot request obviously is a very popular python uh library. I believe it’s in the standard library now, but I could be wrong. But um basically it’s a make rest API call widely used by Fortune 10, Fortune 100 companies. Um, I think for NASA as well.

So it’s crazy to think a simple library uh could help us a simple Python library could help us become you know multiplanetary species, right? So uh so kudos to the source uh to the power open source pynautobot Python client for Nautobot’s rest api of course you know we have your text fsm for parsing nonstructured data into structured data and um now utils which is uh kudos to can and not ntc team for putting together these collection of vendor agnostic utilities from network to code to help parsing validating and normalizing network data and It might

be interesting to to people that text FSM has been a uh NTC template has been directly supported by Netmiko since 20 which is uh crazy to think it was December 20 2017 right so I don’t know it’s almost uh almost eight years ago seven years ago that has been adapted with Netmiko all right so uh with that thank you for listening and I’ll pass it back to Tim for some live demo. Yeah, thanks Eric for the great description of how Nautobot jobs function within the platform and some examples of how you might use Nautobot jobs in the real world.

Uh so now we’re going to actually take a look at a few jobs in a working demo environment so we can see kind of what they look like in practice. And here I’ve got some filtered down in one of our demo environments here. A few simple ones. So you know, starting off with something just as basic as hello world. So I’m going to drill into what that looks like from a practical perspective as far as how we might run it. So here’s an example of what the user might be presented with because obviously this is a very simple job.

Um but first let’s actually go look at the code, right? So here is the git repository where this code is stored and this is something you would find under the extensibility option within Nautobot where you would link the git repository that you want to put your uh job code into and then you can sync that into the Nautobot platform. Um, and as you saw in those examples earlier, right, here’s some very basic uh job code of a hello world job, right? And all it’s going to do is basically log hello world when we run it.

Uh, so you can see again as Eric mentioned, right, importing that job class and then creating the subclass that then executes that particular code and ex puts that log message out there for us. So if we were to just pivot over to that job instance, right, here’s that nice UI that the user might be presented with. We’ll just go ahead and run it now even though it’s going to be really simple just to get an idea of what that looks like and kind of the process that we go through as we use a job.

You’ll notice a few things here at the top of the screen. Uh first, you know, we’re getting, you know, a nice description because we put that in our log. Uh put that in our code. But we also get some other details about like who ran it, um when did they run it, what was the status, how long did it take, um you know, what did it return if anything of any if it returned any values in there. All documented here for us. So jobs give us a great way to run code.

Particularly when you think about comparing this to let’s say you ran some code on your laptop. None of this is going to be documented. We’re not we’re not going to know who ran it, why they ran it, when they ran it, what it was for, or anything like that versus when we do it on the platform. Now we get all of this documented for us. We have a history and a record of everything that was done as well as a step-by-step process as we go through that job there. Right? So here we can see, of course, all we did was print out hello world, right?

So simple, pretty easy job. Now, let’s go look at something maybe a little more interesting that starts to do some perhaps real work, right? So, here’s one that says, “Hey, we want to go and update the device serial number on a device.” So, maybe we have got a bunch of new devices in or we swap some out or something and you know, we know that we’re out of sync in our uh in our data center compared to what we have on the uh in the Nautobot, right? So, we want to get those things updated. So, let’s take a look at that job now.

So, if we go into our uh uh into our code here, we can see the um we’re going to update that. And apparently, I didn’t get that copied into this repository. So, we won’t take a look at the actual code here. We’re just going to go ahead and run it so we can see what it does. Uh we’re going to say, hey, we want to actually use a form that’s a little bit more complicated now, right? And now we’re presenting the user with some more information as Eric was showing us earlier where, hey, I can actually choose things from a drop down.

And of course, we do have that power of searching there. So, we can make it easy. We can get right to where we want to go, which in this case is going to be Jersey City. And that’s going to then filter down the next uh drop down for us. So, now I’m only going to see devices located in my Jersey City location, making it easy for me. Um, and I know that I want to make this change to my Jersey City router 01. And just to give you a little idea of how you might actually be able to check this, there are various ways.

One would be, of course, that you would log into the device itself and you could see that. But it’s kind of interesting to think that Nautobot can actually be used to check something like this, you know. So, for example, one of the things that the Golden Config app does is take backups of devices. So, I’m going to leverage that functionality here just to demonstrate that for you, which is if I pivot over to this backup that we ran of the device. Here’s my Jersey City router.

And I scroll down and I take a look at what I have here on the device, right? We’re seeing all of its configuration. Now, if I look over in my Nautobot side of the world, here’s what I have as well. what Nautobot thinks is out there. And right now, it thinks that the serial number of that device is 1111, right? Which is probably not correct. Uh so we want to get that updated. So in this case, we’re going to do this by hand.

There are of course various ways you might do this programmatically, but just for purposes of example of how you might use a job, right? So now let’s go back over to our job and we’re going to go ahead and execute that new serial number. And just for making it simple, we’ll just use twos now, right? Just to make sure we can do that, right? So there we’ll see that and we’re going to go ahead and execute that and we’re going to make that update into the Nautobot database.

So here what we’re demonstrating is using the capability of a Nautobot job to interact with Nautobot directly to then update that now into the Nautobot database. So as you can see here the job reports back that it executed correctly. It did its thing and let’s go see if it did. Right. So here we are back on our uh Nautobot screen and we’re looking at the device there in Jersey City. And we do a refresh there and we can now see that the serial number has been updated correctly. Right? So not a lot but jobs did what they should do.

Now as you extend this idea you can think about how you might need to do multiple devices at the same time or maybe you’re programmatically implementing some other change. Right? So really powerful way in which to interact with the data within Nautobot jobs. Now the third example that we have here is getting a little bit uh more complicated which is let’s go update the interface description on a device itself. So now we’re not just updating the data within Nautobot directly and getting it updated.

So just again to uh kind of clarify that idea I’m going to move back over to the backup configuration of the device. So now we’re looking at the configuration on the device directly. And I’m just going to show you that out there we’ve got this interface gate 2 and somebody put the wrong description on it. Literally the wrong description on it. Right? And ah we need to get that fixed. Right? So we want to make sure we get the right description there.

So because we had some uh nice easy Nautobot code available to us, we wrote some code to do this cuz maybe we need to go fix a bunch. Right? So you’ll see here a little bit more complicated code. uh again you know doing those basic imports of the job class but now we’re also doing things like importing the design models and we’re also importing the net mo connection handler. So we have a lot of power available to us here from using the jobs framework.

Because if you think about it, right, if you were to write this stuff external to Nautobot, you’d have to go create all of these things yourself and maybe import them from your own libraries. Here in the Nautobot platform, it’s all available to you directly. Very easy to now get access to all of that higher level functionality within the platform. You get down to the work you need to do. Don’t worry about all of this higher level of overhead work if you will as far as using that. Next, you can see us describing the filters.

So, this is how we’re creating those uh fields that the user is selecting from and being able to choose the appropriate uh device location and then the appropriate device from those nice easy UI dropdowns. Right? So, this is how we define that. Super easy to do. I’m making it really easy for you to create nice consumable forms for your users to use. So, maybe you want to be able to give the operations team, for example, the ability to run a job.

uh and you want to make sure that they don’t, you know, kind of go off the rails and do things they shouldn’t do. Here’s a great way you can do that. We can filter them down to the areas that they should be working on. They don’t need to go, you know, looking at all of the underpinnings of Nautobot. They can just get directly to what it is they need to do, which is in this case if we want to update the interface description, right? And of course, the code itself, right?

So here is the code itself where we’re actually going to make those updates and then use the connection handler to reach out to the device and actually change the device. Um and again in this case we’re using net mo but Nautobot being a very flexible framework there are lots of connection handlers that you might choose from as Eric was showing earlier any number of methods in which you might reach out to adjusted device all the way from something uh as straightforward as net mo up to as complex as maybe you want to use Ansible automation platform to

actually reach out and make that change right so there are lots of ways in which you might do this uh and it really depends on the complexity of your environment and the complexity of the particular workflow that you’re building, how you might choose to tackle that problem. So, I’m going to just now move over to the screen where we’ve got that uh update interface description there for us. Right? So, now we can see here, hey, I’ve already pre-selected these just to make it easy for us. Right? We’ve got Jersey City.

Uh we’ve got the router there, and we’re going to update that gig uh interface uh Ethernet, too. Right? Just to demonstrate that for you though, the power of these drop downs. uh you know sometimes what easily happens is you think you’re in one place and you’re not and you accidentally change the wrong thing for example because we’re updating these dropdowns as you select the previous one that helps eliminate those kinds of errors.

So for example you know when I select Jersey City uh router01 I’m only going to get the appropriate interfaces listed to me here. And in fact you might even filter these down more uh based on your code within your uh in your Python code. So, for example, maybe you want to make sure the operations team doesn’t mess up gig one because that’s your uplink or gig 48, you know, whatever, wherever you put your uplink. You could just not have that in the list at all, right? So, you could filter that out.

So, that’s a great way to make sure that users are doing the correct thing um and not accidentally making a typo, right? So, we’ll go ahead and just, you know, put the correct description on this device. Uh, and we’re going to fire it off and let’s run it right now. Highlighting again, you don’t have to run it right now, though. uh you could run it in the future and you could even set up recurring schedules if you have something that you want to run regularly.

So you have a lot of power here again within the UI as far as how you might execute this job and when you want it to run. So let’s go ahead and click run there and uh let it go do its thing. And as you can see pretty quick here in our demo environment able to reach out to that device uh make the update to the device and here we go. Job completed. Now, in this case, because we actually reached out and touched the device, let’s do it a little differently as far as how we check if it worked.

Of course, as I mentioned, you could log into the router, of course, directly. That would be one way. Um, but here’s another way. Uh, so we have the capability to do backups from the Nautobot platform, and that’s part of the Golden Config app functionality. So, let’s go ahead and run a backup from the device now. Uh, so I’ve again pre-selected here under our device choices, and we’re just going to do all of the same things that you saw me do.

Um, but this is one of the default uh jobs that comes with the uh Golden Gate Big application is this backup configuration uh job. And so it’s going to go out and run those backups for us. It’s going to reach out to that uh Jersey City router, do the backup, and put it into our Git repository. So if we go back over to our Git repository now, and we click refresh on our backup file here, and we scroll down, we should see that the interface has been updated to the correct description. And lo and behold, there it is.

the correct description updated out there on the device. So there’s kind of an interesting way that you might use the NWA platform to actually do things without having to actually log into a device. And I think this is an interesting story because you can think about this that hey maybe I don’t allow certain folks let’s say the operations team to actually log into devices directly. So here’s a way they can confirm something. They can double check that the work was done correctly if needed.

Uh, and of course we can do this in code as well, but maybe a human wants to put some eyes on something and double check. Here’s a way um, users can actually get access to the data they need without having to directly log into the device. So I think that’s kind of an interesting use case, particularly when you think about how I can leverage the capability of jobs and all of the different functionalities that Jobs have. So that is the demo that we had for you today.

Hopefully you find that interesting uh, as you think about how I might use the Nautobot jobs and execute on them. As Eric was highlighting, of course, there are some various shortcut buttons out here as well. So, definitely explore those as you look at them and think about how you use them. One other quick highlight that I want to mention on jobs, and it’s to Eric’s earlier point of being explicit. When you first sync a job into the Nautobot platform, it is not going to be enabled.

You are not going to see this little green check and it will not run if you try to run it. So you’re going to need to go in and you’re going to want to edit it and you’re going to come down and you’re going to enable that job. This is a key element of the Nautobot platform and something we implemented because we want to make sure that you are being explicit. If you sync a job into Nautobot by default it is not going to be enabled. So you need to make sure you come in and do that.

Uh and that is again intentional because we want to know that we want to actually use this job on this particular Nautobot instance. So again that is intentional. You need to come in and enable the job. So just keep that in mind because otherwise that can get really irritating like why won’t this job run it that’s why you just need to enable it that’s all. So good little tip there for you um making your life easier hopefully. Okay that concludes our demo portion of the webinar.

So let’s get back into looking at the rest of what we have to go through today. Uh next we’re going to take a look at some uh use case examples or an overview of how I might use uh Nautobot jobs and in practical uses. Uh so here’s one where hey we might want to onboard new devices. So easing the burden of onboarding our new devices with automation right uh scripts can range from simple to sophisticated and in fact you know I often sometimes don’t like to even think of them as scripts.

I really like to think of them as code because they can be very complex and scripts kind of implies this very simplistic view of the world and they don’t have to be well. They can be as we saw with that like hello world job for example they can also be pretty complex. Um so keeping that in mind uh that Nautobot jobs uh enable full automation of this in this case of onboarding workflow uh when needed we could uh you know capture device details and upload them to not uh generate the configuration of the device uh register the device with monitoring or our

ITSM tool and controller platforms uh perform QA testing to verify correct operation and even generate a report confirming that the deployment was successful. So we have so much power available to us because we literally whatever you can do in Python you can do in a Nautobot job. So there’s a lot of flexibility to implement not only technical solutions but also business process and that’s a lot of what we use Nautobot jobs to do which is the way that you follow process and your organization is probably a little bit different than most others or every

other and so this gives you that capability to implement that logic within your code and so this uh showing just one possible flow here um but that’s the beauty of Nautobot right like you adapt the platform you adapt Nautobot jobs to what it is that you need in your organization specifically um we don’t try to tell you how to run your organization. The platform adapts to you. We can automate changes. So we can leverage that job hook functionality that we talked about earlier to automatically enact changes.

So job hooks enable real-time automation to be triggered by changes inside of Nautobot. And this is where things get really powerful. uh an engineer let’s say updates a switch port in Nautobot uh something that they were already doing anyway and now that change triggers a job hook that configures the real device instantly similar to what you saw me doing where I went out and changed that uh interface description on the device for example um the CLI is of course still available to you on the device itself but in this case you wouldn’t have to touch it

and you do have flexibility uh usually when we start talking about this idea that hey I change something in Nautobot and that changes the device directly Sometimes engineers particularly network engineers get a little concerned like that seems scary. So we can put processes along the way there. Uh we can include things like approval chain flows that would have to happen prior to that change flowing out. Uh and we can also say set up time frames where hey maybe it doesn’t happen until 2 a.m. during our change window for example.

So don’t be afraid of this idea that hey I could leverage automation to actually instantiate change on devices. We can still do it carefully, thoughtfully and follow all proper business processes along the way. Um, but here we do have this really powerful concept available to us that hey, I don’t actually have to instantiate the change myself. I can let Nautobot handle that. So adding utility to no Nautobot pages, these are the job buttons.

This is where I can say, hey, I want to make it simpler for a user to do a particular thing and leverage a Nautobot job. This is where now I just click the button within that Nautobot page and I run that job behind the scenes. So a really interesting way again to use jobs to be able to get work done to make my life easier is to make the platform more adapted to your environment.

So you can see an example here that hey rather than you saw me going and manually running that backup uh job in order to pull the backups down from the device here we’re just saying hey click the save but backup config button. So making the life of the uh engineer or operator easier because in this case they wouldn’t have to go select the device specifically. It’s just going to take it from the page that it’s on. Right? So a really interesting way to use job buttons. Another thought here.

So as we talked about Nautobot jobs and you see they’re so powerful but of course they do mean that you need to have Python developer skills. Um, and that means that you’re going to need to learn how to write Python if you don’t already know. And you’re going to need to become familiar with the Nautobot way to use Python, right? One interesting concept that can be used is leveraging NautobotGPT. Uh this is a way to generate jobs and allow NautobotGPT to help you uh vibe code if you will to create Nautobot jobs simpler, faster, and easier.

Even potentially enabling less experienced developers or people that are just learning how to write Python to be able to level up their skills and do these kinds of functions really quickly and really easily. Uh we’re bridging that skills gap and delivering results fast. So in the old way, we would spend hours learning and writing a new job from scratch. looking through documentation, especially if we’re just learning uh to create that job or troubleshooting when there’s a problem or or maybe even customizing an existing job.

Now, we can do it in just seconds, right? We can look up information. We can understand, hey, how does this code work? What does this error mean? I don’t I’ve never seen this error before. What does it mean? Getting those answers back from NautobotGPT. Uh and I think to me the most powerful thing is understanding old code. Somebody else wrote the code. I have no idea what they were doing. This is confusing me. Uh there’s all these different classes being imported. I don’t know what this class does.

Very easy to understand code when we put it into NautobotGPT making it so much easier to adjust existing code. Why without me having to actually drill into every single bit of detail within that code as I try to understand what it does. So to me again, really powerful use. Um, something to consider. If you aren’t using NautobotGPT, definitely reach out to us. We’d love to get you onboard and understand how to leverage NautobotGPT to make your life uh better. All right, so let’s move on to some Q&A.

I know we’ve been answering a few here along the way during the session. I think we have a few open as well. This is your chance. If you have questions, please put them in the Q&A section for us as well as anyone interested in NautobotGPT, we did drop a link there in the chat for you. All right, so let’s start taking a look at these questions and see what we got. Uh, so we got one from Sean that says, uh, if you choose a location in a job like in Eric’s example script, does it get all the devices in child locations as well recursively?

And if not, is there a way to do that? I’m going to pitch that over to Eric since it’s his example. And uh, let’s see what you have to say here on this one, Eric. Well, I think you kind of answer it with your demo, right, and with your codebase. So essentially if you just choose the object and usually what you do want is you want to create query all like if you’re familiar with you know database queries or Django queries you create all but then you could limit it with your query parameters.

So you could do the filter as Tim me uh Tim shown before where they filter with you know certain locations with prefixes and so on and so forth and then you could bundle that up into uh just you know uh whether you when you have this device when you have this location in New Jersey then you only show Jersey devices and when you have Jersey devices you only show uh you know the interfaces within that device. So you could certainly do that but by default you build it recursively. Great. Thank you.

Uh from Jeff, we have one who was spying on some of the jobs apparently on the screen as we were looking through there. Is that generating firewall configs with Capiraa job that I saw publicly available in GitHub and are you able to share it? So uh that is uh that particular job comes as part of the security module within Nautobot. So yes, it is absolutely available uh and you would find it if you installed the security module that will be there. Um, one of the interesting concepts within Nautobot is the ability to model your firewall policies.

Um, it doesn’t have to be firewall, any ACL for that matter. So, your security policies can be modeled in Nautobot in a vendor neutral fashion. Uh, that is we store them in the Capira format and then we leverage Capiraka to output those configurations in a large number of vendor formats, right? So you can have this industry uh standard if you will um and then output into the appropriate devices uh syntax uh from that uh database within Nautobot.

So yes short answer even though uh interesting job absolutely uh and also showing you this idea as Eric had alluded to in his uh sections where uh applications will often come with jobs um and so you’ll see that and that’s a perfect example of where an app that’s the security module within Nautobot comes with that uh with that job. Yep. Absolutely. Is NautobotGPT open source? Short answer, no it is not. Uh it is one of the paid for applications within the Nautobot ecosystem. So no, it is not open source. Uh let’s see another question.

Uh two of the example jobs shown uh changing interface description and changing untagged VLAN. Wouldn’t these be better suited to update the interface description in the Nautobot database and push the changes from there rather than doing ad hoc? Absolutely yes. For simplicity here in the demo, we just went direct to the device. We wanted to not confuse and do, you know, multiple steps, but in the real world, you are absolutely correct. Uh we would want to be updating that source of truth first. Um and then proceed from there.

And there are any number of ways that might happen in the real world. So, absolutely great point, Sean. Um thank you for calling us out on not following our own best practice, but it was for purposes of the demo, and we actually did do that intentionally um that we didn’t want to make the job overly complicated. So, but you’re absolutely correct. Yes. Uh let’s see. Do I need to save to Nautobot before running a golden config job? Uh I don’t quite understand the question there. Uh I think you’re saying how would I use a golden config job?

Uh and if that is what you’re asking, the short answer is you would need to install the golden config application. Um and then those jobs would come along with it. So that I think is what you’re asking, but if not, feel free to follow up with a further question there. Uh let’s see. Does the Golden Config plugin, and by the way, we don’t call them plugins anymore. We do call them apps. So, just a little correction for you there.

Uh, does the Golden Config app work with all kinds of routers or at least like devices from Nokia, Juniper, Arista, and Cisco. Uh, so if you look in the uh Golden Config uh application repository, you will see the list of supported devices, but it is a very large list to your point. Virtually all major uh vendors and devices are supported. Uh, and even if it isn’t directly supported out of the box, it’s pretty easy to add on an additional uh, you know, vendor uh, syntax. So, um, short answer is probably yes.

Um, most likely for anything that you’re looking for. So, yes, for you to have any comments. By the way, Eric, feel free to chime in as, uh, we’re motoring through these questions here as well. No, you’re doing great, Tim. And, uh, thank you, Florian, for putting that answer. I don’t know if it’s the same Florian, but hey, you know, hello if you are. Uh let’s see someone asking about NautobotGPT. Uh, which LLM do you use for NautobotGPT? Can I use my own personal local button?

Uh so uh short answer is at the moment right now we are using the open AAI LLM. Uh however uh it is built to be very modular so that you uh can we will be able to leverage different LLMs. At the moment uh as far as I know you do not have that capability currently to bring your own. Um but that is something that we’re looking at. It will eventually most likely be enabled. So uh eventually uh but not currently as far as I understand. Okay. Uh oh we got some followup here. So uh we you are using the golden config app. Great. Love to see it.

Uh but identical is not generating. It’s only creating a get repo push. Uh so a couple of things. One if you are a uh NTC uh consumer that is you have not a lot of support from us. You can absolutely reach out to the support team. They will help you. Um if not reach out on our public Slack. Um our engineers are pretty responsive there. They’re definitely able to give you some assistance there with using the app. So, if you’re not already in our public Slack, just go ahead and join that and we’ll get you some answers to help you out. Okay.

From Bruce, uh, one of the challenges in developing a network automation job, uh, sorry, one of the challenges in developing a network edition of job and let’s assume Python is being used in the job. Well, it would have to be because yes, network automation jobs within Nautobot are only Python. Uh, one could say there could be three programming domain logics uh, in a given job. So that you have the the Python programming logic, the Ginga templating logic, and perhaps Ansible playbook logic. Sure, that makes sense.

Y one of the takeaways I’m getting from this webinar is perhaps running Nautobot jobs allows a developer to rely less on dealing with Ansible playbook logic and perhaps Ansible playbooks at all. Am I correct in thinking this? 100% yes. Uh one of the things we first did with Nautobot is really deeply integrate ansible into the platform.

So for example, if I’m using a Ginga template within the Nautobot ecosystem, I don’t need to worry about all that ansible overhead of how I merge that template and get say inventory uh file creating group varss and device bars, all that stuff. All of that’s handled dynamically by the Nautobot platform. So really making your life easier when you’re consuming let’s say something like Ginga template or even feeding data into an Ansible playbook. Nautobot’s going to handle all that overhead for you.

Now I had this question from a client just yesterday. um which was how do I decide should I just use a job or should I use a job that also leverages ansible and or ansible automation platform and I think it really comes down to the complexity of your workflow so Nautobot jobs can absolutely be changed so you can create really complex workflows using Nautobot jobs however you’re going to have to handle all the error checking all the error handling all of the if then else tree structure yourself right so you’re going to have to write your Python code that’s going to then execute another job.

It’s going to wait for the results. Uh it’s going to look at the results, make decisions based on what happened there. Essentially, you’re creating your own orchestration engine depending on the complexity of your job. Why do that? You already have ansible. We already have ansible automation platform potentially within your environment. Um it’s a really good orchestration platform. Leverage it. Use it for what it can do.

If your job is complex, if your job is really simple, maybe you don’t need that overhead and you just do everything directly within Nautobot and the Nautobot job and in Python. So it really depends on the complexity of your workflow in my opinion. Now I’m going to give Eric a chance to see if he has anything different from opinion on that. But that would be my take. You decide what is the complexity of using an automation platform worth it or maybe I don’t actually need it. Yeah. No, I absolutely agree.

I think this is a very personal decision and largely relies on your team’s capability. If your team’s more familiar with Ansible, if Ansible is being used by uh in a lot of instances that we saw was already used by system uh DevOps administration, then uh yeah, by all means use leveraging the existing Ansible. But if you’re starting from scratch, more and more we see people starting directly from Python. So it really is kind of individualized and uh we’re flexible enough to accommodate both.

And hopefully you can make that decision based on your own situation. Yep. Yep. Uh this one I’m definitely going to have to give to you Eric because I don’t know the answer. Uh let’s see if you know. Uh, is it possible to integrate container labs natively through apps in the Nautobot platform? Yeah, I don’t see why not. Um and later on when we go through a resource section we have 100 digits and in all the examples we actually use container lab as the lab platform using a bridge interface for uh containers.

So as long as you have reachability uh you could definitely use container lab and it’s up to you to see which portion of container lab how deeply integrated you want it to be right so that’s kind of this question of um needs more understanding on your use cases but uh we have some basic use cases in 100 Nautobot that definitely use container lab. Here’s a a great question coming from Abish which is hey I already have Ansible automation platform or AWS, I’m not sure which or you name the orchestration engine already in my environment.

Do I need Nautobot and why should I use Nautobot? You absolutely need Nautobot. And here’s why. When you run any of these orchestration platforms, uh what that you need to do is now create your inventory file, your group fars, your device files, all of that overhead that comes with maintaining those platforms. And it doesn’t matter which one you’re using. And you probably have multiples um particularly as you start to scale up. Maybe you’re using uh CI/CD pipelines.

You have all of these different areas where I’m going to need to define data and feed data into these platforms. That’s what Nautobot’s purpose is in that kind of a reference architecture, which is where we define the data in Nautobot and Nautobot feeds the data automatically into those platforms for you. So now you get to leverage the capabilities of those platforms without having to deal with the overhead of maintaining and using those platforms, right? So you get the power of them without the complexity of having to maintain them.

Uh that’s where Nautobot shines. Nautobot gives you that capability to say hey I define data in a single place in my environment and then I use Nautobot to feed data into every other tool or every other workflow every other job etc throughout my environment. So a great question and uh that’s exactly why we want Nautobot here. Quick follow-up question uh from Bruce with running Nautobot jobs I have the option of eliminating the need to use AAP andor uh AWX at all. Uh, you just answered my question.

I can run Nautobot only jobs with the need to use endless walls. Yeah. Okay. So, you were just saying thank you. Appreciate that, Bruce. Sometimes reading questions on the fly. I don’t always pick up that. You’re just giving me a shout out. So, appreciate it. Uh, let’s see. And now, uh, CI/CD. I’ve got a couple of questions on CI/CD pipelines. You know, will we implement them? You know? Absolutely, we see CI/CD as really important. And this is something that we typically find with clients as they get further along in their journey.

Nautobot integrates well with various CI/CD engines and pipelines. So yes, absolutely. Would it be something we would implement within Nautobot? Unlikely. There’s no reason for us to do that, right? That’s not the role of Nautobot. There are lots of good tools out there that already do this. So we integrate with them rather than implement that capability directly in the platform. So pretty unlikely.

And uh just to just to add add to what Tim said for the past two Autocons in a row we actually did workshops uh by NTC folks on CI/CD uh integration and you know doing jobs Nautobot that sort of stuff. So uh I if you want to see another workshop please do uh in the public slack channel promote uh another CI/CD workshop. We’re happy to conduct it. It’s just you know the decision is not up to us. So if you want to see more CI/CD integration, please do let the uh you know community know. Yep. Uh one last question here.

It looks like uh oh there was a question on uh any information on uh 3.0 when it might be released. Uh it is coming soon. Let me put it that way. Uh we don’t have a firm date yet, but as soon as it is available, we will publish it for you. But it is going to be soon. Don’t worry. Uh another one about uh community repo where sample jobs. Um, to my knowledge, we don’t have anything like that today. Eric, correct me if I’m wrong, but it’s an interesting concept. Um, not sure if it’s something we would do, but definitely interesting.

Something we could at least consider. Um, some way for folks to share uh sample jobs perhaps. Um, great idea. Um, and something we can chat about internally here at NTC. Uh, let’s see, I think that concludes most of the questions that we have left out here. If I didn’t get to yours, I do apologize, but we are approaching time, so we need to get back into the webinar as we close it out. So moving on to as we conclude out the webinar, thank you all for attending today, and I’m going to hand over to Eric for some closing notes.

Yeah, so you know, thanks again for attending today’s webinar. We do have a lot of resources. Um, the idea about posting a community contribution uh sample jobs, that’s very interesting. So we do uh so you know we’ll take that into consideration but we already have a Nautobot job block series that takes you from zero to at least get the hello world and maybe some of the more uh interesting aspects of Nautobot and Nautobot Jobs documentation.

We do try to keep the the documentation thorough and guided installation video series if you’re kind of a visual learner you know please do feel free to follow that and uh you know seeing is believing so the video series is actually uh quite wonderful in doing that aspect for learners and of course you know uh yours truly 100 days in Nautobot that’s my passion and you know thank you for NTC for making this widely available it doesn’t require any specialized software, it takes you directly uh from zero to at least in section 10.

So for the first 20 days you will cover everything that Tim had uh mentioned. It doesn’t require any special software and uh it takes your guided tour. It does take some uh investment on your end but you know hopefully the quality of content justify for those and uh please do sign up if you just you know wanted to take Nautobot uh for Nautobot jobs for a spin. You know just concentrate on first 20 days and if you like it please continue. And just to recap, you know, we covered what are Nautobot jobs, the jobs framework.

Tim did a wonderful job on the demo as well as the first part on covering Nautobot jobs use cases and we provide resources. And uh you know, we’re up on time. I’m just, you know, really happy to see the community be engaged. All the wonderful questions that’ve been posted. If we didn’t get to it, as you mentioned, we’ll definitely get back to you. And uh thanks again for attending. Happy automation. Happy automating.