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

nautobot/docs/user-guide/administration/tools/nautobot-shell.md

@@ -1,263 +0,0 @@
-# The Nautobot Python Shell
-
-Nautobot includes a Python management shell within which objects can be directly queried, created, modified, and deleted. To enter the shell, run the following command:
-
-```no-highlight
-nautobot-server nbshell
-```
-
-This will launch a lightly customized version of [the django-extensions `shell_plus` shell](https://django-extensions.readthedocs.io/en/latest/shell_plus.html), which is an extension of [the built-in Django shell](https://docs.djangoproject.com/en/stable/ref/django-admin/#shell) with all relevant Nautobot models pre-loaded.
-
-```no-highlight
-nautobot-server nbshell
-```
-
-Example output:
-
-```no-highlight
-# Shell Plus Model Imports
-from constance.backends.database.models import Constance
-from django.contrib.admin.models import LogEntry
-from django.contrib.auth.models import Group, Permission
-from django.contrib.contenttypes.models import ContentType
-from django.contrib.sessions.models import Session
-from django_celery_beat.models import ClockedSchedule, CrontabSchedule, IntervalSchedule, PeriodicTask, PeriodicTasks, SolarSchedule
-from django_celery_results.models import ChordCounter, GroupResult, TaskResult
-from example_plugin.models import AnotherExampleModel, ExampleModel
-from nautobot.circuits.models import Circuit, CircuitTermination, CircuitType, Provider, ProviderNetwork
-from nautobot.dcim.models.cables import Cable, CablePath
-from nautobot.dcim.models.device_component_templates import ConsolePortTemplate, ConsoleServerPortTemplate, DeviceBayTemplate, FrontPortTemplate, InterfaceTemplate, PowerOutletTemplate, PowerPortTemplate, RearPortTemplate
-from nautobot.dcim.models.device_components import ConsolePort, ConsoleServerPort, DeviceBay, FrontPort, Interface, InventoryItem, PowerOutlet, PowerPort, RearPort
-from nautobot.dcim.models.devices import Device, DeviceRedundancyGroup, DeviceType, Manufacturer, Platform, VirtualChassis
-from nautobot.dcim.models.locations import Location, LocationType
-from nautobot.dcim.models.power import PowerFeed, PowerPanel
-from nautobot.dcim.models.racks import Rack, RackGroup, RackReservation
-from nautobot.extras.models.change_logging import ObjectChange
-from nautobot.extras.models.customfields import ComputedField, CustomField, CustomFieldChoice
-from nautobot.extras.models.datasources import GitRepository
-from nautobot.extras.models.groups import DynamicGroup, DynamicGroupMembership
-from nautobot.extras.models.jobs import Job, JobHook, JobLogEntry, JobResult, ScheduledJob, ScheduledJobs
-from nautobot.extras.models.models import ConfigContext, ConfigContextSchema, CustomLink, ExportTemplate, FileAttachment, FileProxy, GraphQLQuery, HealthCheckTestModel, ImageAttachment, Note, Webhook
-from nautobot.extras.models.relationships import Relationship, RelationshipAssociation
-from nautobot.extras.models.roles import Role
-from nautobot.extras.models.secrets import Secret, SecretsGroup, SecretsGroupAssociation
-from nautobot.extras.models.statuses import Status
-from nautobot.extras.models.tags import Tag, TaggedItem
-from nautobot.ipam.models import IPAddress, Prefix, RIR, RouteTarget, Service, VLAN, VLANGroup, VRF
-from nautobot.tenancy.models import Tenant, TenantGroup
-from nautobot.users.models import AdminGroup, ObjectPermission, Token, User
-from nautobot.virtualization.models import Cluster, ClusterGroup, ClusterType, VMInterface, VirtualMachine
-from social_django.models import Association, Code, Nonce, Partial, UserSocialAuth
-# Shell Plus Django Imports
-from django.core.cache import cache
-from django.conf import settings
-from django.contrib.auth import get_user_model
-from django.db import transaction
-from django.db.models import Avg, Case, Count, F, Max, Min, Prefetch, Q, Sum, When
-from django.utils import timezone
-from django.urls import reverse
-from django.db.models import Exists, OuterRef, Subquery
-# Django version 3.2.18
-# Nautobot version 2.0.0a2
-# Example Nautobot App version 1.0.0
-Python 3.8.16 (default, Mar 23 2023, 04:48:11)
-[GCC 10.2.1 20210110] on linux
-Type "help", "copyright", "credits" or "license" for more information.
-(InteractiveConsole)
->>>
-```
-
-As you can see from the above output, the Nautobot shell automatically loads all relevant database models, including those built-in to Django, those provided by Nautobot itself, and those provided by any installed Nautobot apps. It also loads a number of useful Django utilities as well.
-
-!!! warning
-    The Nautobot shell affords direct access to Nautobot data and function with very little validation in place. As such, it is crucial to ensure that only authorized, knowledgeable users are ever granted access to it. Never perform any action in the management shell without having a full backup in place.
-
-## Querying Objects
-
-Objects are retrieved from the database using a [Django queryset](https://docs.djangoproject.com/en/stable/topics/db/queries/#retrieving-objects). The base queryset for an object takes the form `<model>.objects.all()`, which will return a (truncated) list of all objects of that type.
-
-```python
->>> Device.objects.all()
-<QuerySet [<Device: TestDevice1>, <Device: TestDevice2>, <Device: TestDevice3>,
-<Device: TestDevice4>, <Device: TestDevice5>, '...(remaining elements truncated)...']>
-```
-
-Use a `for` loop to cycle through all objects in the list:
-
-```python
->>> for device in Device.objects.all():
-...   print(device.name, device.device_type)
-...
-('TestDevice1', <DeviceType: PacketThingy 9000>)
-('TestDevice2', <DeviceType: PacketThingy 9000>)
-('TestDevice3', <DeviceType: PacketThingy 9000>)
-('TestDevice4', <DeviceType: PacketThingy 9000>)
-('TestDevice5', <DeviceType: PacketThingy 9000>)
-...
-```
-
-To count all objects matching the query, replace `all()` with `count()`:
-
-```python
->>> Device.objects.count()
-1274
-```
-
-To retrieve a particular object (typically by its primary key or other unique field), use `get()`:
-
-```python
->>> Location.objects.get(pk="8a2c9c3b-076e-4688-8a0b-89362f343a26")
-<Location: Test Lab>
-```
-
-### Filtering Querysets
-
-In most cases, you will want to retrieve only a specific subset of objects. To filter a queryset, replace `all()` with `filter()` and pass one or more keyword arguments. For example:
-
-```python
->>> Device.objects.filter(status__name="Active")
-<QuerySet [<Device: TestDevice1>, <Device: TestDevice2>, <Device: TestDevice3>,
-<Device: TestDevice8>, <Device: TestDevice9>, '...(remaining elements truncated)...']>
-```
-
-Querysets support slicing to return a specific range of objects.
-
-```python
->>> Device.objects.filter(status__name="Active")[:3]
-<QuerySet [<Device: TestDevice1>, <Device: TestDevice2>, <Device: TestDevice3>]>
-```
-
-The `count()` method can be appended to the queryset to return a count of objects rather than the full list.
-
-```python
->>> Device.objects.filter(status__name="Active").count()
-982
-```
-
-Relationships with other models can be traversed by concatenating attribute names with a double-underscore. For example, the following will return all devices assigned to the tenant named "Pied Piper."
-
-```python
->>> Device.objects.filter(tenant__name="Pied Piper")
-```
-
-This approach can span multiple levels of relations. For example, the following will return all IP addresses assigned to a device in North America:
-
-```python
->>> IPAddress.objects.filter(interfaces__device__location__name="North America")
-```
-
-!!! note
-    While the above query is functional, it's not very efficient. There are ways to optimize such requests, however they are out of scope for this document. For more information, see the [Django queryset method reference](https://docs.djangoproject.com/en/stable/ref/models/querysets/) documentation.
-
-Reverse relationships can be traversed as well. For example, the following will find all devices with an interface named "em0":
-
-```python
->>> Device.objects.filter(interfaces__name="em0")
-```
-
-Character fields can be filtered against partial matches using the `contains` or `icontains` field lookup (the later of which is case-insensitive).
-
-```python
->>> Device.objects.filter(name__icontains="testdevice")
-```
-
-Similarly, numeric fields can be filtered by values less than, greater than, and/or equal to a given value.
-
-```python
->>> VLAN.objects.filter(vid__gt=2000)
-```
-
-Multiple filters can be combined to further refine a queryset.
-
-```python
->>> VLAN.objects.filter(vid__gt=2000, name__icontains="engineering")
-```
-
-To return the inverse of a filtered queryset, use `exclude()` instead of `filter()`.
-
-```python
->>> Device.objects.count()
-4479
->>> Device.objects.filter(status="active").count()
-4133
->>> Device.objects.exclude(status="active").count()
-346
-```
-
-!!! info
-    The examples above are intended only to provide a cursory introduction to queryset filtering. For an exhaustive list of the available filters, please consult the [Django queryset API documentation](https://docs.djangoproject.com/en/stable/ref/models/querysets/).
-
-## Creating and Updating Objects
-
-New objects can be created by instantiating the desired model, defining values for all required attributes, and calling `validated_save()` on the instance. For example, we can create a new VLAN by specifying its numeric ID, name, and assigned location:
-
-```python
->>> lab1 = Location.objects.get(pk="8a2c9c3b-076e-4688-8a0b-89362f343a26")
->>> myvlan = VLAN(vid=123, name="MyNewVLAN", location=lab1)
->>> myvlan.validated_save()
-```
-
-Alternatively, the above can be performed as a single operation. (Note, however, that `validated_save()` does _not_ return the new instance for reuse.)
-
-```python
->>> VLAN(vid=123, name="MyNewVLAN", location=Location.objects.get(pk="8a2c9c3b-076e-4688-8a0b-89362f343a26")).validated_save()
-```
-
-To modify an existing object, we retrieve it, update the desired field(s), and call `validated_save()` again.
-
-```python
->>> vlan = VLAN.objects.get(pk="b4b4344f-f6bb-4ceb-85bc-4f169c753157")
->>> vlan.name
-'MyNewVLAN'
->>> vlan.name = 'BetterName'
->>> vlan.validated_save()
->>> VLAN.objects.get(pk="b4b4344f-f6bb-4ceb-85bc-4f169c753157").name
-'BetterName'
-```
-
-!!! warning
-    It is recommended to make use of the `validated_save()` convenience method which exists on all core models. While the Django `save()` method still exists, the `validated_save()` method saves the instance data but first enforces model validation logic. Simply calling `save()` on the model instance **does not** enforce validation automatically and may lead to bad data. See the development [best practices](../../../development/core/best-practices.md).
-
-!!! warning
-    The Django ORM provides methods to create/edit many objects at once, namely `bulk_create()` and `update()`. These are best avoided in most cases as they bypass a model's built-in validation and can easily lead to database corruption if not used carefully.
-
-## Deleting Objects
-
-To delete an object, simply call `delete()` on its instance. This will return a dictionary of all objects (including related objects) which have been deleted as a result of this operation.
-
-```python
->>> vlan
-<VLAN: 123 (BetterName)>
->>> vlan.delete()
-(1, {'ipam.VLAN': 1})
-```
-
-To delete multiple objects at once, call `delete()` on a filtered queryset. It's a good idea to always sanity-check the count of selected objects _before_ deleting them.
-
-```python
->>> Device.objects.filter(name__icontains='test').count()
-27
->>> Device.objects.filter(name__icontains='test').delete()
-(35, {'dcim.DeviceBay': 0, 'dcim.InterfaceConnection': 4,
-'extras.ImageAttachment': 0, 'dcim.Device': 27, 'dcim.Interface': 4,
-'dcim.ConsolePort': 0, 'dcim.PowerPort': 0})
-```
-
-!!! warning
-    Deletions are immediate and irreversible. Always consider the impact of deleting objects carefully before calling `delete()` on an instance or queryset.
-
-## Change Logging and Webhooks
-
-Note that Nautobot's change logging and webhook processing features operate under the context of an HTTP request. As such, these functions do not work automatically when using the ORM directly, either through the Nautobot shell or otherwise. A special context manager is provided to allow these features to operate under an emulated HTTP request context. This context manager must be explicitly invoked for change log entries and webhooks to be created when interacting with objects through the ORM. Here is an example using the `web_request_context` context manager within the Nautobot shell:
-
-```python
->>> from nautobot.extras.context_managers import web_request_context
->>> user = User.objects.get(username="admin")
->>> with web_request_context(user):
-...     location_type = LocationType.objects.get(name="Airport")
-...     status = Status.objects.get_for_model(Location).first()
-...     lax = Location(name="LAX", location_type=location_type, status=status)
-...     lax.validated_save()
-```
-
-A `User` object must be provided. A `WSGIRequest` may optionally be passed and one will automatically be created if not provided.

nautobot/docs/user-guide/administration/upgrading/database-backup.md

@@ -1,11 +0,0 @@
-# Backing up the Nautobot Database
-
-Before any upgrade of Nautobot, and as a general best practice, you'll want to back up the underlying database. This is important both from a general high-availability and error-recovery standpoint, and also specifically in case of any Nautobot update that includes database changes (which is most of them) as in general Nautobot does not guarantee that all database changes made during an upgrade will be reversible. If anything goes wrong during a Nautobot update, your database may be left in a bad/invalid state and your best recourse will be to restore from backup.
-
-## Backing up PostgreSQL
-
-Refer to [Backup and Restore](https://www.postgresql.org/docs/current/backup.html) in the PostgreSQL documentation for the various approaches to database backup that are recommended with PostgreSQL.
-
-## Backing up MySQL
-
-Refer to [Backup and Recovery](https://dev.mysql.com/doc/refman/8.1/en/backup-and-recovery.html) in the MySQL documentation for the various approaches to database backup that are recommended with MySQL.

nautobot/docs/user-guide/administration/upgrading/from-v1/ipam/after-you-upgrade.md

@@ -1,55 +0,0 @@
-# After you Upgrade
-
-This section includes various things to consider after you have successfully upgraded to Nautobot 2.0.
-
-## Review any Cleanup or VRF Namespaces
-
-> This may also apply to any "VRF Namespace" objects that were created, depending on your requirements on maintaining duplicate Prefix/IPAddress objects.
-
-A priority of the upgrade process is to assert that no data will be lost. Due to the introduction of strict uniqueness constraints to disallow duplicate `Prefix`, `IPAddress`, and `VRF` objects within the same `Namespace`, depending on the nature of your data, you may have numerous "VRF" or "Cleanup" Namespaces that were automatically created by the upgrade process as described in the previous section.
-
-### A word on Tenant affinity
-
-A best effort is made to keep `Prefixes` and `IPAddresses` together in the same `Namespace` by shared attributes such as `Tenant`, but this is not always possible for various reasons such as numerous duplicates with identical or too-closely-similar criteria.
-
-For more information on how this is done please see the section [Parenting affinity during the upgrade](./whats-changed.md#parenting-affinity-during-the-upgrade) above.
-
-If you find that you have objects that were moved to the wrong Namespaces, you might try the next section on swapping Namespaces.
-
-### Swapping Namespaces
-
-If you need to swap a duplicate object into another `Namespace` (say "Global" and "Cleanup Namespace 1") where it conflicts with one in the desired `Namespace`, you can use this basic strategy to facilitate moving duplicate objects between `Namespaces` by using a temporary interstitial `Namespace`.
-
-In this example we'll use three `Namespaces`. "Global", the `Namespace` in which you have duplicate objects that are found in "Cleanup Namespace 1", but you would like them to be the "Global" Namespace. We'll create a third Namespace called "Temporary" to act as the go-between to temporarily hold objects from one `Namespace` that we want to swap into another.
-
-- First, Create a new  Namespace named "Temporary"
-- Next, edit any desired objects you want to swap in objects from the "Global" Namespace and update their Namespace to "Temporary"
-    - After performing this step, there should be no duplicates found in the "Global" Namespace
-- Next, edit the duplicate objects you want moved in from "Cleanup Namespace 1" and set their Namespace to "Global".
-    - After performing this step there should be no duplicates found in the "Cleanup Namespace 1" Namespace, as they've been moved to "Global"
-- Finally, edit the original objects found in the "Temporary" Namespace that were moved from "Global" to "Temporary" and set their Namespace "Cleanup Namespace 1"
-    - After performing this final step, the duplicate objects that were originally in the "Global" have now been swapped with those that were originally in the "Cleanup Namespace 1" Namespace.
-    - There are no duplicate objects found in the "Temporary" Namespace. This Namespace can safely be deleted.
-- Delete the "Temporary" Namespace when done.
-
-## Merge duplicate IP Addresses
-
-After upgrading to Nautobot v2.0 and running the data migrations necessary, duplicate `IPAddress` objects might exist in your database. We define duplicate `IPAddress` objects as those which have the same `host` attribute but exist in different `Namespaces`. If you have no use case to keep those duplicate `IPAddress` objects around, we recommend you to use this tool to de-duplicate those `IPAddress` objects and keep your database clean and manageable. But if you do have reasons to maintain duplicate `IPAddress` objects, this tool is not for you.
-
-For more information, please see the [documentation on the Duplicate IP Address Merge Tool](../../../../feature-guides/ip-address-merge-tool.md).
-
-## Delete duplicate objects
-
-Because preventing data loss is prioritized, some objects that may have been required to be duplicates before may no longer be needed. For objects that weren't covered by the Duplicate IP Address Merge Tool, deleting objects might be your next course of action.
-
-Some examples include:
-
-- The same `IPAddress` assigned to multiple `Interfaces/VMInterfaces`. Where possible, a single `IPAddress` is now assigned leaving duplicate objects across other Namespaces to be potentially no longer necessary.
-- `VRFs` that were used strictly for custom uniqueness boundaries with `enforce_unique` set to `True` may not necessarily be needed.
-
-## Cleanup your config
-
-Remove the now-deprecated settings from your `nautobot_config.py`:
-
-- `DISABLE_PREFIX_LIST_HIERARCHY`
-- `ENFORCE_GLOBAL_UNIQUE`

nautobot/docs/user-guide/administration/upgrading/from-v1/ipam/before-you-upgrade.md

@@ -1,73 +0,0 @@
-# Before you Upgrade
-
-This section covers how you can prepare your IPAM Data for Nautobot 2.0.
-
-## Run the pre-migration helper before upgrading
-
-A new pre-migration management command was added that will allow you to check your existing data for compatibility with the data model changes introduced in Nautobot 2.0. You are highly encouraged to run this before upgrading!
-
-For more information please see the [documentation on Pre-migration validation](../upgrading-from-nautobot-v1.md#pre-migration-validation).
-
-## You cannot migrate Interfaces or VMInterfaces that have IPs with differing VRFs
-
-When assigning a `VRF` to an`IPaddress`, the `VRF` must be the same across each IP when multiple `IPAddress` objects are assigned to `Interface`/`VMInterface` objects.
-
-Make sure for `Interfaces`/`VMInterfaces` with multiple IPs that each `IPAddress`1 assigned to the same `Interface`/`VMInterface` share the same VRF, or are not assigned a VRF.
-
-## Parent Prefixes, child Prefixes, and child IPAddresses must share the same Namespace
-
-Parent `Prefixes`, child `Prefixes`, and `IPAddresses` must share the same `Namespace` and any case for duplicate `Prefix`/`IPAddress` must involve leveraging distinct `Namespace` objects.
-
-If you need to maintain duplicates for any reason, assert that each set of duplicate objects are assigned to a distinct `VRF` with `enforce_unique` set to `True`, as during the upgrade process these will each be moved to their own "VRF Namespace". Please see the section on [VRF Namespaces](#vrf-namespaces) below for more information.
-
-## IPAddress objects can no longer be orphaned
-
-`IPAddresses` must now always have a parent `Prefix` to contain them. Any `IPAddress` that does not have a parent is considered to be "orphaned" and as of Natutobot 2.0 this is not allowed.
-
-When upgrading to Nautobot 2.0, the database migration will automatically create a parent `Prefix` for `IPAddresses` that do not have an eligible parent `Prefix`. For example an `IPAddress` with address of `1.2.3.4/32` will have a parent `Prefix` created of the same `network` and `prefix_length` e.g. `1.2.3.4/32`.
-
-If you do not wish for these single-host `Prefixes` to be created, create a parent `Prefix` of your desired size to contain any would-be orphaned `IPAddresses` before upgrading.
-
-## Prepare for Namespaces
-
-After upgrading, there will be two distinct sets of extra `Namespace` objects created based on specific conditions of your data set.
-
-First, any `VRF` objects with `enforce_unique` enabled (which is the default), will be moved to "VRF Namespace" objects. Second, any duplicate objects will be moved to "Cleanup Namespace" objects.
-
-Each of these are covered below.
-
-### Cleanup Namespaces
-
-After upgrading, any duplicate objects that were found in the "Global" Namespace will be moved to one or more "Cleanup" Namespaces. Cleanup Namespaces are named numerically. When duplicate objects are identified that are not associated with a VRF that has `enforce_unique` set to `True`, each Cleanup Namespace will be enumerated until one that does not have conflicting objects can be found. If one cannot be found, a new Cleanup Namespace will be created.
-
-For example, the very first duplicate `Prefix` found will be moved to a Namespace named "Cleanup Namespace 1". For each pass that identifies a duplicate of an object in an existing Namespace, new Namespaces will be created by incrementing the number resulting in "Cleanup Namespace 2", "Cleanup Namespace 3", etc.
-
-Because Cleanup Namespaces will be created to avoid data loss, there is little you can do to avoid their creation during the upgrade process. You may want to review your Cleanup Namespaces or swap objects around between other Namespaces.
-
-Please [review any Cleanup Namespaces](./after-you-upgrade.md#review-any-cleanup-or-vrf-namespaces) after you upgrade.
-
-### VRF Namespaces
-
-For `VRF` objects that had `enforce_unique` enabled with `Prefixes` assigned to them, any child `Prefixes` or child `IPAddresses` of those `Prefixes` will be moved to a "VRF Namespace" with the name of the `VRF` included.
-
-For example, if the `VRF` is named "Blue" and has `Prefixes` assigned to it, the `VRF`, all `Prefixes` assigned to it, and any child `Prefixes` or `IPAddresses` will be moved to a new `Namespace` with the name "VRF Namespace Blue".
-
-If you wish to reduce the need for creation of VRF Namespaces, review your existing `VRF` objects with `enforce_unique` enabled to identify their relevance. If you do not require enforcing uniqueness in the VRF itself, you may toggle `enforce_unique` to tell Nautobot to handle any potential duplicates globally instead, which may result in duplicate objects being moved to Cleanup Namespaces that will need to be reviewed following the upgrade process.
-
-Please [review any Cleanup or VRF Namespaces](./after-you-upgrade.md#review-any-cleanup-or-vrf-namespaces) after you upgrade.
-
-## Aggregate model was merged into Prefix
-
-The `Aggregate` model was removed and all existing aggregates will be migrated to `Prefix` with type set to `Container`. The `Aggregate.date_added` field will be migrated to `Prefix.date_allocated` and changed from a `Date` field to a `DateTime` field with the time set to `00:00`. The fields `Aggregate.tenant`, `Aggregate.rir`, and `Aggregate.description` will be migrated over to the same fields on `Prefix`.
-
-If a `Prefix` already exists with the same network and prefix length as a previous `Aggregate`, the `rir` and `date_added` fields will be copied to the `rir` and `date_allocated` fields on the existing Prefix object. Messages will be output during migration (`nautobot-server migrate` or `nautobot-server post_upgrade`) if the `tenant`, `description` or `type` fields need to be manually migrated.
-
-| Aggregate        | Prefix               |
-|------------------|----------------------|
-| `broadcast`      | `broadcast`          |
-| **`date_added`** | **`date_allocated`** |
-| `description`    | `description`        |
-| `network`        | `network`            |
-| `prefix_length`  | `prefix_length`      |
-| `rir`            | `rir`                |
-| `tenant`         | `tenant`             |

nautobot/docs/user-guide/administration/upgrading/from-v1/ipam/for-developers.md

@@ -1,211 +0,0 @@
-# For Developers
-
-This section covers technical changes to the underlying data models and programmable interfaces and is intended for developers or integrators to help facilitate any necessary changes to functional code in Apps/plugins that extend Nautobot.
-
-## Database (ORM) Changes
-
-### Database Field Behavior Changes
-
-| Model     | Field           | Changes                                                      |
-| :-------- | :-------------- | :----------------------------------------------------------- |
-| IPAddress | role            | Changed from `CharField` to a `ForeignKey` to the new `Role` model. |
-| IPAddress | primary_ip4_for | Now a list as the reverse relation for the `Device.primary_ip4` foreign key |
-| IPAddress | primary_ip6_for | Now a list as the reverse relation for the `Device.primary_ip6` foreign key |
-| Prefix    | is_pool         | Replaced by new field `type`, valid choices are "Container", "Network" and "Pool" |
-| Prefix    | namespace       | New required foreign key to Namespace, defaulting to 'Global' |
-| Prefix    | status          | "Container" status has been replaced by new field `type`     |
-| VRF       | namespace       | New required foreign key to Namespace, defaulting to 'Global' |
-
-### Renamed Database Fields
-
-Most renamed database fields in Nautobot 2.0 fall into the following general categories:
-
-1. Renaming of foreign keys and reverse relations to more consistently and specifically match the related model name or plural name (for example, `Circuit.terminations` to `Circuit.circuit_terminations`, `Rack.group` to `Rack.rack_group`)
-2. Explicitly for the `IPAddress` and `Prefix` models, `family`, a derived field, was replaced with `ip_version`, a concrete integer field that may be used in query filters.
-
-| Model     | Renamed Field | New Name     |
-| :-------- | :------------ | :----------- |
-| IPAddress | family        | ip_version   |
-| IPAddress | prefix_length | mask_length  |
-| Prefix    | family        | ip_version   |
-| Service   | ipaddresses   | ip_addresses |
-| VLAN      | group         | vlan_group   |
-
-### Removed Database Fields
-
-Most removed database fields in Nautobot 2.0 fall into the following general categories:
-
-1. Removal of references to removed models such as `Site` and `Region`
-2. Removal of `slug` fields in preference to the use of the natural key.
-
-| Model       | Removed Field   | Comments                                                     |
-| :---------- | :-------------- | :----------------------------------------------------------- |
-| IPAddress   | assigned_object | Replaced by `interfaces` and `vm_interfaces` many-to-many relations |
-| IPAddress   | broadcast       | Use parent Prefix's broadcast instead                        |
-| IPAddress   | vrf             | VRF is now related to the assigned Interface(s), as well as the parent Prefix |
-| Prefix      | is_pool         | Replaced by new `type` field                                 |
-| Prefix      | site            | Use `location` instead                                       |
-| Prefix      | vrf             | Replaced by `vrf_assignments` many-to-many relation          |
-| RouteTarget | slug            |                                                              |
-| VLAN        | site            | Use `location` instead                                       |
-| VLANGroup   | site            | Use `location` instead                                       |
-| VLANGroup   | slug            |                                                              |
-| VRF         | enforce_unique  | Uniqueness of Prefixes and IPAddresses is now enforced by the database |
-
-### Replaced Models
-
-The `ipam.Role`  model has been removed and replaced by a single `extras.Role` model. This means that any references to the removed models in the code now use the `extras.Role` model instead.
-
-| Removed Model | Replaced With |
-| :------------ | :------------ |
-| `ipam.Role`   | `extras.Role` |
-
-## GraphQL and REST API Changes Changes
-
-### API Behavior changes
-
-Most of the API behavior changes in Nautobot 2.0 fall into the following general categories:
-
-1. The `created` field on most models has changed from a date only ("2023-04-06") to being a date/time ("2023-04-06T19:57:45.320232Z")
-2. The `status` fields on various models has changed from a pseudo-enum value (containing a "value" and a "label") to referencing the related Status object in full, similar to other foreign-key fields.
-3. Various models that had a required `site` field and an optional `location` field now have a required `location` field.
-
-| Model     | Field     | Changes                                                      |
-| :-------- | :-------- | :----------------------------------------------------------- |
-| IPAddress | parent    | A new foreign-key to `Prefix`. Required on creation, if `namespace` isn't provided, to find a correct parent Prefix |
-| IPAddress | role      | Now is a foreign-key to `Role` rather than a string          |
-| IPAddress | status    | Now is a foreign-key rather than a pseudo-enum               |
-| Prefix    | namespace | New required foreign key to Namespace, defaulting to 'Global' |
-| Prefix    | status    | Now is a foreign-key rather than a pseudo-enum               |
-| VLAN      | status    | Now is a foreign-key rather than a pseudo-enum               |
-| VRF       | namespace | New required foreign key to Namespace, defaulting to 'Global' |
-
-### Renamed Serializer Fields
-
-Most renamed API fields in Nautobot 2.0 fall into the following general categories:
-
-1. Renaming of foreign keys and reverse relations to more consistently and specifically match the related model name or plural name (for example, `Circuit.type` to `Circuit.circuit_type`, `Interface.count_ipaddresses` to `Interface.ip_address_count`)
-
-| Model     | Renamed Field | New Name   |
-| :-------- | :------------ | :--------- |
-| IPAddress | family        | ip_version |
-| Prefix    | family        | ip_version |
-| VLAN      | group         | vlan_group |
-
-### Removed Serializer Fields
-
-Most removed database fields in Nautobot 2.0 fall into the following general categories:
-
-1. Removal of references to removed models such as `Site` and `Region`
-2. Removal of `slug` fields in preference to the use of the natural key.
-
-| Model/Endpoint | Removed Field   | Comments                                                     |
-| :------------- | :-------------- | :----------------------------------------------------------- |
-| IPAddress      | assigned_object | Changed to many-to-many field. Use the REST API view for `IPAddressToInterface`(/api/ipam/ip-address-to-interface/) to create/modify/delete associations or `interfaces`/`vm_interfaces` on this model to retrieve a list of associated interfaces. |
-| IPAddress      | broadcast       | Use parent Prefix's broadcast instead                        |
-| IPAddress      | vrf             | VRF is now related to the assigned Interface(s), as well as the parent Prefix |
-| Prefix         | is_pool         | Use `type` instead                                           |
-| Prefix         | vrf             | Prefixes are now assigned to a VRF in the same Namespace via a many-to-many relationship |
-| Prefix         | site            | Use `location` instead                                       |
-| RouteTarget    | slug            |                                                              |
-| VLAN           | site            | Use `location` instead                                       |
-| VLANGroup      | site            | Use `location` instead                                       |
-| VLANGroup      | slug            |                                                              |
-| VRF            | enforce_unique  | Uniqueness of Prefixes and IPAddresses is now enforced at the database level |
-
-### Replaced Endpoints
-
-The endpoint `/ipam/roles/` is no longer available. Instead, use the `/extras/roles/` endpoint to retrieve and manipulate `role` data.
-
-| Removed Endpoints | Replaced With    |
-| :---------------- | :--------------- |
-| `/ipam/roles/`    | `/extras/roles/` |
-
-## UI, GraphQL, and REST API Filter Changes
-
-### Renamed Filter Fields
-
-Most renamed filter fields in Nautobot 2.0 fall into the following general categories:
-
-1. The `tag` filter is renamed to `tags` on all models supporting Tags.
-2. Renames to match renamed model/serializer fields as described earlier in this document.
-3. Related membership filters are renamed to `has_<related>` throughout, for example `ConsolePort.cabled` is renamed to `ConsolePort.has_cable`.
-4. Most `<related>_id` filters have been merged into the corresponding `<related>` filter (see ["Enhanced Filter Fields"](#enhanced-filter-fields) below).
-
-| Model       | Renamed Filter        | New Name                  | Renamed Field |
-| :---------- | :-------------------- | :------------------------ | :------------ |
-| IPAddress   | assigned_to_interface | has_interface_assignments |               |
-| IPAddress   | family                | ip_version                |               |
-| IPAddress   | parent                | prefix                    |               |
-| IPAddress   | tag                   | tags                      |               |
-| Prefix      | family                | ip_versionip_version      |               |
-| Prefix      | is_pool               | type                      |               |
-| Prefix      | tag                   | tags                      |               |
-| RouteTarget | tag                   | tags                      |               |
-| Service     | tag                   | tags                      |               |
-| VLAN        | group                 | vlan_group                |               |
-| VLAN        | tag                   | tags                      |               |
-| VRF         | tag                   | tags                      |               |
-
-### Enhanced Filter Fields
-
-Below is a table documenting [enhanced filter field changes](../../../../../release-notes/version-2.0.md#enhanced-filter-fields-2804) in Nautobot 2.0. These enhancements mostly fall into the following general categories:
-
-1. Many filters are enhanced to permit filtering by UUID *or* by name.
-2. Filters that previously only supported a single filter value can now filter on multiple values.
-
-| Model       | Filter              | Enhancements                         |
-| :---------- | :------------------ | :----------------------------------- |
-| IPAddress   | mask_length         | Filtering on multiple integer values |
-| IPAddress   | rir                 | Filter by UUID or by name            |
-| IPAddress   | tenant              | Filter by UUID or by name            |
-| IPAddress   | tenant_group        | Filter by UUID or by name            |
-| Prefix      | rir                 | Filter by UUID or by name            |
-| Prefix      | tenant              | Filter by UUID or by name            |
-| Prefix      | tenant_group        | Filter by UUID or by name            |
-| RouteTarget | tenant              | Filter by UUID or by name            |
-| RouteTarget | tenant_group        | Filter by UUID or by name            |
-| VLAN        | available_on_device | Filtering on multiple values         |
-| VLAN        | tenant              | Filter by UUID or by name            |
-| VLAN        | tenant_group        | Filter by UUID or by name            |
-| VLAN        | vlan_group          | Filter by UUID or by name            |
-| VRF         | tenant              | Filter by UUID or by name            |
-| VRF         | tenant_group        | Filter by UUID or by name            |
-
-### Corrected Filter Fields
-
-Below is a table documenting [corrected filter field changes](../../../../../release-notes/version-2.0.md#corrected-filter-fields-2804) in Nautobot 2.0. These corrections mostly involve filters that previously permitted filtering on related membership only (`/api/dcim/devices/?console_ports=True`) and have now been corrected into filters for related membership (`/api/dcim/devices/?has_console_ports=True`) as well as by actual related objects (`/api/dcim/devices/?console_ports=<UUID>`).
-
-| Model     | Filter | Correction                                                   |
-| :-------- | :----- | :----------------------------------------------------------- |
-| IPAddress | parent | The `parent` filter now checks for an exact match of the parent Prefix; for legacy `net_host_contained` behavior now use the new `prefix` filter instead |
-
-### Removed Filter Fields
-
-Below is a table documenting [removed filter field changes](../../../../../release-notes/version-2.0.md#removed-redundant-filter-fields-2804) in v2.x. Most removed database fields in Nautobot 2.0 fall into the following general categories:
-
-1. Removal of `*_id=<uuid>` filters as they have have been merged into filters that support both uuid and name/slug (for example, instead of `/api/circuits/circuits/?provider_id=<UUID>`, use `/api/circuits/circuits/?provider=<uuid>`).
-2. Removal of filtering on removed models such as `Region` and `Site`. (Use `location` filters instead.)
-3. Removal of `slug` filters from models that no longer have a `slug` field.
-
-| Model       | Removed Filter  | Comments                |
-| :---------- | :-------------- | :---------------------- |
-| Prefix      | region          |                         |
-| Prefix      | region_id       |                         |
-| Prefix      | site            |                         |
-| Prefix      | site_id         |                         |
-| Prefix      | vrf_id          | Use vrf filter instead  |
-| RouteTarget | slug            |                         |
-| RouteTarget | tenant_group_id |                         |
-| VLAN        | group_id        | Use `vlan_group` filter |
-| VLAN        | region          |                         |
-| VLAN        | region_id       |                         |
-| VLAN        | site            |                         |
-| VLAN        | site_id         |                         |
-| VLAN        | tenant_group_id |                         |
-| VLANGroup   | region          |                         |
-| VLANGroup   | region_id       |                         |
-| VLANGroup   | site            |                         |
-| VLANGroup   | site_id         |                         |
-| VLANGroup   | slug            |                         |
-| VRF         | tenant_group_id |                         |

nautobot/docs/user-guide/administration/upgrading/from-v1/ipam/index.md

@@ -1,16 +0,0 @@
-# Nautobot 2.0 IPAM Migration Guide
-
-## Goal
-
-This document aims to answer the question "What do I need to do to my data (or what changes with my data) when migrating to 2.0, specifically IPAM?"
-
-Each change is covered in detail to describe the changes, their impact, and the underlying reasons why the changes were made.
-
-Please see the individual sections for more details.
-
-## Sections
-
-- [What's Changed](whats-changed.md)
-- [Before you Upgrade](before-you-upgrade.md)
-- [After you Upgrade](after-you-upgrade.md)
-- [For Developers](for-developers.md)