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

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

@@ -1,157 +0,0 @@
-# What's Changed
-
-This section details the high-level changes as it relates to the data modeling for IPAM objects. Some of the sections are repeating content found in the release notes with detail added for improved readability. Additionally, not all changes described will be distinctly related to IPAM, but if there were changes to relationships to or from IPAM data models, the impact of those changes will be described here.
-
-## Namespaces were introduced
-
-The new `Namespace` model expands on the functionality previously provided by `VRF.enforce_unique` and the `ENFORCE_GLOBAL_UNIQUE` setting, both of which have now been removed. Within a Namespace, all VRFs, Prefixes, and IP addresses must be unique. This enables greater flexibility in managing discrete duplicate `VRF`, `Prefix` or `IPAddress` objects, asserting that each set of duplicates will be in a distinct `Namespace`.
-
-For more details please refer to the [Namespace model documentation](../../../../core-data-model/ipam/namespace.md).
-
-### Sample Namespace Implementation Diagram
-
-![IPAM Namespace Example](../../../../core-data-model/ipam/media/ipam_namespace_documentation.drawio.svg)
-
-### Default Namespace
-
-A default `Namespace` object named "Global" will be created for you. All objects that did not have duplicates found will be found in this Namespace. All new objects will default to this Namespace unless otherwise specified.
-
-## Role model is now Generic across Nautobot
-
-The `DeviceRole`, `RackRole`, `ipam.Role`, and `IPAddressRoleChoices` have all been removed and replaced with an `extras.Role` model. This means that all references to any of the replaced models and choices now points to this generic `Role` model.
-
-In addition, the `role` field of the `IPAddress` model will be changed from a choice field to a foreign key field related to the `extras.Role` model.
-
-For more details please refer to the [documention on Roles](../../../../platform-functionality/role.md).
-
-## Prefix Parenting Concrete Relationship was added
-
-The `Prefix` model was modified to have a self-referencing foreign key as the `parent` field. Parenting of prefixes is now automatically managed at the database level to greatly improve performance especially when calculating tree hierarchy and utilization.
-
-As a result of this change, it is no longer necessary nor possible to disable tree hierarchy using `settings.DISABLE_PREFIX_LIST_HIERARCHY` as this setting has been removed. Additionally it is no longer possible to disable global uniqueness using `settings.ENFORCE_GLOBAL_UNIQUE` as this setting has been removed.
-
-### Prefix Parenting Guidance
-
-The following guidance has been added for the `Prefix` model in order to ensure more accurate network modeling:
-
-- A `Prefix` of type `Container` should only have a parent (if any) of type `Container`
-- A `Prefix` of type `Network` should only have a parent (if any) of type `Container`
-- A `Prefix` of type `Pool` should only have a parent (if any) of type `Network`
-- Any `Prefix` can be a root prefix (i.e. have no parent)
-
-In Nautobot 2.0, creating or updating prefixes that violate this guidance will result in a warning; in a future Nautobot release this will be changed to an enforced data constraint.
-
-## Prefix.is_pool field and "Container" status replaced by new field Prefix.type
-
-A new type field was added to `Prefix` to replace the `is_pool` boolean field and the "Container" `status`. The `type` field can be set to "Network", "Pool" or "Container", with "Network" being the default.
-
-Existing `Prefixes` with a `status` of "Container" will be migrated to the "Container" `type`. Existing prefixes with `is_pool` set are migrated to the "Pool" `type`. Prefixes with both `is_pool set` and a `status` of "Container" are migrated to the "Pool" `type`.
-
-The "Container" `status` will be removed and all prefixes will be migrated to the "Active" `status` if it exists. If the "Active" `status` does not exist, prefixes will instead be migrated to the first available `Prefix` `status` in the database that is not "Container".
-
-## Prefix utilization calculations were revamped
-
-The `get_utilization` method on the `ipam.Prefix` model has been updated in 2.0 to account for the `Prefix.type` field as described above under **Prefix Parenting Guidance**. The behavior is now as follows:
-
-- If the `Prefix.type` is `Container`, the utilization is calculated as the sum of the total address space of all child prefixes.
-- If the `Prefix.type` is `Pool`, the utilization is calculated as the sum of the total number of IP addresses within the pool's range.
-- If the `Prefix.type` is `Network`:
-    - The utilization is calculated as the sum of the total address space of all child `Pool` prefixes plus the total number of child IP addresses.
-    - For IPv4 networks with a `prefix_length` larger (lower) than `/31`, if neither the first or last address is occupied by either a pool or an IP address, they are subtracted from the total size of the prefix.
-
-### Example
-
-- 192.168.0.0/16          `Container - 1024/65536 utilization`
-    - 192.168.1.0/24      `Network - 1/254 utilization`
-        - 192.168.1.1     `IP Address`
-    - 192.168.2.0/24      `Network - 4/256 utilization`
-        - 192.168.2.0/30  `Pool - 1/4 utilization`
-            - 192.168.2.1 `IP Address`
-    - 192.168.3.0/24      `Network - 5/254 utilization`
-        - 192.168.3.1     `IP Address`
-        - 192.168.3.64/30 `Pool - 0/4 utilization`
-    - 192.168.4.0/24      `Network - 1/256 utilization`
-        - 192.168.4.255   `IP Address`
-
-## IPAddress Parenting Concrete Relationship was added
-
-The `ipam.IPAddress` model has been modified to have a mandatory foreign key to `ipam.Prefix` as the `parent` field. Parenting of IP addresses is now automatically managed at the database level to greatly improve performance especially when calculating tree hierarchy and utilization.
-
-### IPAddress Parenting Guidance
-
-The following guidance has been added to the `IPAddress` model:
-
-- An `IPAddress` should have a parent `Prefix` of type `Network`
-- An `IPAddress` should not be created if a suitable parent `Prefix` of type `Network` does not exist
-- An `IPAddress` can be a member of a `Pool` but only if the `Pool` is a child of a `Network`
-- If an eligible parent `Prefix` cannot be found for an `IPAddress` in a given `Namespace`, creation or update of that `IPAddress` will fail.
-- If deleting a parent `Prefix` would result in any child `IPAddress` objects to become orphaned, the delete operation will fail.
-
-As with the [`Prefix` parenting guidance](#prefix-parenting-guidance) above, violating this guidance in Nautobot 2.0 will result in a warning; in a future Nautobot release this will be changed to an enforced data constraint.
-
-## Parenting affinity during the upgrade
-
-A best effort is made to keep `Prefixes` and `IPAddresses` together 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.
-
-When identifying possible ancestors for child `Prefix` or `IPAddress` objects during the reparenting phase of the upgrade process, the following sets of attributes will be compared in order:
-
-- `Tenant` assigned, `VRF` assigned
-- `Tenant` null, `VRF` assigned
-- `Tenant` assigned, `VRF` null
-- `VRF` assigned
-- `Tenant` null, `VRF` null
-- `VRF` null
-- Default ordering
-
-<!-- markdownlint-disable-next-line MD033 -->
-<figure markdown>
-  ![Tenant affinity decision tree](../../../../../media/user-guide/administration/upgrading/from-v1/ipam/tenant-affinity.png)
-  <!-- markdownlint-disable-next-line MD033 -->
-  <figcaption>Tenant affinity decision tree</figcaption>
-</figure>
-
-## IPAddress to VRF relationships were changed
-
-The foreign key relationship from `IPAddress` to `VRF` was removed. `IPAddress` objects may no longer have a `VRF` assigned to them. The `VRF` value for an `IPAddress` is now inherited from its parent `Prefix`.
-
-Additionally, some new constraints have been put into place to alleviate issues that existed previously which allowed an Interface to have multiple `IPAddress` assignments each with differing VRFs, which is not technically possible in real-world networking configurations.
-
-The `Interface`/`VMInterface` assignment constraints are as follows:
-
-- If the `VRF` has no `Prefixes` assigned, `IPAddresses` may freely be assigned to the `Interface`/`VMInterface`
-- If the `VRF` has `Prefixes` assigned, only child `IPAddresses` of those `Prefixes` may be assigned to the `Interface`/`VMInterface`
-
-## IPAddress prefix_length is now mask_length
-
-The `prefix_length` field on `IPAddress` has been renamed to `mask_length`. This is to enforce that this field is used for documentation purposes only to indicate the mask length that may be used in practice when configuring this address for use on your network.
-
-The `mask_length` field is not used for the parenting algorithm when determining the appropriate parent `Prefix` within a given `Namespace`.
-
-## VRF is no longer used for uniqueness
-
-`VRF` objects can no longer be used for uniqueness boundaries and the `enforce_unique` field has been removed. A new uniqueness constraint has been added to the `VRF` `rd` field, which requires it to be unique for each `Namespace`.
-
-The foreign key relationship from `Prefix` to `VRF` has been inverted and replaced with a many-to-many relationship from `VRF` to `Prefix`. Now each `Prefix` can be assigned to one or more `VRF` object in the same `Namespace`.
-
-Lastly, one or more `Device`/`VirtualMachine` objects can now be assigned to a `VRF`. A `VRF` must be assigned to a `Device`/`VirtualMachine` before it may be assigned to an `Interface`/`VMInterface`. This is the modeling equivalent of creating a `VRF` in the device configuration before it may be used on an interface.
-
-## IPAddress to Interface relationship was inverted
-
-In Nautobot 1.x the relationship from an `IPAddress` to an `Interface`/`VMInterface` was done by way of a foreign key to `Interface`/`VMInterface` on the `IPAddress` object. This implementation was flawed in that if a need arose to assign the same IP address to multiple interfaces, it required the creation of duplicate `IPAddress` objects with the same `host` address in order to assign each one to a different `Interface`/`VMInterface`.
-
-As of Nautobot 2.0, this relationship was inverted. Now an `Interface`/`VMInterface` has a many-to-many relationship to `IPAddresses`. This allows the same `IPAddress` object to be assigned to multiple `Interface`/`VMInterface` objects without the need to create duplicate `IPAddress` objects.
-
-## VRF is now assigned to Interface/VMInterface, not IPAddress
-
-A new foreign key to `VRF` has been introduced to `Interface/VMInterface`.
-
-- A `VRF` must be assigned to a `Device` before it may be assigned to an `Interface`
-- A `VRF` must be assigned to a `VirtualMachine` before it may be assigned to an `VMInterface`
-
-This addresses a fundamental flaw in which an Interface could have multiple `IPAddress` objects assigned with conflicting `VRFs`, which is impossible in practice when applied to a network device configuration.
-
-## Primary IPv4/IPv6 no longer unique
-
-On `Device` and `VirtualMachine` objects, the `primary_ip4` and `primary_ip6` fields were changed from a one-to-one field--which is a foreign key with a uniqueness constraint--to a foreign key, dropping the uniqueness constraint.
-
-This was necessary to support the case where the same `IPAddress` object may be assigned to one or more `Interface`/`VMInterface` objects to share a (non-duplicated) primary `IPAddress` record, reducing the need to proliferate duplicate `IPAddress` objects merely for the purpose of facilitating `Interface`/`VMInterface` assignments.

nautobot/docs/user-guide/administration/upgrading/from-v1/region-and-site-data-migration-guide.md

@@ -1,153 +0,0 @@
-# Region and Site to Location Migration Guide
-
-In Nautobot 2.0.0, all the `Region` and `Site` related data models are being migrated to use `Location`. Below is a comprehensive guide for Nautobot users and Nautobot App developers to migrate their `Region` and `Site` related models and apps to `Location`.
-
-## Migrate ObjectPermission instances in Nautobot from Region and Site to Location
-
-Nautobot admins need to migrate `Site` and `Region` Related `ObjectPermission` instances to `Location`. The correct way to do it are documented below with practical examples.
-
-### Region Specific ObjectPermission
-
-Replace `Location` ContentType to `object_types` field of the `ObjectPermission` if it is not already present and add `"location_type__name": "Region"` to `constraints` field if the old `ObjectPermission` only allows operations on `Region` instances and not on `Site` instances.
-
-Since `Location` has all the filters that `Region` had and they retain the same functionalities. We **do not** need to modify the `constraints` field of any `Region` specific `ObjectPermission` instances any further.
-
-### Site Specific ObjectPermission
-
-Replace `Location` ContentType to `object_types` field of the `ObjectPermission` if it is not already present and add `location_type__name: "Site"` to `constraints` field if the old `ObjectPermission` only allows operations on `Site` instances and not on `Region` instances.
-
-The old `constraints` field for a `Site` specific `ObjectPermission` instance might look like this:
-
-```json
-{
-    "name": "AMS01",
-    "name__in": ["AMS01", "ATL01", "EDX01"],
-    "slug": "ams01",
-    "slug__in": ["ams01", "atl01", "edx01"],
-    "id": "c12753e5-8f01-49a6-b0cf-bf8b460853a1",
-    "id__in": ["c12753e5-8f01-49a6-b0cf-bf8b460853a1", "455038c3-4045-4b78-85f5-17d9f34cb9e8"],
-    "region__name": "United States",
-    "region__name__in": ["United States", "Greece", "England"],
-    "region__slug": "united-states",
-    "region__slug__in": ["united-states", "greece", "england"],
-    "region__id": "f77f5706-e5b3-49e0-9749-b8f818319c40",
-    "region__id__in": ["f77f5706-e5b3-49e0-9749-b8f818319c40", "7df99dc2-283a-4130-8125-60b9ca293131"],
-    "region__parent__name": "North America",
-    "region__parent__name__in": ["North America", "Europe"],
-    "region__parent__slug": "north-america",
-    "region__parent__slug__in": ["north-america", "europe"],
-    "region__parent__id": "c1a816df-876f-44d4-8ea0-335898998780",
-    "region__parent__id__in": ["c1a816df-876f-44d4-8ea0-335898998780", "a68b0838-d7fb-416c-b4ba-a3e464e552ba"]
-}
-```
-
-To modify the data correctly, we need to:
-    1. Replace all occurrences of "region" with "parent" in the **Key** portion (before ":") of the data **not Value** (after ":").
-    2. Since Nautobot carries over the UUIDs of the old `Site`/`Region` instances when creating the new "Site"/"Region" type `Location` instances, we **do not** need to change the UUID values in `...__id` and `...__id__in` Keys.
-    3. Since Nautobot 2.x `Locations` do not have `slug` fields, we will need to remove those references. (In a real example, you'd probably want to replace them with `name` references, but in this example we already have `name` references that are redundant with the `slug`, so here we'll just remove the `slug` references entirely.)
-
-The updated JSON data might look like this:
-
-```json
-{
-    "location_type__name": "Site",
-    "name": "AMS01",
-    "name__in": ["AMS01", "ATL01", "EDX01"],
-    "id": "c12753e5-8f01-49a6-b0cf-bf8b460853a1",
-    "id__in": ["c12753e5-8f01-49a6-b0cf-bf8b460853a1", "455038c3-4045-4b78-85f5-17d9f34cb9e8"],
-    "parent__name": "United States",
-    "parent__name__in": ["United States", "Greece", "England"],
-    "parent__id":  "f77f5706-e5b3-49e0-9749-b8f818319c40",
-    "parent__id__in": ["f77f5706-e5b3-49e0-9749-b8f818319c40", "7df99dc2-283a-4130-8125-60b9ca293131"],
-    "parent__parent__name": "North America",
-    "parent__parent__name__in": ["North America", "Europe"],
-    "parent__parent__id": "c1a816df-876f-44d4-8ea0-335898998780",
-    "parent__parent__id__in": ["c1a816df-876f-44d4-8ea0-335898998780", "a68b0838-d7fb-416c-b4ba-a3e464e552ba"]
-}
-```
-
-### Other Data Model Specific ObjectPermission e.g. Interface
-
-The old `constraints` field for a `Site`/`Region` related data model's (e.g. `Interface`) `ObjectPermission` instance might look like this:
-
-```json
-{
-    "device__site__name": "AMS01",
-    "device__site__name__in": ["AMS01", "ATL01", "ETX02"],
-    "device__site__slug": "ams01",
-    "device__site__slug__in": ["ams01", "atl01", "etx02"],
-    "device__site__id": "0ab47314-2944-45f6-b964-9e009fc48ce0",
-    "device__site__id__in": ["0ab47314-2944-45f6-b964-9e009fc48ce0", "b09545d4-6e2b-471e-8f07-27f25ca308f5"],
-    "device__site__region__name": "United States",
-    "device__site__region__name__in": ["United States", "United Kingdom", "Greece"],
-    "device__site__region__slug": "united-states",
-    "device__site__region__slug__in": ["united-states", "united-kingdom", "greece"],
-    "device__site__region__id": "f1a79a3c-d980-40e1-979d-abdb0f83388e",
-    "device__site__region__id__in": ["f1a79a3c-d980-40e1-979d-abdb0f83388e", "6335a61e-503d-463c-99c2-9c87ef8354d9"],
-    "device__site__region__parent__name": "North America",
-    "device__site__region__parent__name__in": ["North America", "Europe", "South America"],
-    "device__site__region__parent__slug": "north-america",
-    "device__site__region__parent__slug__in": ["north-america", "europe", "south-america"],
-    "device__site__region__parent__id": "6695809c-b33b-4f12-b0de-a4969000434d",
-    "device__site__region__parent__id__in": ["6695809c-b33b-4f12-b0de-a4969000434d", "e51d07bb-3fcf-4306-9d87-6b1ff6dd6378"]
-}
-```
-
-To modify the data correctly, we need to:
-    1. Replace all occurrences of "site" with "location" in the **Key** portion (before ":") of the data **not Value** (after ":").
-    2. Replace all occurrences of "region" with "parent" in the **Key** portion (before ":") of the data **not Value** (after ":").
-    3. Add `"device__location__location_type__name": "Site"` if the old `ObjectPermission` only allows operations on `Interfaces` of `Device` instances assigned to `Sites`.
-    4. Since Nautobot carries over the UUIDs of the old `Site`/`Region` instances when creating the new "Site"/"Region" type `Location` instances, we **do not** need to change the UUID values in `...__id` and `...__id__in` Keys.
-    5. As before, remove any `slug` references or replace them with appropriate `name` or `id` references.
-
-The updated JSON data might look like this:
-
-```json
-{
-    "device__location__location_type__name": "Site",
-    "device__location__name": "AMS01",
-    "device__location__name__in": ["AMS01", "ATL01", "ETX02"],
-    "device__location__id": "0ab47314-2944-45f6-b964-9e009fc48ce0",
-    "device__location__id__in": ["0ab47314-2944-45f6-b964-9e009fc48ce0", "b09545d4-6e2b-471e-8f07-27f25ca308f5"],
-    "device__location__parent__name": "United States",
-    "device__location__parent__name__in": ["United States", "United Kingdom", "Greece"],
-    "device__location__parent__id": "f1a79a3c-d980-40e1-979d-abdb0f83388e",
-    "device__location__parent__id__in": ["f1a79a3c-d980-40e1-979d-abdb0f83388e", "6335a61e-503d-463c-99c2-9c87ef8354d9"],
-    "device__location__parent__parent__name": "North America",
-    "device__location__parent__parent__name__in": ["North America", "Europe", "South America"],
-    "device__location__parent__parent__id": "6695809c-b33b-4f12-b0de-a4969000434d",
-    "device__location__parent__parent__id__in": ["6695809c-b33b-4f12-b0de-a4969000434d", "e51d07bb-3fcf-4306-9d87-6b1ff6dd6378"]
-}
-```
-
-### Other Data Model Specific ObjectPermission e.g. Note
-
-The old `constraints` field for a `Site`/`Region` related data model's (e.g. `Note`) `ObjectPermission` instance might look like this:
-
-```json
-{
-    "assigned_object_type": "dcim.site",
-    "assigned_object_id": "932d94ee-5571-40a0-903f-4274fcfbed32",
-    "assigned_object_id__in": ["932d94ee-5571-40a0-903f-4274fcfbed32", "e383db9a-dd55-464d-9e56-2f18bc03b32c"]
-}
-```
-
-To modify the data correctly, we need to:
-    1. Replace all occurrences of "dcim.site" and/or "dcim.region" with "dcim.location" in the **Value** portion (after ":") of the `assigned_object_type` Key.
-    2. Since Nautobot carries over the UUIDs of the old `Site`/`Region` instances when creating the new "Site"/"Region" type `Location` instances, we **do not** need to change the UUID values in the `assigned_object_id` and `assigned_object_id__in` Keys.
-
-The updated JSON data might look like this:
-
-```json
-{
-    "assigned_object_type": "dcim.location",
-    "assigned_object_id": "932d94ee-5571-40a0-903f-4274fcfbed32",
-    "assigned_object_id__in": ["932d94ee-5571-40a0-903f-4274fcfbed32", "e383db9a-dd55-464d-9e56-2f18bc03b32c"]
-}
-```
-
-## Update Nautobot Apps
-
-Any Nautobot Apps that you use and maintain which have existing data referencing Site or Region records will need to be [updated](../../../../development/apps/migration/model-updates/dcim.md#replace-site-and-region-with-location-model) before you can complete your migration to Nautobot 2.0.
-
-## Region and Site Related Data Model Migration Guide For New Nautobot App installations in an Existing Nautobot 2.0 Environment

nautobot/docs/user-guide/administration/upgrading/from-v1/tables/v2-api-behavior-changes.yaml

@@ -1,82 +0,0 @@
----
-- Model: "(all)"
-  Field: "created"
-  Changes: "Now is a date/time rather than only a date"
-- Model: "Cable"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "Circuit"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "Device"
-  Field: "config_context"
-  Changes: "Now is only included when specifically requested with `?include=config_context` query parameter"
-- Model: "Device"
-  Field: "location"
-  Changes: "Now required, no longer optional"
-- Model: "Device"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "DeviceRedundancyGroup"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "Interface"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "IPAddress"
-  Field: "namespace"
-  Changes: "A derived field. Required on creation, if `parent` isn't provided, to find a correct parent Prefix"
-- Model: "IPAddress"
-  Field: "parent"
-  Changes: "A new foreign-key to `Prefix`. Required on creation, if `namespace` isn't provided, to find a correct parent Prefix"
-- Model: "IPAddress"
-  Field: "role"
-  Changes: "Now is a foreign-key to `Role` rather than a string"
-- Model: "IPAddress"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "JobLogEntry"
-  Field: "display"
-  Changes: "Now contains the message text rather than the message timestamp"
-- Model: "Location"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "PowerFeed"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "PowerPanel"
-  Field: "location"
-  Changes: "Now required, no longer optional"
-- Model: "Prefix"
-  Field: "namespace"
-  Changes: "New required foreign key to Namespace, defaulting to 'Global'"
-- Model: "Prefix"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "Rack"
-  Field: "location"
-  Changes: "Now required, no longer optional"
-- Model: "Rack"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "RackGroup"
-  Field: "location"
-  Changes: "Now required, no longer optional"
-- Model: "RackGroup"
-  Field: "rack_count"
-  Changes: "Now only counts Racks directly belonging to this RackGroup, not those belonging to its descendants"
-- Model: "TenantGroup"
-  Field: "tenant_count"
-  Changes: "Now only counts Tenants directly belonging to this TenantGroup, not those belonging to its descendants"
-- Model: "VirtualMachine"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "VLAN"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "VMInterface"
-  Field: "status"
-  Changes: "Now is a foreign-key rather than a pseudo-enum"
-- Model: "VRF"
-  Field: "namespace"
-  Changes: "New required foreign key to Namespace, defaulting to 'Global'"

nautobot/docs/user-guide/administration/upgrading/from-v1/tables/v2-api-removed-fields.yaml

@@ -1,175 +0,0 @@
----
-- Model/Endpoint: "/api/plugins/installed-plugins"
-  Removed Field: "verison"
-  Comments: "Use `version` instead"
-- Model/Endpoint: "/api/status/"
-  Removed Field: "rq-workers-running"
-  Comments: "Django-RQ is no longer supported"
-- Model/Endpoint: "CircuitTermination"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "CircuitType"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Cluster"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "ClusterGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "ClusterType"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "ConfigContext"
-  Removed Field: "regions"
-  Comments: "Use `locations` instead"
-- Model/Endpoint: "ConfigContext"
-  Removed Field: "sites"
-  Comments: "Use `locations` instead"
-- Model/Endpoint: "ConfigContextSchema"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "CustomLink"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Device"
-  Removed Field: "primary_ip"
-  Comments: "Use `primary_ip4` or `primary_ip6`instead"
-- Model/Endpoint: "Device"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "DeviceRedundancyGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "DeviceType"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "DynamicGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "GitRepository"
-  Removed Field: "token"
-  Comments: "Use Secrets instead"
-- Model/Endpoint: "GitRepository"
-  Removed Field: "username"
-  Comments: "Use Secrets instead"
-- Model/Endpoint: "GraphQLQuery"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "IPAddress"
-  Removed Field: "assigned_object"
-  Comments: "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."
-- Model/Endpoint: "IPAddress"
-  Removed Field: "broadcast"
-  Comments: "Use parent Prefix's broadcast instead"
-- Model/Endpoint: "IPAddress"
-  Removed Field: "vrf"
-  Comments: "VRF is now related to the assigned Interface(s), as well as the parent Prefix"
-- Model/Endpoint: "JobHook"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "JobResult"
-  Removed Field: "job_id"
-  Comments:
-- Model/Endpoint: "JobResult"
-  Removed Field: "obj_type"
-  Comments:
-- Model/Endpoint: "Location"
-  Removed Field: "site"
-  Comments: "Use `parent` instead"
-- Model/Endpoint: "Location"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "LocationType"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Manufacturer"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Note"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Platform"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "PowerFeed"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "PowerPanel"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "Prefix"
-  Removed Field: "is_pool"
-  Comments: "Use `type` instead"
-- Model/Endpoint: "Prefix"
-  Removed Field: "vrf"
-  Comments: "Prefixes are now assigned to a VRF in the same Namespace via a many-to-many relationship"
-- Model/Endpoint: "Prefix"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "Provider"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "ProviderNetwork"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Rack"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "RackGroup"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "RackGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "RelationshipAssociation"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "RIR"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Role"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "RouteTarget"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Secret"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "SecretsGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "SecretsGroupAssociation"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Status"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Tag"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "Tenant"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "TenantGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "VirtualMachine"
-  Removed Field: "primary_ip"
-  Comments: "Use `primary_ip4` or `primary_ip6`instead"
-- Model/Endpoint: "VLAN"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "VLANGroup"
-  Removed Field: "site"
-  Comments: "Use `location` instead"
-- Model/Endpoint: "VLANGroup"
-  Removed Field: "slug"
-  Comments:
-- Model/Endpoint: "VRF"
-  Removed Field: "enforce_unique"
-  Comments: "Uniqueness of Prefixes and IPAddresses is now enforced at the database level"
-- Model/Endpoint: "Webhook"
-  Removed Field: "slug"
-  Comments: