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

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

@@ -1,127 +0,0 @@
-# Upgrading to a New Nautobot Release
-
-## Review the Release Notes
-
-Prior to upgrading your Nautobot instance, be sure to carefully review all [release notes](../../../release-notes/index.md) that
-have been published since your current version was released. Although the upgrade process typically does not involve
-additional work, certain releases may introduce breaking or backward-incompatible changes. These are called out in the
-release notes under the release in which the change went into effect.
-
-The below sub-sections describe some key changes that deployers should be aware of, but are not intended to be a replacement for reading the release notes carefully and in depth.
-
-### Updating from Nautobot 1.0.x to 1.1.x
-
-#### Migration from RQ to Celery
-
-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*, as Celery has been introduced to eventually replace RQ for executing background tasks within Nautobot. All Nautobot **core** usage of RQ has been migrated to use Celery.
-
-RQ support for custom tasks was not removed in order to give plugin authors time to migrate, however, to continue to utilize advanced Nautobot features such as Git repository synchronization, webhooks, jobs, etc. you must migrate your `nautobot-worker` deployment from RQ to Celery.
-
-Please see the section on [migrating to Celery from RQ](../installation/services.md#migrating-to-celery-from-rq) for more information on how to easily migrate your deployment.
-
-### Updating from Nautobot 1.1.x to 1.2.x
-
-#### Introduction of Celery Beat Scheduler
-
-As of Nautobot v1.2.0, Nautobot supports deferring ("scheduling") Jobs. To facilitate this, a new service called `celery-scheduler` is now required. Please review the [service installation documentation](../installation/services.md#celery-beat-scheduler) to find out how to set it up.
-
-### Updating from Nautobot 1.2.x to 1.3.x
-
-#### Revision of Recommended MySQL UTF-8 Encoding
-
-The recommended database encoding settings have been revised to rely upon the default UTF-8 encoding provided by MySQL for collation of data in the database. Previously we were recommending in our documentation that the collation encoding be set explicitly to `utf8mb4_bin`. We are now recommending `utf8mb4_0900_ai_ci` which is configured by default on unmodified MySQL database server deployments.
-
-The collation encoding is used to inform MySQL how characters are sorted in the database. This is important when it comes to retrieving data that has special characters or special byte-encoding such as accents or ligatures, and also including emojis. In some cases, with the `utf8mb4_bin` encoding we were previously recommending, case-insensitive searching may return inconsistent or incorrect results.
-
-!!! danger
-    It is **strongly recommended** that you [backup your database](database-backup.md) before executing this query and that you perform this in a non-production environment to identify any potential issues prior to updating your production environment.
-
-If you have an existing MySQL database, you may update your database to use the recommended encoding by using `nautobot-server dbshell` to launch a database shell and executing the following command:
-
-```no-highlight
-nautobot-server dbshell
-```
-
-Example output:
-
-```no-highlight
-mysql> ALTER DATABASE nautobot COLLATE utf8mb4_0900_ai_ci;
-Query OK, 1 row affected (0.07 sec)
-```
-
-Please see the [official MySQL documentation on migrating collation encoding settings](https://dev.mysql.com/blog-archive/mysql-8-0-collations-migrating-from-older-collations/) for more information on troubleshooting any issues you may encounter.
-
-## Update Prerequisites to Required Versions
-
-Nautobot v2.0.0 and later requires the following:
-
-| Dependency | Minimum Version |
-| ---------- | --------------- |
-| Python     | 3.8             |
-| PostgreSQL | 9.6             |
-| Redis      | 4.0             |
-
---- 1.6.0
-    Support for Python 3.7 was removed.
-
-Nautobot v1.1.0 and later can optionally support the following:
-
-> *Nautobot v1.1.0 added support for MySQL 8.0 as a database backend as an alternative to PostgreSQL.*
-
-| Dependency | Minimum Version |
-| ---------- | --------------- |
-| MySQL      | 8.0             |
-
-!!! tip
-    If you wish to migrate from PostgreSQL to MySQL, we recommend creating a new Nautobot installation based on MySQL and then [migrating the database contents to the new installation](../migration/migrating-from-postgresql.md), rather than attempting an in-place upgrade or migration.
-
-## Install the Latest Release
-
-As with the initial installation, you can upgrade Nautobot by installing the Python package directly from the Python Package Index (PyPI).
-
-!!! warning
-    Unless explicitly stated, all steps requiring the use of `pip3` or `nautobot-server` in this document should be performed as the `nautobot` user!
-
-Upgrade Nautobot using `pip3`:
-
-```no-highlight
-pip3 install --upgrade nautobot
-```
-
-## Upgrade your Optional Dependencies
-
-If you do not have any optional dependencies, you may skip this step.
-
-Once the new code is in place, verify that any optional Python packages required by your deployment (e.g. `napalm` or
-`django-auth-ldap`) are listed in `local_requirements.txt`.
-
-Then, upgrade your dependencies using `pip3`:
-
-```no-highlight
-pip3 install --upgrade -r $NAUTOBOT_ROOT/local_requirements.txt
-```
-
-## Run the Post Upgrade Operations
-
-Finally, run Nautobot's `post_upgrade` management command:
-
-```no-highlight
-nautobot-server post_upgrade
-```
-
-This command performs the following actions:
-
-* Applies any database migrations that were included in the release
-* Generates any missing cable paths among all cable termination objects in the database
-* Collects all static files to be served by the HTTP service
-* Deletes stale content types from the database
-* Deletes all expired user sessions from the database
-* Clears all cached data to prevent conflicts with the new release
-
-## Restart the Nautobot Services
-
-Finally, with root permissions, restart the web and background services:
-
-```no-highlight
-sudo systemctl restart nautobot nautobot-worker nautobot-scheduler
-```

nautobot/docs/user-guide/core-data-model/circuits/circuit.md

@@ -1,19 +0,0 @@
-# Circuits
-
-A communications circuit represents a single _physical_ link connecting exactly two endpoints, commonly referred to as its A and Z terminations. A circuit in Nautobot may have zero, one, or two terminations defined. It is common to have only one termination defined when you don't necessarily care about the details of the provider side of the circuit, e.g. for Internet access circuits. Both terminations would likely be modeled for circuits which connect one customer location to another.
-
-Each circuit is associated with a provider and a user-defined type. For example, you might have Internet access circuits delivered to each location by one provider, and private MPLS circuits delivered by another. Each circuit must be assigned a circuit ID, each of which must be unique per provider.
-
-Each circuit must be assigned to a [`status`](../../platform-functionality/status.md). The following statuses are available by default:
-
-* Planned
-* Provisioning
-* Active
-* Offline
-* Deprovisioning
-* Decommissioned
-
-Circuits also have optional fields for annotating their installation date and commit rate, and may be assigned to Nautobot tenants.
-
-!!! note
-    Nautobot currently models only physical circuits: those which have exactly two endpoints. It is common to layer virtualized constructs (_virtual circuits_) such as MPLS or EVPN tunnels on top of these, however Nautobot does not yet support virtual circuit modeling.

nautobot/docs/user-guide/core-data-model/circuits/circuittermination.md

@@ -1,10 +0,0 @@
-# Circuit Terminations
-
-The association of a circuit with a particular location and/or device is modeled separately as a circuit termination. A circuit may have up to two terminations, labeled A and Z. A single-termination circuit can be used when you don't know (or care) about the far end of a circuit (for example, an Internet access circuit which connects to a transit provider). A dual-termination circuit is useful for tracking circuits which connect two locations.
-
-Each circuit termination is attached to either a location or a provider network. Location terminations may optionally be connected via a cable to a specific device interface or port within that location. Each termination must be assigned a port speed, and can optionally be assigned an upstream speed if it differs from the downstream speed (a common scenario with e.g. DOCSIS cable modems). Fields are also available to track cross-connect and patch panel details.
-
-In adherence with Nautobot's philosophy of closely modeling the real world, a circuit may be connected only to a physical interface. For example, circuits may not terminate to LAG interfaces, which are virtual in nature. In such cases, a separate physical circuit is associated with each LAG member interface and each needs to be modeled discretely.
-
-!!! note
-    A circuit in Nautobot represents a physical link, and cannot have more than two endpoints. When modeling a multi-point topology, each leg of the topology must be defined as a discrete circuit, with one end terminating within the provider's infrastructure. The provider network model is ideal for representing these networks.

nautobot/docs/user-guide/core-data-model/circuits/circuittype.md

@@ -1,8 +0,0 @@
-# Circuit Types
-
-Circuits are classified by functional type. These types are completely customizable, and are typically used to convey the type of service being delivered over a circuit. For example, you might define circuit types for:
-
-* Internet transit
-* Out-of-band connectivity
-* Peering
-* Private backhaul

nautobot/docs/user-guide/core-data-model/circuits/provider.md

@@ -1,5 +0,0 @@
-# Providers
-
-A circuit provider is any entity which provides some form of connectivity among locations or organizations within a location. While this obviously includes carriers which offer Internet and private transit service, it might also include Internet exchange (IX) points and even organizations with whom you peer directly. Each circuit within Nautobot must be assigned a provider and a circuit ID which is unique to that provider.
-
-Each provider may be assigned an autonomous system number (ASN), an account number, and contact information.

nautobot/docs/user-guide/core-data-model/circuits/providernetwork.md

@@ -1,7 +0,0 @@
-# Provider Network
-
-+++ 1.3.0
-
-A provider network represents an abstract portion of network topology, just like in a topology diagram. For example, a provider network may be used to represent a provider's MPLS network.
-
-Each provider network must be assigned to a provider. A circuit may terminate to either a provider network or to a valid location.

nautobot/docs/user-guide/core-data-model/dcim/cable.md

@@ -1,43 +0,0 @@
-# Cables
-
-All connections between device components in Nautobot are represented using cables. A cable represents a direct physical connection between two termination points, such as between a console port and a patch panel port, or between two network interfaces.
-
-Each cable must have two endpoints defined. These endpoints are sometimes referenced as A and B for clarity, however cables are direction-agnostic and the order in which terminations are made has no meaning. Cables may be connected to the following objects:
-
-* Circuit terminations
-* Console ports
-* Console server ports
-* Interfaces
-* Pass-through ports (front and rear)
-* Power feeds
-* Power outlets
-* Power ports
-
-Each cable may be assigned a type, label, length, and color. Each cable must also assigned to an operational [`status`](../../platform-functionality/status.md). The following statuses are available by default:
-
-* Active
-* Planned
-* Decommissioning
-
-## Tracing Cables
-
-A cable may be traced from either of its endpoints by clicking the "trace" button. (A REST API endpoint also provides this functionality.) Nautobot will follow the path of connected cables from this termination across the directly connected cable to the far-end termination. If the cable connects to a pass-through port, and the peer port has another cable connected, Nautobot will continue following the cable path until it encounters a non-pass-through or unconnected termination point. The entire path will be displayed to the user.
-
-In the example below, three individual cables comprise a path between devices A and D:
-
-![Cable path](../../../media/models/dcim_cable_trace.png)
-
-Traced from Interface 1 on Device A, Nautobot will show the following path:
-
-* Cable 1: Interface 1 to Front Port 1
-* Cable 2: Rear Port 1 to Rear Port 2
-* Cable 3: Front Port 2 to Interface 2
-
-A cable can also be traced through a circuit.
-
-![Cable path circuit](../../../media/models/dcim_cable_trace_circuit.png)
-
-Traced from Interface 1 on Device A, Nautobot will show the following path:
-
-* Cable 1: Interface 1 to Side A
-* Cable 2: Side Z to Interface 2

nautobot/docs/user-guide/core-data-model/dcim/consoleport.md

@@ -1,8 +0,0 @@
-# Console Ports
-
-A console port provides connectivity to the physical console of a device. These are typically used for temporary access by someone who is physically near the device, or for remote out-of-band access provided via a networked console server. Each console port may be assigned a physical type.
-
-Cables can connect console ports to console server ports or pass-through ports.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/consoleporttemplate.md

@@ -1,6 +0,0 @@
-# Console Port Templates
-
-A template for a console port that will be created on all instantiations of the parent device type. Each console port can be assigned a physical type.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/consoleserverport.md

@@ -1,8 +0,0 @@
-# Console Server Ports
-
-A console server is a device which provides remote access to the local consoles of connected devices. They are typically used to provide remote out-of-band access to network devices. Each console server port may be assigned a physical type.
-
-Cables can connect console server ports to console ports or pass-through ports.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/consoleserverporttemplate.md

@@ -1,6 +0,0 @@
-# Console Server Port Templates
-
-A template for a console server port that will be created on all instantiations of the parent device type. Each console server port can be assigned a physical type.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/device.md

@@ -1,29 +0,0 @@
-# Devices
-
-Every piece of hardware which is installed within a location or rack exists in Nautobot as a device. Devices are measured in rack units (U) and can be half depth or full depth. A device may have a height of 0U: These devices do not consume vertical rack space and cannot be assigned to a particular rack unit. A common example of a 0U device is a vertically-mounted PDU.
-
-When assigning a multi-U device to a rack, it is considered to be mounted in the lowest-numbered rack unit which it occupies. For example, a 3U device which occupies U8 through U10 is said to be mounted in U8. This logic applies to racks with both ascending and descending unit numbering.
-
-A device is said to be full-depth if its installation on one rack face prevents the installation of any other device on the opposite face within the same rack unit(s). This could be either because the device is physically too deep to allow a device behind it, or because the installation of an opposing device would impede airflow.
-
-Each device must be instantiated from a pre-created device type, and its default components (console ports, power ports, interfaces, etc.) will be created automatically. (The device type associated with a device may be changed after its creation, however its components will not be updated retroactively.)
-
-Each device must be assigned a location, device role, and operational [`status`](../../platform-functionality/status.md), and may optionally be assigned to a rack within a location. A platform, serial number, and asset tag may optionally be assigned to each device.
-
-Device names must be unique within a location, unless the device has been assigned to a tenant. Devices may also be unnamed.
-
-When a device has one or more interfaces with IP addresses assigned, a primary IP for the device can be designated, for both IPv4 and IPv6.
-
-+/- 2.0.0
-    In Nautobot 1.x, it was not possible to delete an IPAddress or an Interface that was serving as the primary IP address (`primary_ip4`/`primary_ip6`) for a Device. As of Nautobot 2.0, this is now permitted; doing so will clear out the Device's corresponding primary IP value.
-
-For Devices forming a group (Failover, Load-Sharing, Redundacy or similar) refer to [Device Redundancy Groups](deviceredundancygroup.md) model documentation.
-
-## Developer API
-
-The `Device` Django model class supports a method called `create_components()`. This method is normally called during `device_instance.save()`, which is called whenever you save create a Device via the GUI or the REST API, but if you are working directly in the ORM and encounter one of the two following scenarios, `device_instance.save()` is not called:
-
-- Usage of `device_instance.objects.bulk_create()` to perform a bulk creation of Device objects
-- Usage of `device_instance.save()` during handling of the `nautobot_database_ready` signal (which uses [historical models](https://docs.djangoproject.com/en/3.2/topics/migrations/#historical-models))
-
-In these cases you will have to manually run `device_instance.create_components()` in order to instantiate the [device type's](devicetype.md) component templates (interfaces, power ports, etc.).

nautobot/docs/user-guide/core-data-model/dcim/devicebay.md

@@ -1,11 +0,0 @@
-# Device Bays
-
-Device bays represent a space or slot within a parent device in which a child device may be installed. For example, a 2U parent chassis might house four individual blade servers. The chassis would appear in the rack elevation as a 2U device with four device bays, and each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations or count as consuming rack units.
-
-Child devices are first-class Devices in their own right: That is, they are fully independent managed entities which don't share any control plane with the parent.  Just like normal devices, child devices have their own platform (OS), role, tags, and components.  LAG interfaces may not group interfaces belonging to different child devices.
-
-!!! note
-    Device bays are **not** suitable for modeling line cards (such as those commonly found in chassis-based routers and switches), as these components depend on the control plane of the parent device to operate. Instead, line cards and similarly non-autonomous hardware should be modeled as inventory items within a device, with any associated interfaces or other components assigned directly to the device.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/devicebaytemplate.md

@@ -1,6 +0,0 @@
-# Device Bay Templates
-
-A template for a device bay that will be created on all instantiations of the parent device type.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/deviceredundancygroup.md

@@ -1,279 +0,0 @@
-# Device Redundancy Groups
-
-+++ 1.5.0
-
-Device Redundancy Groups represent logical relationships between multiple devices. Typically, a redundancy group could represent a failover pair, failover group, or a load sharing cluster.
-Device Redundancy Groups are created first, before the devices are assigned to the group.
-
-A failover strategy represents intended operation mode of the group. Supported failover strategy are: Active/Active and Active/Standby.
-
-Secrets groups could be used to inform store secret information used by failover or a cluster of devices.
-
-Device Redundancy Group Priority is a Device attribute defined during assigning a Device to a Device Redundancy Group. This field represents the priority the device has in the device redundancy group.
-
-## Example use of Device Redundancy Groups - Cisco ASA 5500 Series Active/Standby Failover
-
-This document provides an example of generating a Cisco ASA device's desired failover configuration based on data stored in Nautobot Device Redundancy Groups.
-A GraphQL query is used to retrieve the relevant data, which is then rendered through a Jinja2 template to produce the desired configuration.
-
-As one of the use cases for Device Redundacy Groups, introduced in Nautobot 1.5 release, is to model failover pairs, we will use the ASA 5500 Series in this example with details as follows:
-
-* Firewall failover pair is composed of two devices named "nyc-fw-primary" and "nyc-fw-secondary"
-* Each firewall device forming a failover cluster has a virtual interface dedicated for failover usage (named "failover-link") and addressed in 172.27.48.0/31 network
-* Virtual failover interface has a physical parent interface assigned ("gigabitethernet0/3")
-* Following redundancy group priorities are assigned in a failover pair:
-    * Priority 100 for a Primary Failover unit
-    * Priority 50 for a Secondary Failover unit
-
-### Querying for the data
-
-To retrieve information about devices forming an ASA Failover pair, we will use a GraphQL query and the `get_gql_failover_details` Python method.
-This method takes a `device_name` as an argument.
-
-```python
-import json
-import pynautobot
-
-query = """
-query ($device_name: [String]) {
-    devices(name__ie: $device_name) {
-        name
-        device_redundancy_group {
-            name
-            members {
-                name
-                device_redundancy_group_priority
-                interfaces(name__ie: "failover-link") {
-                    type
-                    name
-                    ip_addresses {
-                        host
-                        mask_length
-                    }
-                    parent_interface {
-                        name
-                        type
-                    }
-                }
-            }
-        }
-    }
-}
-"""
-
-def get_gql_failover_details(device_name):
-    variables = {"device_name": device_name}
-    nb = pynautobot.api(
-        url="http://localhost:8080",
-        token="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
-    )
-    return nb.graphql.query(query=query, variables=variables)
-```
-
-### Retrieving the data - Primary Failover Unit ("nyc-fw-primary")
-
-We will demonstrate how to execute the command for Primary Unit only, however you could repeat the process for a secondary unit. An example data returned from Nautobot is presented below.
-
-```python
->>> hostname = "nyc-fw-primary"
->>> gql_data = get_gql_failover_details(hostname).json
-```
-
-```json
-{
-    "data": {
-        "devices": [
-            {
-                "name": "nyc-fw-primary",
-                "device_redundancy_group": {
-                    "name": "nyc-firewalls",
-                    "members": [
-                        {
-                            "name": "nyc-fw-primary",
-                            "device_redundancy_group_priority": 100,
-                            "interfaces": [
-                                {
-                                    "type": "VIRTUAL",
-                                    "name": "failover-link",
-                                    "ip_addresses": [
-                                        {
-                                            "host": "172.27.48.0",
-                                            "mask_length": 31
-                                        }
-                                    ],
-                                    "parent_interface": {
-                                        "name": "gigabitethernet0/3",
-                                        "type": "A_1000BASE_T"
-                                    }
-                                }
-                            ]
-                        },
-                        {
-                            "name": "nyc-fw-secondary",
-                            "device_redundancy_group_priority": 50,
-                            "interfaces": [
-                                {
-                                    "type": "VIRTUAL",
-                                    "name": "failover-link",
-                                    "ip_addresses": [
-                                        {
-                                            "host": "172.27.48.1",
-                                            "mask_length": 31
-                                        }
-                                    ],
-                                    "parent_interface": {
-                                        "name": "gigabitethernet0/3",
-                                        "type": "A_1000BASE_T"
-                                    }
-                                }
-                            ]
-                        }
-                    ]
-                }
-            }
-        ]
-    }
-}
-```
-
-### Creating Cisco ASA Configuration Template - Common for Primary and Secondary Units
-
-The following snippet represents an example Cisco ASA failover configuration template:
-
-```python
-# Configuration Template for Cisco ASA
-template_code = """
-{% set redundancy_members = gql_data['data']['devices'][0]['device_redundancy_group']['members'] %}
-{% set failover_device_local = redundancy_members[0] if redundancy_members[0].name == device else redundancy_members[1] %}
-{% set failover_device_peer = redundancy_members[0] if redundancy_members[0].name != device else redundancy_members[1] %}
-{% set failover_local_vif = failover_device_local.interfaces | first %}
-{% set failover_peer_vif = failover_device_peer.interfaces | first %}
-!
-hostname {{ device.name }}
-!
-failover lan unit {{ priority_mapping[failover_device_local.device_redundancy_group_priority] }}
-failover lan interface {{ failover_local_vif.name }} {{ failover_local_vif.parent_interface.name }} 
-!
-failover interface ip {{ failover_local_vif.name }} {{ failover_local_vif.ip_addresses[0].host }}/{{ failover_local_vif.ip_addresses[0].prefix_length }} standby {{ failover_peer_vif.ip_addresses[0].host }}
-interface {{ failover_local_vif.parent_interface.name }} 
-  no shutdown
-!
-failover link {{ failover_local_vif.name }} {{ failover_local_vif.parent_interface.name }} 
-!
-!failover ipsec pre-shared-key !Nautobot Secrets
-!
-failover
-!
-"""
-```
-
-### Rendering Cisco ASA Configuration Template with the data retrieved from GraphQL
-
-Following snippet represents an example Cisco ASA Failover rendered configuration:
-
-```python
-from nautobot.core.utils.data import render_jinja2
-
-
-context = dict(
-    device=hostname,
-    gql_data=gql_data,
-    priority_mapping={50: 'secondary', 100: 'primary'}
-)
-nyc_fw_primary_config = render_jinja2(template_code=template_code, context=context)
-
-print(nyc_fw_primary_config)
-```
-
-```text
-!
-hostname nyc-fw-primary
-!
-failover lan unit
-failover lan interface failover-link gigabitethernet0/3
-!
-failover interface ip failover-link 172.27.48.0/31 standby 172.27.48.1
-interface gigabitethernet0/3
-  no shutdown
-!
-failover link failover-link gigabitethernet0/3
-!
-!failover ipsec pre-shared-key !Nautobot Secrets
-!
-failover
-!
-```
-
-## Example use of Device Redundancy Groups - Spine Redundancy in a Leaf and Spine (Clos) Topology
-
-Another example for the redundancy group use case could be a spine redundancy in the Leaf and Spine topology.
-Spine redundancy is important while performing the Day-2 operations, such as OS-updates.
-
-In this scenario, no more than 1 device participating in a Device Redundancy Group should be updated and rebooted at the same time. In order to track this, we will create a new Device custom field  named `upgrade_operational_state` and assign it one of the statues: `pre_upgrade`, `in_reboot`, `post_upgrade`. If a device with a spine role assigned is in state `in_reboot`, no other redundancy group members should be OS-upgraded at the same time.
-
-### Querying for the data - Spine Redundancy in a Leaf and Spine (Clos) Topology
-
-To retrieve the data about devices forming a Spine redundancy group, we will use the following GraphQL query:
-
-```text
-query {
-    device_redundancy_groups(name__ie: "nyc-spines") {
-        name
-        members {
-          name
-          device_role {
-            name
-          }
-          cf_upgrade_operational_state
-        }
-    }
-}
-```
-
-### Retrieving the data - Spine Redundancy in a Leaf and Spine (Clos) Topology
-
-An example data returned from Nautobot is presented below.
-
-```json
-{
-  "data": {
-    "device_redundancy_groups": [
-      {
-        "name": "nyc-spines",
-        "members": [
-          {
-            "name": "spine-1",
-            "device_role": {
-              "name": "spine"
-            },
-            "cf_upgrade_operational_state": "in_reboot"
-          },
-          {
-            "name": "spine-2",
-            "device_role": {
-              "name": "spine"
-            },
-            "cf_upgrade_operational_state": null
-          },
-          {
-            "name": "spine-3",
-            "device_role": {
-              "name": "spine"
-            },
-            "cf_upgrade_operational_state": null
-          },
-          {
-            "name": "spine-4",
-            "device_role": {
-              "name": "spine"
-            },
-            "cf_upgrade_operational_state": null
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-Based on the output, `spine-1` device is being rebooted at the moment of the GraphQL query response. This could be used by an automation system to prevent OS upgrades on `spine-2`, `spine-3`, `spine-4`.

nautobot/docs/user-guide/core-data-model/dcim/devicetype.md

@@ -1,44 +0,0 @@
-# Device Types
-
-A device type represents a particular make and model of hardware that exists in the real world. Device types define the physical attributes of a device (rack height and depth) and its individual components (console, power, network interfaces, and so on).
-
-Device types are instantiated as devices installed within locations and/or equipment racks. For example, you might define a device type to represent a Juniper EX4300-48T network switch with 48 Ethernet interfaces. You can then create multiple _instances_ of this type named "switch1," "switch2," and so on. Each device will automatically inherit the components (such as interfaces) of its device type at the time of creation. However, changes made to a device type will **not** apply to instances of that device type retroactively.
-
-Some devices house child devices which share physical resources, like space and power, but which functional independently from one another. A common example of this is blade server chassis. Each device type is designated as one of the following:
-
-* A parent device (which has device bays)
-* A child device (which must be installed within a device bay)
-* Neither
-
-!!! note
-    This parent/child relationship is **not** suitable for modeling chassis-based devices, wherein child members share a common control plane. Instead, line cards and similarly non-autonomous hardware should be modeled as inventory items within a device, with any associated interfaces or other components assigned directly to the device.
-
-## Device Component Templates
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).
-
-Each device type is assigned a number of component templates which define the physical components within a device. These are:
-
-* Console ports
-* Console server ports
-* Power ports
-* Power outlets
-* Network interfaces
-* Front ports
-* Rear ports
-* Device bays (which house child devices)
-
-Whenever a new device is created, its components are automatically created per the templates assigned to its device type. For example, a Juniper EX4300-48T device type might have the following component templates defined:
-
-* One template for a console port ("Console")
-* Two templates for power ports ("PSU0" and "PSU1")
-* 48 templates for 1GE interfaces ("ge-0/0/0" through "ge-0/0/47")
-* Four templates for 10GE interfaces ("xe-0/2/0" through "xe-0/2/3")
-
-Once component templates have been created, every new device that you create as an instance of this type will automatically be assigned each of the components listed above. However, this automation occurs only when a device is first created: Adding or removing components on a device type does not automatically change existing device instances based on that device type.
-
-!!! note
-    Assignment of components from templates occurs only at the time of device creation. If you modify the templates of a device type, it will not affect devices which have already been created. This is intentional and by design as device type templates may evolve over time in your organization. However, you always have the option of adding, modifying, or deleting components on existing devices.
-
-    Consider also that automatically changing components of existing devices when a device-type changes would require Nautobot to make very dangerous assumptions. For example, suppose you had a device type which included a specific line card with a specific set of interfaces. After creating some devices, representing your existing deployment of this device type, your deployment for new devices of this type changed to include a different line card and hence different interfaces, so you decided to update the device-type templates accordingly. If Nautobot were to automatically propagate this change to all existing devices of this type, it would result in an incorrect reflection of the reality that all existing devices have not yet been retrofitted with the new line card.

nautobot/docs/user-guide/core-data-model/dcim/frontport.md

@@ -1,6 +0,0 @@
-# Front Ports
-
-Front ports are pass-through ports used to represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in Nautobot as front ports. Each port is assigned a physical type, and must be mapped to a specific rear port on the same device. A single rear port may be mapped to multiple rear ports, using numeric positions to annotate the specific alignment of each.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).