Week 8 recap

Nautobot is divided into Django “apps” corresponding to major functions

• circuits: Data circuits & providers
• dcim: Sites, racks, device types, devices, cables, etc.
• extras: Extensions & integrations (e.g. webhooks, export templates)
• ipam: Prefixes, IP addresses, VLANs, VRFs, etc.
• secrets: Credentials storage
• tenancy: Tenants and groups
• virtualization: Clusters and virtual machines

Integrations

• REST API
  • Machine-focused CRUD operations; parallel to the web UI
• Webhooks
  • Automatically inform remote systems of changes to Nautobot data
• Export templates
  • Customized export of Nautobot objects
• Plugins
  • Python-level extensions to Nautobot

Models

• MVT
  • Model: Structured data stored in a relational database
  • Table rows are handled as individual Python instances
  • View: The business logic employed in request/response processing
• get() and post() functions handle HTTP requests
• Template: Rendering of data for display to the user
• DTL/Jinja2 renders HTML templates using context provided by views
• Creating a new model requires a new SQL table
• Django migrations can do this for us automatically
• Migrations also handle adding, changing, and removing table fields (to a degree)
• Two management commands:
  • makemigrations: Create the schema migration files
  • migrate: Apply the migrations by executing SQL commands
• Migration files can alternatively be created/modified by hand, but not recommended

Django admin

• Django provides an admin UI as a convenient backend for normal administrative functions
• Creating, modifying, and deleting objects
• Nautobot employs the admin UI for “backstage” objects
• Registering a model in admin.py provides generic forms & views for the model

Views

• List views display a set of objects from the database
• Detail views show or manipulate a single object
• Stock CRUD operations are included; don’t need custom methods

Forms

• Django forms assist in processing user input via views
• Analogous to HTML forms
• Allow for validation and error reporting
• The type of a field determines its valid values
• Forms also support custom validation
• Form classes are easily rendered as HTML forms in templates
• We define forms by specifying form fields
• Form fields are not the same as model fields
• Model fields define how data is stored in the database
• Form fields define how data is input within a view

Navigation

• Plugins can extend the Nautobot navigation menu with their own links and buttons
• Plugin items appear below the “Plugins” dropdown
• Hidden when no plugin items have been registered
• Grouped by plugin name
• Edit navigation.py and define menu_items
• Iterable of PluginMenuItem instances
• Each menu item can include buttons

Permissions

• Nautobot provides an object-based permissions framework
• Replaces Django's built-in permissions model
• Object-based provides granular control
• Not restricted to applying permissions to records of a specific type.
• Four core actions, analogous to the CRUD operations
  • Add - Create a new object
  • View - Read an object from the database
  • Change - Update an existing object
  • Delete - Delete an existing object

Serializers

• Serializers handle data display and validation
• Analogous to Django forms, but with JSON
• Views contain the business logic
• Separate view functions for e.g. GET vs. POST vs. DELETE
• Separate view functions for detail vs. list views
• Typically combined in a single ViewSet class
• Routers map URLs to views
• AKA URL patterns in Django

Jobs

• Jobs provide a way for users to execute custom logic on demand within the Nautobot UI
• Jobs can interact directly with Nautobot data
  • Jobs have direct access to the Django ORM
• Jobs execute asynchronously as background tasks
  • Ideal for connecting to external data sources
• Jobs log messages and report status to the database
  • Update JobResult records
  • Create JobLogEntry records