nautobot 2.0.4__py3-none-any.whl → 2.1.0b1__py3-none-any.whl

nautobot/docs/user-guide/administration/installation/services.md

@@ -1,340 +0,0 @@
-# Deploying Nautobot: Web Service and Workers
-
-## Services Overview
-
-Like most Django applications, Nautobot runs as a [WSGI application](https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface) behind an HTTP server.
-
-Nautobot comes preinstalled with [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/) to use as the WSGI server, however other WSGI servers are available and should work similarly well. [Gunicorn](http://gunicorn.org/) is a popular alternative.
-
-Additionally, certain Nautobot features (including Git repository synchronization, Webhooks, Jobs, etc.) depend on the presence of Nautobot's [Celery](https://docs.celeryq.dev/en/stable/) background worker process, which is not automatically started with Nautobot and is run as a separate service.
-
-This document will guide you through setting up uWSGI and establishing Nautobot web and Celery worker services to run on system startup.
-
-### Web Service
-
-Nautobot includes a `nautobot-server start` management command that directly invokes uWSGI. This command behaves exactly as uWSGI does, but allows us to maintain a single entrypoint into the Nautobot application.
-
-```no-highlight
-nautobot-server start --help
-```
-
-### Worker Service
-
-Nautobot requires at least one worker to consume background tasks required for advanced background features. A `nautobot-server celery` command is included that directly invokes Celery. This command behaves exactly as the Celery command-line utility does, but launches it through Nautobot's environment to share Redis and database connection settings transparently.
-
-```no-highlight
-nautobot-server celery --help
-```
-
-+/- 1.1.0
-    Prior to version 1.1.0, Nautobot utilized RQ as the primary background task worker. As of Nautobot 1.1.0, RQ is now *deprecated*. RQ and the `@job` decorator for custom tasks were still supported for the remainder of the 1.x.y releases, but users should [migrate the primary worker to Celery](#migrating-to-celery-from-rq).
-
---- 2.0.0
-    Support for RQ has been completely removed from Nautobot.
-
-#### Advanced Task Queue Configuration
-
-You may want to deploy multiple workers and/or multiple queues. For more information see the [task queues](../guides/celery-queues.md) documentation.
-
-## Configuration
-
-As the `nautobot` user, copy and paste the following into `$NAUTOBOT_ROOT/uwsgi.ini`:
-
-```ini
-[uwsgi]
-; The IP address (typically localhost) and port that the WSGI process should listen on
-socket = 127.0.0.1:8001
-
-; Fail to start if any parameter in the configuration file isn’t explicitly understood by uWSGI
-strict = true
-
-; Enable master process to gracefully re-spawn and pre-fork workers
-master = true
-
-; Allow Python app-generated threads to run
-enable-threads = true
-
-;Try to remove all of the generated file/sockets during shutdown
-vacuum = true
-
-; Do not use multiple interpreters, allowing only Nautobot to run
-single-interpreter = true
-
-; Shutdown when receiving SIGTERM (default is respawn)
-die-on-term = true
-
-; Prevents uWSGI from starting if it is unable load Nautobot (usually due to errors)
-need-app = true
-
-; By default, uWSGI has rather verbose logging that can be noisy
-disable-logging = true
-
-; Assert that critical 4xx and 5xx errors are still logged
-log-4xx = true
-log-5xx = true
-
-; Enable HTTP 1.1 keepalive support
-http-keepalive = 1
-
-;
-; Advanced settings (disabled by default)
-; Customize these for your environment if and only if you need them.
-; Ref: https://uwsgi-docs.readthedocs.io/en/latest/Options.html
-;
-
-; Number of uWSGI workers to spawn. This should typically be 2n+1, where n is the number of CPU cores present.
-; processes = 5
-
-; If using subdirectory hosting e.g. example.com/nautobot, you must uncomment this line. Otherwise you'll get double paths e.g. example.com/nautobot/nautobot/.
-; Ref: https://uwsgi-docs.readthedocs.io/en/latest/Changelog-2.0.11.html#fixpathinfo-routing-action
-; route-run = fixpathinfo:
-
-; If hosted behind a load balancer uncomment these lines, the harakiri timeout should be greater than your load balancer timeout.
-; Ref: https://uwsgi-docs.readthedocs.io/en/latest/HTTP.html?highlight=keepalive#http-keep-alive
-; harakiri = 65
-; add-header = Connection: Keep-Alive
-; http-keepalive = 1
-```
-
-This configuration should suffice for most initial installations, you may wish to edit this file to change the bound IP
-address and/or port number, or to make performance-related adjustments. See [uWSGI
-documentation](https://uwsgi-docs.readthedocs.io/en/latest/Configuration.html) for the available configuration parameters.
-
-!!! note
-    If you are deploying uWSGI behind a load balancer be sure to configure the harakiri timeout and keep alive appropriately.
-
-## Setup systemd
-
-We'll use `systemd` to control both uWSGI and Nautobot's background worker processes.
-
-!!! warning
-    The following steps must be performed with root permissions.
-
-### Nautobot Service
-
-First, we'll establish the `systemd` unit file for the Nautobot web service. Copy and paste the following into `/etc/systemd/system/nautobot.service`:
-
-```ini
-[Unit]
-Description=Nautobot WSGI Service
-Documentation=https://docs.nautobot.com/projects/core/en/stable/
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-Type=simple
-Environment="NAUTOBOT_ROOT=/opt/nautobot"
-
-User=nautobot
-Group=nautobot
-PIDFile=/var/tmp/nautobot.pid
-WorkingDirectory=/opt/nautobot
-
-ExecStart=/opt/nautobot/bin/nautobot-server start --pidfile /var/tmp/nautobot.pid --ini /opt/nautobot/uwsgi.ini
-ExecStop=/opt/nautobot/bin/nautobot-server start --stop /var/tmp/nautobot.pid
-ExecReload=/opt/nautobot/bin/nautobot-server start --reload /var/tmp/nautobot.pid
-
-Restart=on-failure
-RestartSec=30
-PrivateTmp=true
-
-[Install]
-WantedBy=multi-user.target
-```
-
-### Nautobot Background Services
-
-+/- 1.1.0
-    Prior to version 1.1.0, Nautobot utilized RQ as the primary background task worker. As of Nautobot 1.1.0, RQ is now *deprecated* and has been replaced with Celery. RQ and the `@job` decorator for custom tasks were still supported for the remainder of the 1.x.y releases, but users should [migrate the primary worker to Celery](#migrating-to-celery-from-rq).
-
---- 2.0.0
-    RQ support has been fully removed from Nautobot.
-
-Next, we will setup the `systemd` units for the Celery worker and Celery Beat scheduler.
-
-#### Celery Worker
-
-+++ 1.1.0
-
-The Celery worker service consumes tasks from background task queues and is required for taking advantage of advanced
-Nautobot features including [Jobs](../../platform-functionality/jobs/index.md), [Custom
-Fields](../../platform-functionality/customfield.md), and [Git Repositories](../../platform-functionality/gitrepository.md), among others.
-
-To establish the `systemd` unit file for the Celery worker, copy and paste the following into `/etc/systemd/system/nautobot-worker.service`:
-
-```ini
-[Unit]
-Description=Nautobot Celery Worker
-Documentation=https://docs.nautobot.com/projects/core/en/stable/
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-Type=exec
-Environment="NAUTOBOT_ROOT=/opt/nautobot"
-
-User=nautobot
-Group=nautobot
-PIDFile=/var/tmp/nautobot-worker.pid
-WorkingDirectory=/opt/nautobot
-
-ExecStart=/opt/nautobot/bin/nautobot-server celery worker --loglevel INFO --pidfile /var/tmp/nautobot-worker.pid
-
-Restart=always
-RestartSec=30
-PrivateTmp=true
-
-[Install]
-WantedBy=multi-user.target
-```
-
-#### Celery Beat Scheduler
-
-+++ 1.2.0
-
-The Celery Beat scheduler enables the periodic execution of and scheduling of background tasks. It is required to take
-advantage of the [job scheduling and approval](../../platform-functionality/jobs/job-scheduling-and-approvals.md) features.
-
-To establish the `systemd` unit file for the Celery Beat scheduler, copy and paste the following into `/etc/systemd/system/nautobot-scheduler.service`:
-
-```ini
-[Unit]
-Description=Nautobot Celery Beat Scheduler
-Documentation=https://docs.nautobot.com/projects/core/en/stable/
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-Type=exec
-Environment="NAUTOBOT_ROOT=/opt/nautobot"
-
-User=nautobot
-Group=nautobot
-PIDFile=/var/tmp/nautobot-scheduler.pid
-WorkingDirectory=/opt/nautobot
-
-ExecStart=/opt/nautobot/bin/nautobot-server celery beat --loglevel INFO --pidfile /var/tmp/nautobot-scheduler.pid
-
-Restart=always
-RestartSec=30
-PrivateTmp=true
-
-[Install]
-WantedBy=multi-user.target
-```
-
-#### Migrating to Celery from RQ
-
-Prior to migrating, you need to determine whether you have any plugins installed that run custom background tasks that still rely on the RQ worker. There are a few ways to do this. Two of them are:
-
-* Ask your developer or administrator if there are any plugins running background tasks still using the RQ worker
-* If you are savvy with code, search your code for the `@job` decorator or for `from django_rq import job`
-
-If you're upgrading from Nautobot version 1.0.x and are NOT running plugins that use the RQ worker, all you really need to do are two things.
-
-First, you must replace the contents of `/etc/systemd/system/nautobot-worker.service` with the `systemd` unit file provided just above.
-
-Next, you must update any custom background tasks that you may have written. If you do not have any custom background tasks, then you may continue on to the next section to reload your worker service to use Celery.
-
-To update your custom tasks, you'll need to do the following.
-
-* Replace each import `from django_rq import job` with `from nautobot.core.celery import nautobot_task`
-* Replace each decorator of `@job` with `@nautobot_task`
-
-For example:
-
-```diff
-diff --git a/task_example.py b/task_example.py
-index f84073fb5..52baf6096 100644
---- a/task_example.py
-+++ b/task_example.py
-@@ -1,6 +1,6 @@
--from django_rq import job
-+from nautobot.core.celery import nautobot_task
-
-
--@job("default")
-+@nautobot_task
- def example_task(*args, **kwargs):
-     return "examples are cool!"
-(END)
-```
-
-!!! warning
-    Failure to account for the RQ to Celery migration may break your custom background tasks.
-
-### Configure systemd
-
-Because we just added new service files, you'll need to reload the systemd daemon:
-
-```no-highlight
-sudo systemctl daemon-reload
-```
-
-Then, start the `nautobot`, `nautobot-worker`, and `nautobot-scheduler` services and enable them to initiate at boot time:
-
-```no-highlight
-sudo systemctl enable --now nautobot nautobot-worker nautobot-scheduler
-```
-
-### Verify the service
-
-You can use the command `systemctl status nautobot.service` to verify that the WSGI service is running:
-
-```no-highlight
-● nautobot.service - Nautobot WSGI Service
-     Loaded: loaded (/etc/systemd/system/nautobot.service; enabled; vendor preset: enabled)
-     Active: active (running) since Fri 2021-03-05 22:23:33 UTC; 35min ago
-       Docs: https://docs.nautobot.com/projects/core/en/stable/
-   Main PID: 6992 (nautobot-server)
-      Tasks: 16 (limit: 9513)
-     Memory: 221.1M
-     CGroup: /system.slice/nautobot.service
-             ├─6992 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-             ├─7007 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-             ├─7010 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-             ├─7013 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-             ├─7016 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-             └─7019 /opt/nautobot/bin/python3 /opt/nautobot/bin/nautobot-server start />
-```
-
-!!! note
-    If the Nautobot service fails to start, issue the command `journalctl -eu nautobot.service` to check for log messages that may indicate the problem.
-
-Once you've verified that the WSGI service and worker are up and running, move on to [HTTP server setup](http-server.md).
-
-## Troubleshooting
-
-### Operational Error: Incorrect string value
-
-When using MySQL as a database backend, if you encounter a server error along the lines of `Incorrect string value: '\\xF0\\x9F\\x92\\x80' for column`, it is because you are running afoul of the legacy implementation of Unicode (aka `utf8`) encoding in MySQL. This often occurs when using modern Unicode glyphs like the famous poop emoji.
-
-Please see the [configuration guide on MySQL Unicode settings](../configuration/required-settings.md#mysql-unicode-settings) for instructions on how to address this.
-
-Please see [Computed fields with fallback value that is unicode results in OperationalError (#645)](https://github.com/nautobot/nautobot/issues/645) for more details.
-
-### SVG images not rendered
-
-When serving Nautobot directly from uWSGI on RedHat or CentOS there may be a problem rendering .svg images to include the Nautobot logo. On the RedHat based operating systems there is no file `/etc/mime.types` by default, unfortunately, uWSGI looks for this file to serve static files (see [Serving static files with uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/StaticFiles.html#mime-types)). To work around this copy the file `/etc/mime.types` from a known good system for example an Ubuntu/Debian system or even the Nautobot container to /opt/nautobot/mime.types. Then add the following line to your `uwsgi.ini` file and restart the Nautobot services:
-
-```no-highlight
-mime-file = /opt/nautobot/mime.types
-```
-
-Alternatively, host Nautobot behind Nginx as instructed in [HTTP server setup](http-server.md).
-
-### Test Redis Connectivity
-
-From a nautobot shell (`nautobot-server shell_plus`) use the following Python commands to test connectivity to your Redis server. If successful, python should not return any exceptions.
-
-```py
-import os
-import redis
-from nautobot.core.settings_funcs import parse_redis_connection
-
-connection = parse_redis_connection(0)
-client = redis.from_url(connection)
-client.ping() # test basic connectivity
-client.keys() # retrieve a list of keys in the redis database
-client.auth(password=os.getenv("NAUTOBOT_REDIS_PASSWORD")) # test password authentication
-```

nautobot/docs/user-guide/administration/migration/migrating-from-netbox.md

@@ -1,336 +0,0 @@
-# Migrating to Nautobot from NetBox
-
-## Review the Release Notes
-
-Be sure to carefully review all [release notes](../../../release-notes/index.md) that have been published. In particular, the [Nautobot 1.0 release notes](../../../release-notes/version-1.0.md) include an overview of key changes between NetBox 2.10 and Nautobot 1.0, while later release notes highlight incremental changes between Nautobot versions.
-
-## Install Nautobot
-
-Install Nautobot as described in [the documentation](../installation/index.md).
-
-## Configure Nautobot
-
-Although Nautobot will run perfectly well with a default configuration (such as generated by `nautobot-server init`, you may want to replicate aspects of your previous NetBox configuration to Nautobot. Refer to the [configuration documentation](../configuration/index.md) for details on the available options.
-
-## Migrate Database Contents Using `nautobot-netbox-importer`
-
-Due to a number of significant infrastructural changes between the applications, you cannot simply point Nautobot at your existing NetBox PostgreSQL database and have it automatically load your data. Fortunately, Network to Code (NTC) and collaborators have developed a Nautobot plugin, `nautobot-netbox-importer`, that can be used to import a NetBox database dump file into Nautobot. For full details, refer to [the plugin's own documentation](https://github.com/nautobot/nautobot-plugin-netbox-importer/), but here is a brief overview:
-
-1. Export your NetBox database to a JSON file.
-2. Install the importer plugin.
-3. Enable the importer plugin.
-4. Run the plugin's import command to import the data.
-5. Connect to Nautobot and verify that your data has been successfully imported.
-
-## Migrate Files from NetBox to Nautobot
-
-Uploaded media (device images, etc.) are stored on the filesystem rather than in the database and hence need to be migrated separately. The same is true for custom scripts and reports that you may wish to import.
-
-### Copy Uploaded Media
-
-The exact command will depend on where your [`MEDIA_ROOT`](../configuration/optional-settings.md#media_root) is configured in NetBox as well as where it's configured in Nautobot, but in general it will be:
-
-```no-highlight
-cp -pr $NETBOX_MEDIA_ROOT/* $NAUTOBOT_MEDIA_ROOT/*
-```
-
-### Copy Custom Scripts and Reports
-
-Similarly, the exact commands depend on your `SCRIPTS_ROOT` and `REPORTS_ROOT` settings in NetBox and your [`JOBS_ROOT`](../configuration/optional-settings.md#jobs_root) in Nautobot, but in general they will be:
-
-```no-highlight
-cp -pr $NETBOX_SCRIPTS_ROOT/* $NAUTOBOT_JOBS_ROOT/
-cp -pr $NETBOX_REPORTS_ROOT/* $NAUTOBOT_JOBS_ROOT/
-```
-
-### Update Scripts, Reports, and Plugins for Nautobot compatibility
-
-Depending on the complexity of your scripts, reports, or plugins, and how tightly integrated with NetBox they were, it may be simple or complex to port them to be compatible with Nautobot, and we cannot possibly provide a generalized step-by-step guide that would cover all possibilities. One change that you will certainly have to make to even begin this process, however, is updating the Python module names for any modules that were being imported from NetBox:
-
-- `circuits.* -> nautobot.circuits.*`
-- `dcim.* -> nautobot.dcim.*`
-- `extras.* -> nautobot.extras.*`
-- `ipam.* -> nautobot.ipam.*`
-- `netbox.* -> nautobot.core.*`
-- `tenancy.* -> nautobot.tenancy.*`
-- `utilities.* -> nautobot.core.*`
-- `virtualization.* -> nautobot.virtualization.*`
-
-+/- 2.0.0
-    The equivalent of NetBox's `utilities` module moved from `nautobot.utilities` to `nautobot.core`.
-
-### Update Your other Integration Code
-
-If you have developed any custom integrations or plugins you may need to update some of your calls. Please see the data model changes below for guidance.
-
-## Data Model Changes
-
-The following backwards-incompatible changes have been made to the data model in Nautobot.
-
-### Status Fields
-
-A new [`Status`](../../platform-functionality/status.md) model has been added to represent the `status` field for many models. Each status has a human-readable `name` field (e.g. `Active`), a `color`, a `description`, and a set of `content_types` that it can be applied to (for example, `Device` and `Location`).
-
-### Display name
-
-Several models such as device type and VLAN exposed a `display_name` property, which has now been renamed to `display`. In fact, there are several other instances, especially in the REST API, where the `display_name` field was used and as such, all instances have been renamed to `display`.
-
-#### Default Choices
-
-Because `status` fields are now stored in the database, they cannot have a default value, just like other similar objects like Device Roles or Device Types. In cases where `status` was not required to be set because it would use the default value, you must now provide a `status` yourself.  
-
-#### Choices in Code
-
-All `*StatusChoices` enums used for populated `status` field choices (such as `nautobot.dcim.choices.DeviceStatusChoices`) are deprecated. Any code you have that is leveraging these will now result in an error when performing lookups on objects with `status` fields.
-
-Anywhere you have code like this:
-
-```python
-from dcim.choices import DeviceStatusChoices
-from dcim.models import Device
-
-Device.objects.filter(status=DeviceStatusChoices.STATUS_PLANNED)
-```
-
-Update it to this:
-
-```python
-from nautobot.extras.models import Status
-from nautobot.dcim.models import Device
-
-Device.objects.filter(status=Status.objects.get(name="Planned"))
-```
-
-### UUID Primary Database Keys
-
-!!! tip
-    Primary key (aka ID) fields are no longer auto-incrementing integers and are now randomly-generated UUIDs.
-
-Database keys are now defined as randomly-generated [Universally Unique Identifiers](https://tools.ietf.org/html/rfc4122.html) (UUIDs) instead of integers, protecting against certain classes of data-traversal attacks.
-
-### Merge of UserConfig data into User model
-
-There is no longer a distinct `UserConfig` model; instead, user configuration and preferences are stored directly on the `User` model under the key `config_data`.
-
-### Custom Fields
-
-!!! tip
-    You can no longer rename or change the type of a custom field.
-
-Custom Fields have been overhauled for asserting data integrity and improving user experience.
-
-- Custom Fields can no longer be renamed or have their type changed after they have been created.
-- Choices for Custom Fields are now stored as discrete `CustomFieldChoice` database objects. Choices that are in active use cannot be deleted.
-
-### IPAM Network Field Types
-
-!!! tip
-    Nautobot 1.2 and later supports most of the same filter-based network membership queries as NetBox. See [below](#membership-lookups) and the [filtering documentation](../../platform-functionality/rest-api/filtering.md#network-and-host-fields) for more details. (Prior to Nautobot 1.2, IPAM network objects only supported model-manager-based methods for network membership filtering.)
-
-All IPAM objects with network field types (`ipam.IPAddress`, and `ipam.Prefix`) are no longer hard-coded to use PostgreSQL-only `inet` or `cidr` field types and are now using a custom implementation leveraging SQL-standard `varbinary` field types.
-
-#### Technical Details
-
-Below is a summary of the underlying technical changes to network fields. These will be explained in more detail in the following sections.
-
-- For `IPAddress`, the `address` field was exploded out to `host` and `mask_length` fields; `address` was converted into a computed field.
-- For `Prefix` objects, the `prefix` field was exploded out to `network`, `broadcast`, and `prefix_length` fields; `prefix` was converted into a computed field.
-- The `host`, `network`, and `broadcast` fields are now of a `varbinary` database type, which is represented as a packed binary integer (for example, the host `1.1.1.1` is packed as `b"\x01\x01\x01\x01"`)
-- Network membership queries are accomplished by triangulating the "position" of an address using the `host` of the `IPAddress` and the `network` and `broadcast` of the `Prefix`.
-
-!!! note
-    You should never have to worry about the binary nature of how the network fields are stored in the database! The Django database ORM takes care of it all!
-
-#### Changes to `IPAddress`
-
-The following fields have changed when working with `ipam.IPAddress` objects:
-
-##### `address` is now a computed field
-
-This field is computed from `{host}/{mask_length}` and is represented as a `netaddr.IPNetwork` object.
-
-```python
->>> ip = IPAddress(address="1.1.1.1/30")
->>> ip.address
-IPNetwork('1.1.1.1/30')
-```
-
-While this field is now a virtual field, it can still be used in many ways.
-
-It can be used to create objects:
-
-```python
->>> ip = IPAddress.objects.create(address="1.1.1.1/30")
-```
-
-It can be used in `.get()` and `.filter()` lookups where `address` is the primary argument:
-
-```python
->>> IPAddress.objects.get(address="1.1.1.1/30")
-IPNetwork('1.1.1.1/30')
->>> IPAddress.objects.filter(address="1.1.1.1/30")
-<IPAddressQuerySet [<IPAddress: 1.1.1.1/30>]>
-```
-
-!!! note
-    If you use a `mask_length` other than `/32` (IPv4) or `/128` (IPv6) it **must** be included in your lookups
-
-This field *cannot be used in **nested** filter expressions*:
-
-```python
->>> Device.objects.filter(primary_ip4__address="1.1.1.1")
-django.core.exceptions.FieldError: Related Field got invalid lookup: address
-```
-
-##### `host` contains the IP address
-
-The IP (host) component of the address is now stored in the `host` field.
-
-```python
->>> ip.host
-'1.1.1.1'
-```
-
-This field *can* be used in nested filter expressions, for example:
-
-```python
->>> Device.objects.filter(primary_ip4__host="1.1.1.1")
-```
-
-##### IPAddress `mask_length` contains the prefix length
-
-This is an integer, such as `30` for `/30`.
-
-```python
->>> ip.mask_length
-30
-```
-
-For IP addresses with a mask length other than a host prefix, you will need to filter using `host` and `mask_length` fields for greater accuracy.
-
-For example, if you have multiple `IPAddress` objects with the same `host` value but different `mask_length`:
-
-```python
->>> IPAddress.objects.create(address="1.1.1.1/32")
-<IPAddress: 1.1.1.1/32>
->>> IPAddress.objects.filter(host="1.1.1.1")
-<IPAddressQuerySet [<IPAddress: 1.1.1.1/30>, <IPAddress: 1.1.1.1/32>]>
->>> IPAddress.objects.filter(host="1.1.1.1", mask_length=30)
-<IPAddressQuerySet [<IPAddress: 1.1.1.1/30>]>
-```
-
-#### Changes to `Aggregate` and `Prefix`
-
-The following fields have changed when working with `ipam.Aggregate` and `ipam.Prefix` objects.
-
-##### `Aggregate` model merged into `Prefix`
-
-The Aggregate model has been removed in Nautobot and its functionality was moved to the Prefix model. The `rir` and `tenant` fields were directly copied over to Prefix, the `date_added` field was renamed to `date_allocated` and changed to a DateTimeField in Prefix.
-
-##### `prefix` is now a computed field
-
-This field is computed from `{network}/{prefix_length}` and is represented as a `netaddr.IPNetwork` object.
-
-While this field is now a virtual field, it can still be used in many ways.
-
-It can be used to create objects:
-
-```python
->>> net = Prefix.objects.create(prefix="1.1.1.0/24")
-```
-
-It can be used in `.get()` and `.filter()` lookups where `prefix` is the primary argument:
-
-```python
->>> Prefix.objects.get(prefix="1.1.1.0/24")
-<Prefix: 1.1.1.0/24>
->>> Prefix.objects.filter(prefix="1.1.1.0/24")
-<PrefixQuerySet [<Prefix: 1.1.1.0/24>]>
-```
-
-##### `network` contains the network address
-
-The network component of the address is now stored in the `network` field.
-
-```python
->>> net.network
-'1.1.1.0'
-```
-
-##### Prefix `prefix_length` contains the prefix length
-
-This is an integer, such as `24` for `/24`.
-
-```python
->>> net.prefix_length
-24
-```
-
-It's highly likely that you will have multiple objects with the same `network` address but varying prefix lengths, so you will need to filter using `network` and `prefix_length` fields for greater accuracy.
-
-For example, if you have multiple `Prefix` objects with the same `network` value but different `prefix_length`:
-
-```python
->>> Prefix.objects.create(prefix="1.1.1.0/25")
-<Prefix: 1.1.1.0/25>
->>> Prefix.objects.filter(network="1.1.1.0")
-<PrefixQuerySet [<Prefix: 1.1.1.0/24>, <Prefix: 1.1.1.0/25>]>
->>> Prefix.objects.filter(network="1.1.1.0", prefix_length=25)
-<PrefixQuerySet [<Prefix: 1.1.1.0/25>]>
-```
-
-##### Prefix `broadcast` contains the broadcast address
-
-The `broadcast` will be derived from the `prefix_length` and will be that of the last network address for that prefix length (e.g. `1.1.1.255`):
-
-```python
->>> Prefix.objects.get(prefix="1.1.1.0/24").broadcast
-'1.1.1.255'
-```
-
-!!! note
-    This field is largely for internal use only for facilitating network membership queries and it is not recommend that you use it for filtering.
-
-#### Membership Lookups
-
-Nautobot 1.0.x and 1.1.x did not support the custom lookup expressions that NetBox supported for membership queries on IPAM objects (such as `Prefix.objects.filter(prefix__net_contained="10.0.0.0/24")`), but instead provided an alternate approach using model manager methods (such as `Prefix.objects.net_contained("10.0.0.0/24")`).
-
-In Nautobot 1.2.0 and later, both model manager methods and custom lookup expressions are supported for this purpose, but the latter are now preferred for most use cases and are generally equivalent to their counterparts in NetBox.
-
-!!! note
-    Nautobot did not mimic the support of non-subnets for the `net_in` query to avoid mistakes and confusion caused by an IP address being mistaken for a /32 as an example.
-
-##### net_mask_length
-
-*Returns target addresses matching the source address prefix length.*
-
-!!! note
-    The NetBox filter net_mask_length should use the `prefix_length` field for filtering.
-
-NetBox:
-
-```python
-IPAddress.objects.filter(address__net_mask_length=value)
-# or
-Prefix.objects.filter(prefix__net_mask_length=value)
-```
-
-Nautobot:
-
-```python
-IPAddress.objects.filter(mask_length=value)
-# or
-Prefix.objects.filter(prefix_length=value)
-```
-
-## REST API Changes
-
-The following backwards-incompatible changes have been made to the REST API in Nautobot.
-
-### Display field
-
-In several endpoints such as device type and VLAN, a `display_name` field is used to expose a human friendly string value for the object. This field has been renamed to `display` and has been standardized across all model API endpoints.
-
-### Custom Field Choices
-
-Custom field choices are exposed in Nautobot at a dedicated endpoint: `/api/extras/custom-field-choices/`. This replaces the `choices` field on on the CustomField model and the subsequent endpoint: `/api/extras/custom-fields/`