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

nautobot/docs/user-guide/administration/configuration/required-settings.md

@@ -1,244 +0,0 @@
-# Required Configuration Settings
-
-## ALLOWED_HOSTS
-
-Environment Variable: `NAUTOBOT_ALLOWED_HOSTS` specified as a space-separated quoted string (e.g. `NAUTOBOT_ALLOWED_HOSTS="localhost 127.0.0.1 example.com"`).
-
-This is a list of valid fully-qualified domain names (FQDNs) and/or IP addresses that can be used to reach the Nautobot service. Usually this is the same as the hostname for the Nautobot server, but can also be different; for example, when using a reverse proxy serving the Nautobot website under a different FQDN than the hostname of the Nautobot server. To help guard against [HTTP Host header attacks](https://docs.djangoproject.com/en/stable/topics/security/#host-headers-virtual-hosting), Nautobot will not permit access to the server via any other hostnames (or IPs).
-
-Keep in mind that by default Nautobot sets [`USE_X_FORWARDED_HOST`](https://docs.djangoproject.com/en/stable/ref/settings/#use-x-forwarded-host) to `True`, which means that if you're using a reverse proxy, the FQDN used to reach that reverse proxy needs to be in this list.
-
-!!! note
-    This parameter must always be defined as a list or tuple, even if only a single value is provided.
-
-Example:
-
-```python
-ALLOWED_HOSTS = ['nautobot.example.com', '192.0.2.123']
-```
-
-!!! tip
-    If there is more than one hostname in this list, you *may* also need to set [`CSRF_TRUSTED_ORIGINS`](optional-settings.md#csrf_trusted_origins) as well.
-
-If you are not yet sure what the domain name and/or IP address of the Nautobot installation will be, and are comfortable accepting the risks in doing so, you can set this to a wildcard (asterisk) to allow all host values:
-
-```python
-ALLOWED_HOSTS = ['*']
-```
-
-!!! warning
-    It is not recommended to leave this value as `['*']` for production deployments. Please see the [official Django documentation on `ALLOWED_HOSTS`](https://docs.djangoproject.com/en/stable/ref/settings/#allowed-hosts) for help.
-
----
-
-## DATABASES
-
-Nautobot requires access to a supported database service to store data. This service can run locally on the Nautobot server or on a remote system. The following parameters must be defined within the `DATABASES` dictionary:
-
-* `NAME` - Database name
-* `USER` - Database username
-* `PASSWORD` - Database password
-* `HOST` - Name or IP address of the database server (use `localhost` if running locally)
-* `PORT` - The port to use when connecting to the database. An empty string means the default port for your selected backend. (PostgreSQL: `5432`, MySQL: `3306`)
-* `CONN_MAX_AGE` - Lifetime of a [persistent database connection](https://docs.djangoproject.com/en/stable/ref/databases/#persistent-connections), in seconds (300 is the default)
-* `ENGINE` - The database backend to use. This can be either `django.db.backends.postgresql` or `django.db.backends.mysql`.  If `METRICS_ENABLED` is `True` this can also be either `django_prometheus.db.backends.postgresql` or `django_prometheus.db.backends.mysql`
-
-The following environment variables may also be set for each of the above values:
-
-* `NAUTOBOT_DB_NAME`
-* `NAUTOBOT_DB_USER`
-* `NAUTOBOT_DB_PASSWORD`
-* `NAUTOBOT_DB_HOST`
-* `NAUTOBOT_DB_PORT`
-* `NAUTOBOT_DB_TIMEOUT`
-* `NAUTOBOT_DB_ENGINE`
-
-+++ 1.1.0
-    The `NAUTOBOT_DB_ENGINE` setting was added along with support for MySQL.
-
-!!! warning
-    Nautobot supports either MySQL or PostgreSQL as a database backend. You must make sure that the `ENGINE` setting matches your selected database backend or **you will be unable to connect to the database**.
-
-Example:
-
-```python
-DATABASES = {
-    'default': {
-        'NAME': 'nautobot',                         # Database name
-        'USER': 'nautobot',                         # Database username
-        'PASSWORD': 'awesome_password',             # Database password
-        'HOST': 'localhost',                        # Database server
-        'PORT': '',                                 # Database port (leave blank for default)
-        'CONN_MAX_AGE': 300,                        # Max database connection age
-        'ENGINE': 'django.db.backends.postgresql',  # Database driver ("mysql" or "postgresql")
-    }
-}
-```
-
-!!! note
-    Nautobot supports all database options supported by the underlying Django framework. For a complete list of available parameters, please see [the official Django documentation on `DATABASES`](https://docs.djangoproject.com/en/stable/ref/settings/#databases).
-
-### MySQL Unicode Settings
-
-+++ 1.1.0
-
-!!! tip
-    By default, MySQL is case-insensitive in its handling of text strings. This is different from PostgreSQL which is case-sensitive by default. We strongly recommend that you configure MySQL to be case-sensitive for use with Nautobot, either when you enable the MySQL server, or when you create the Nautobot database in MySQL. If you follow the provided installation instructions for CentOS or Ubuntu, the recommended steps there will include the appropriate database configuration.
-
-When using MySQL as a database backend, and you want to enable support for Unicode characters like the beloved poop emoji, you'll need to update your settings.
-
-If you try to use emojis without this setting, you will encounter a server error along the lines of `Incorrect string value`, because you are running afoul of the legacy implementation of Unicode (aka `utf8`) encoding in MySQL. The `utf8` encoding in MySQL is limited to 3-bytes per character. Newer Unicode emoji require 4-bytes.
-
-To properly support using such characters, you will need to create an entry in `DATABASES` -> `default` -> `OPTIONS` with the value `{"charset": "utf8mb4"}` in your `nautobot_config.py` and restart all Nautobot services. This will tell MySQL to always use `utf8mb4` character set for database client connections.
-
-For example:
-
-```python
-DATABASES = {
-    "default": {
-        # Other settings...
-        "OPTIONS": {"charset": "utf8mb4"},  # Add this line
-    }
-}
-```
-
-+++ 1.1.0
-    If you have generated a new `nautobot_config.py` using `nautobot-server init`, this line is already there for you in your config. You'll just need to uncomment it!
-
-+/- 1.1.5
-    If you have generated a new `nautobot_config.py` using `nautobot-server init`, this line is already present in your config and no action is required.
-
----
-
-## Redis Settings
-
-[Redis](https://redis.io/) is an in-memory data store similar to memcached. It is required to support Nautobot's
-caching, task queueing, and webhook features. The connection settings are explained here, allowing Nautobot to connect
-to different Redis instances/databases per feature.
-
-!!! warning
-    It is highly recommended to keep the Redis databases for caching and tasks separate. Using the same database number on the same Redis instance for both may result in queued background tasks being lost during cache flushing events. For this reason, the default settings utilize database `1` for caching and database `0` for tasks.
-
-!!! tip
-    The default Redis settings in your `nautobot_config.py` should be suitable for most deployments and should only require customization for more advanced configurations.
-
-### Caching
-
-For more details on Nautobot's caching, including TLS and HA configuration, see the guide on [Caching](../../administration/guides/caching.md).
-
-### Task Queuing
-
-#### CACHES
-
-The [`django-redis`](https://github.com/jazzband/django-redis) Django plugin is used to enable Redis as a concurrent write lock for preventing race conditions when allocating IP address objects. The `CACHES` setting is required to simplify the configuration for `django-redis`.
-
-!!! important
-    Nautobot also utilizes the built-in [Django cache framework](https://docs.djangoproject.com/en/stable/topics/cache/) (which also relies on the `CACHES` setting) to perform caching.
-
-Default:
-
-```python
-# Uncomment the following line to configure TLS/SSL
-# import ssl
-
-CACHES = {
-    "default": {
-        "BACKEND": "django_redis.cache.RedisCache",
-        "LOCATION": "redis://localhost:6379/1",
-        "TIMEOUT": 300,
-        "OPTIONS": {
-            "CLIENT_CLASS": "django_redis.client.DefaultClient",
-            # Uncomment the following lines to configure TLS/SSL
-            # "CONNECTION_POOL_KWARGS": {
-            #     "ssl_cert_reqs": ssl.CERT_REQUIRED,
-            #     "ssl_ca_certs": "/opt/nautobot/redis/ca.crt",
-            #     "ssl_certfile": "/opt/nautobot/redis/tls.crt",
-            #     "ssl_keyfile": "/opt/nautobot/redis/tls.key",
-            # },
-        },
-    }
-}
-```
-
-The following environment variables may also be set for some of the above values:
-
-* `NAUTOBOT_CACHES_BACKEND`
-
-+/- 2.0.0
-    The default value of `CACHES["default"]["LOCATION"]` has changed from `redis://localhost:6379/0` to `redis://localhost:6379/1`, as Django's native caching is now taking the role previously occupied by `django-cacheops`.
-
-### Task Queuing with Celery
-
-+++ 1.1.0
-
-Out of the box you do not need to make any changes to utilize task queueing with Celery. All of the default settings are sufficient for most installations.
-
-In the event you do need to make customizations to how Celery interacts with the message broker such as for more advanced clustered deployments, the following setting may be changed.
-
-#### CELERY_BROKER_URL
-
-This setting tells Celery and its workers how and where to communicate with the message broker. The default value for this points to `redis://localhost:6379/0`. Please see the [optional settings documentation for `CELERY_BROKER_URL`](optional-settings.md#celery_broker_url) for more information on customizing this setting.
-
-#### Configuring Celery with TLS
-
-Optionally, you can configure Celery to use custom SSL certificates to connect to redis by setting the following variables:
-
-```python
-import ssl
-
-CELERY_REDIS_BACKEND_USE_SSL = {
-    "ssl_cert_reqs": ssl.CERT_REQUIRED,
-    "ssl_ca_certs": "/opt/nautobot/redis/ca.crt",
-    "ssl_certfile": "/opt/nautobot/redis/tls.crt",
-    "ssl_keyfile": "/opt/nautobot/redis/tls.key",
-}
-CELERY_BROKER_USE_SSL = CELERY_REDIS_BACKEND_USE_SSL
-```
-
-Please see the celery [documentation](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_use_ssl) for additional details.
-
-#### Configuring Celery for High Availability
-
-High availability clustering of Redis for use with Celery can be performed using Redis Sentinel. Please see documentation section on configuring [Celery for Redis Sentinel](../../administration/guides/caching.md#celery-sentinel-configuration) for more information.
-
----
-
-## SECRET_KEY
-
-Environment Variable: `NAUTOBOT_SECRET_KEY`
-
-This is a secret, random string used to assist in the creation new cryptographic hashes for passwords and HTTP cookies. The key defined here should not be shared outside of the configuration file. `SECRET_KEY` can be changed at any time, however be aware that doing so will invalidate all existing sessions.
-
-`SECRET_KEY` should be at least 50 characters in length and contain a random mix of letters, digits, and symbols.
-
-!!! note
-    A unique `SECRET_KEY` is generated for you automatically when you use `nautobot-server init` to create a new `nautobot_config.py`.
-
-You may run `nautobot-server generate_secret_key` to generate a new key at any time.
-
-```no-highlight
-nautobot-server generate_secret_key
-```
-
-Sample output:
-
-```no-highlight
-+$_kw69oq&fbkfk6&q-+ksbgzw1&061ghw%420u3(wen54w(m
-```
-
-Alternatively use the following command to generate a secret even before `nautobot-server` is runnable:
-
-```no-highlight
-LC_ALL=C tr -cd '[:lower:][:digit:]!@#$%^&*(\-_=+)' < /dev/urandom | fold -w50 | head -n1
-```
-
-Example output:
-
-```no-highlight
-9.V$@Kxkc@@Kd@z<a/=.J-Y;rYc79<y@](9o9(L(*sS)Q+ud5P
-```
-
-!!! warning
-    In the case of a highly available installation with multiple web servers, `SECRET_KEY` must be identical among all servers in order to maintain a persistent user session state.
-
-For more details see [Nautobot Configuration](index.md).

nautobot/docs/user-guide/administration/guides/caching.md

@@ -1,108 +0,0 @@
-# Caching
-
-A fundamental trade-off in dynamic websites like Nautobot is that, well, they’re dynamic. Each time a user requests a page, the Web server makes all sorts of calculations – from database queries to template rendering to business logic – to create the page that your site’s visitor sees. This is a lot more expensive, from a processing-overhead perspective, than your standard read-a-file-off-the-filesystem server arrangement.
-
-That’s where caching comes in.
-
-To cache something is to save the result of an expensive calculation so that you don’t have to perform the calculation next time.
-
-Nautobot makes extensive use of caching; this is not a simple topic but it's a useful one for a Nautobot administrator to understand, so read on if you please.
-
-## How it Works
-
---- 2.0.0
-    `django-cacheops` has been removed as a Nautobot dependency and is no longer used.
-
-Caching is a complex topic and there are some important details to clarify with how caching is implemented and configured in Nautobot.
-
-### Caching in Django
-
-Django includes its own [cache framework](https://docs.djangoproject.com/en/stable/topics/cache/). Nautobot uses this cache framework in a limited number of cases.
-
-### `CACHES` and `django-redis`
-
-The [`CACHES`](../configuration/required-settings.md#caches) setting is used to, among other things, configure Django's built-in caching. *This is a required setting*. Here's why:
-
-Nautobot uses the [`django-redis`](https://github.com/jazzband/django-redis) Django plugin which allows it to use Redis as a backend for caching and session storage. This is used to provide a concurrent write lock for preventing race conditions when allocating IP address objects.
-
-`django-redis` *also* uses the [`CACHES`](../configuration/required-settings.md#caches) setting, in its case to simplify the configuration for establishing concurrent write locks.
-
-## High Availability Caching
-
-[Redis](https://redis.io/) provides two different methods to achieve high availability: The first is [Redis Sentinel](https://redis.io/topics/sentinel) and the second is the newer [Redis Clustering](https://redis.io/topics/cluster-tutorial) feature. Currently, Nautobot only supports Redis Sentinel for high availability.
-
-### Using Redis Sentinel
-
-The installation/configuration of the [Redis Sentinel](https://redis.io/topics/sentinel) cluster itself is outside the scope of this document, this section is intended to provide the steps necessary to configure Nautobot to connect to a Sentinel cluster.
-
-We need to configure `django-redis` and `celery` to use Sentinel. Each library is configured differently, so please pay close attention to the details.
-
-#### `django-redis` Sentinel Configuration
-
-Notable settings:
-
-* `SENTINELS`: List of tuples or tuple of tuples with each inner tuple containing the name or IP address
-of the Redis server and port for each sentinel instance to connect to
-* `LOCATION`: Similar to a redis URL, *however*, the hostname in the URL is the master/service name in redis sentinel
-* `SENTINEL_KWARGS`: Options which will be passed directly to [Redis Sentinel](https://github.com/redis/redis-py#sentinel-support)
-* `PASSWORD`: The redis password (if set), the `SENTINEL_KWARGS["password"]` setting is the password for Sentinel
-
-Example:
-
-```python
-DJANGO_REDIS_CONNECTION_FACTORY = "django_redis.pool.SentinelConnectionFactory"
-CACHES = {
-    "default": {
-        "BACKEND": "django_redis.cache.RedisCache",
-        "LOCATION": "redis://nautobot/0",  # in this context 'nautobot' is the redis master/service name
-        "OPTIONS": {
-            "CLIENT_CLASS": "django_redis.client.SentinelClient",
-            "CONNECTION_POOL_CLASS": "redis.sentinel.SentinelConnectionPool",
-            "PASSWORD": "",
-            "SENTINEL_KWARGS": {
-                "password": "",  # likely the same password from above
-            },
-            "SENTINELS": [
-                ("mysentinel.redis.example.com", 26379),
-                ("othersentinel.redis.example.com", 26379),
-                ("thirdsentinel.redis.example.com", 26379)
-            ],
-        },
-    },
-}
-```
-
-For more details on configuring django-redis with Redis Sentinel, please see the documentation for [Django Redis](https://github.com/jazzband/django-redis#use-the-sentinel-connection-factory).
-
-#### `celery` Sentinel Configuration
-
-+/- 2.0.0
-    Celery now stores results in the Nautobot database. The `CELERY_RESULT_BACKEND` and `CELERY_RESULT_BACKEND_TRANSPORT_OPTIONS` should not be changed from their default values.
-
-!!! note
-    Celery is not directly related to caching but it does utilize Redis, therefore in more advanced deployments if Redis Sentinel is required for caching, Celery must also be configured to use Redis Sentinel to high availability.
-
-Celery Sentinel configuration is controlled by two settings within your `nautobot_config.py`:
-
-* [`CELERY_BROKER_URL`](../configuration/optional-settings.md#celery_broker_url)
-* [`CELERY_BROKER_TRANSPORT_OPTIONS`](../configuration/optional-settings.md#celery_broker_transport_options)
-
-```python
-redis_password = ""
-sentinel_password = ""
-
-CELERY_BROKER_URL = (
-    f"sentinel://:{redis_password}@mysentinel.redis.example.com:26379;"
-    f"sentinel://:{redis_password}@othersentinel.redis.example.com:26379;"
-    # The final entry must not have the `;` delimiter
-    f"sentinel://:{redis_password}@thirdsentinel.redis.example.com:26379"
-)
-CELERY_BROKER_TRANSPORT_OPTIONS = {
-    "master_name": "nautobot",
-    "sentinel_kwargs": {"password": sentinel_password},
-}
-```
-
-Please see the official Celery documentation for more information on how to [configure Celery to use Redis Sentinel](https://docs.celeryq.dev/en/stable/getting-started/backends-and-brokers/redis.html?highlight=sentinel#configuration).
-
-Please also see the [Nautobot documentation on required settings for Celery](../configuration/required-settings.md#task-queuing-with-celery) for additional information.

nautobot/docs/user-guide/administration/guides/celery-queues.md

@@ -1,42 +0,0 @@
-# Celery Task Queues
-
-If you're planning to run multiple jobs, leverage job hooks or are finding that your jobs are taking too long to complete you may want to consider deploying multiple celery workers with different queues for different types of tasks.
-
-## How Celery Task Queues Work
-
-The default celery behavior is:
-
-- [`--queue celery`](https://docs.celeryq.dev/en/stable/reference/cli.html#cmdoption-celery-worker-Q)
-- [`--concurrency`](https://docs.celeryq.dev/en/stable/reference/cli.html#cmdoption-celery-worker-c) set to the number of CPUs detected on the system
-- [`worker_prefetch_multiplier=4`](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-worker_prefetch_multiplier)
-
-This means that a worker running on a 4 core system will run 4 tasks concurrently and reserve a maximum of 16 more tasks from the queue named `celery`. If you have a mixture of long running and short running tasks with a single queue, you could find your long running tasks blocking the shorter tasks.
-
-## Recommended Worker Deployment
-
-Each environment is unique but it's generally a good idea to add at least one extra worker on a separate queue for running jobs. Nautobot uses the default `celery` queue to perform some background tasks and if the queue is full of long running jobs these system tasks could take a long time to execute. This could cause performance problems or unexpected behavior in Nautobot. A new worker can be deployed on a separate queue by using the [`nautobot-worker.service` systemd service](../installation/services.md#celery-worker) and modifying the `ExecStart` line to include a [`--queues` option](https://docs.celeryq.dev/en/stable/reference/cli.html#cmdoption-celery-worker-Q). Example:
-
-```ini
-ExecStart=/opt/nautobot/bin/nautobot-server celery worker --loglevel INFO --pidfile /var/tmp/nautobot-worker-jobqueue.pid --queues job_queue
-```
-
-This will create a worker that will only process tasks sent to the `job_queue` celery queue. You can use this worker to run jobs while the rest of Nautobot's background tasks will be processed by the default celery worker listening to the `celery` queue.
-
-!!! info
-    Workers can be configured to listen to multiple queues by supplying a comma separated list of queues to the `--queues` argument. See the [celery workers guide](https://docs.celeryq.dev/en/stable/userguide/workers.html#queues) for more information.
-
-!!! warning
-    If a job is sent to a queue that no workers are listening to, that job will remain in pending status until it's purged or a worker starts listening to that queue and processes the job. Be sure that the queue name on the worker and jobs match.
-
-## Concurrency Setting
-
-If you have long running jobs that use little CPU resources you may want to increase your [`--concurrency`](https://docs.celeryq.dev/en/stable/reference/cli.html#cmdoption-celery-worker-c) setting on your worker to increase the number of jobs that run in parallel. For example, you may have a job that logs into a device over ssh and collects some information from the command line. This task could take a long time to run but consume minimal CPU so your system may be able to run many more of these tasks in parallel than the default concurrency setting allows. The `--concurrency` setting can be modified by adding the command line option in the `ExecStart` line in your systemd service:
-
-```ini
-ExecStart=/opt/nautobot/bin/nautobot-server celery worker --loglevel INFO --pidfile /var/tmp/nautobot-worker-jobqueue.pid --queues job_queue --concurrency 64
-```
-
-You may have to change this setting multiple times to find what works best in your environment.
-
-!!! warning
-    Modifying your concurrency setting may increase the CPU and will increase the memory load on your celery worker by at least 175MB per concurrent thread. Only change this setting if you have monitoring systems in place to monitor the system resources on your worker.

nautobot/docs/user-guide/administration/guides/healthcheck.md

@@ -1,11 +0,0 @@
-# Healthcheck Endpoint
-
-Nautobot includes a health check endpoint `/health` which utilizes the [django-health-check](https://github.com/KristianOellegaard/django-health-check) project and some custom health checks (database connection and cache availability).  This endpoint is designed for use by an optional load balancer placed in front of Nautobot to determine the health of the Nautobot application server.  By default the health check enables checks for the following:
-
-* Database Backend
-* Caching Backend
-* Storage Backend
-
-In addition to exposing a health check URL the `nautobot-server` utility also provides a [`health_check` management command](../tools/nautobot-server.md#health_check) which provides the same information as the web interface.
-
-Additional health checks are available as part of the [django-health-check](https://github.com/KristianOellegaard/django-health-check) project and can be added to the [`EXTRA_INSTALLED_APPS`](../configuration/optional-settings.md#extra-applications) configuration variable as desired.  The Nautobot server is healthy if the HTTP response is 200 from a GET request to `/health`, a web UI is also available at the same endpoint for human consumption.

nautobot/docs/user-guide/administration/guides/permissions.md

@@ -1,98 +0,0 @@
-# Permissions
-
-Nautobot provides an object-based permissions framework, which replace's Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in Nautobot, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only locations within a particular parent location, or to modify only VLANs with a numeric ID within a certain range.
-
-See the documentation on [user permissions](../../platform-functionality/users/objectpermission.md).
-
-## Example Constraint Definitions
-
-| Constraints                                           | Description                                                   |
-|-------------------------------------------------------|---------------------------------------------------------------|
-| `{"status__name": "Active"}`                          | Status name is active                                         |
-| `{"status__name__in": ["Planned", "Reserved"]}`       | Status name is active **OR** reserved                         |
-| `{"status__name": "Active", "role__name": "testing"}` | Status name is active **OR** role name is testing             |
-| `{"name__startswith": "Foo"}`                         | Name starts with "Foo" (case-sensitive)                       |
-| `{"name__iendswith": "bar"}`                          | Name ends with "bar" (case-insensitive)                       |
-| `{"vid__gte": 100, "vid__lt": 200}`                   | VLAN ID is greater than or equal to 100 **AND** less than 200 |
-| `[{"vid__lt": 200}, {"status__name": "Reserved"}]`    | VLAN ID is less than 200 **OR** status is reserved            |
-
-## Permissions Enforcement
-
-### Viewing Objects
-
-Object-based permissions work by filtering the database query generated by a user's request to restrict the set of objects returned. When a request is received, Nautobot first determines whether the user is authenticated and has been granted to perform the requested action. For example, if the requested URL is `/dcim/devices/`, Nautobot will check for the `dcim.view_device` permission. If the user has not been assigned this permission (either directly or via a group assignment), Nautobot will return a 403 (forbidden) HTTP response.
-
-If the permission _has_ been granted, Nautobot will compile any specified constraints for the model and action. For example, suppose two permissions have been assigned to the user granting view access to the device model, with the following constraints:
-
-```json
-[
-    {"location__name__in":  ["NYC1", "NYC2"]},
-    {"location__location_type__name__in":  ["City"]},
-    {"status__name":  "Offline", "tenant__isnull":  true}
-]
-```
-
-This grants the user access to view any device that is assigned to a location named NYC1 or NYC2 with location type `City`, **or** which has a status name of "Offline" and has no tenant assigned. These constraints are equivalent to the following ORM query:
-
-```no-highlight
-Location.objects.filter(
-    Q(location__name__in=['NYC1', 'NYC2']),
-    Q(location__location_type__name__in=['City']),
-    Q(status__name='Active', tenant__isnull=True)
-)
-```
-
-### Creating and Modifying Objects
-
-The same sort of logic is in play when a user attempts to create or modify an object in Nautobot, with a twist. Once validation has completed, Nautobot starts an atomic database transaction to facilitate the change, and the object is created or saved normally. Next, still within the transaction, Nautobot issues a second query to retrieve the newly created/updated object, filtering the restricted queryset with the object's primary key. If this query fails to return the object, Nautobot knows that the new revision does not match the constraints imposed by the permission. The transaction is then rolled back, leaving the database in its original state prior to the change, and the user is informed of the violation.
-
-## Assigning Permissions
-
-Permissions are implemented by assigning them to specific users and/or to groups of users. Users can have a combination of permissions and groups assigned to their account. All of the permissions granted to the user's groups and directly to the user's account will be used when determining authorization to access an object or view.
-
-### Assigning Permissions to Individual Users
-
-Permissions can be related directly to users from the Admin UI or the API:
-
-| -                                                                      | Admin UI | API |
-| ---------------------------------------------------------------------- | -------- | --- |
-| Staff superusers                                                         | Yes      | Yes |
-| Non-staff superusers                                                     | No       | Yes |
-| Staff users with `users.add_permission` or `users.change_permission`     | Yes      | Yes |
-| Non-staff users with `users.add_permission` or `users.change_permission` | No       | Yes |
-
-Multiple permissions can be assigned to a user account.
-
-!!! info
-    User permission relationships can be managed in the Admin UI by modifying the user or the permission.
-
-!!! warning
-    Granting a user `users.change_permission` or `users.add_permission` gives the user the ability to modify their own permissions. This permission should be restricted to trusted accounts and should be considered the same as giving a user full access.
-
-### Creating Groups
-
-Groups of users can be created to provide role-based access control and simplify user permissions management. Permissions related to a group will apply to all users in the group. A user can belong to any number of groups. Groups can be created from the Admin UI or the API:
-
-| -                                                           | Admin UI | API |
-| ----------------------------------------------------------- | -------- | --- |
-| Superusers                                                  | Yes      | Yes |
-| Users with `auth.add_group` or `auth.change_group`          | No       | Yes |
-
-### Adding Users to Groups
-
-Users can be added to groups through the Admin UI by superusers or automatically assigned to externally authenticated users through the [`EXTERNAL_AUTH_DEFAULT_GROUPS`](../configuration/optional-settings.md#external_auth_default_groups) and [`EXTERNAL_AUTH_DEFAULT_PERMISSIONS`](../configuration/optional-settings.md#external_auth_default_permissions) settings. Nautobot groups can optionally be mapped to LDAP groups when using [LDAP authentication](../configuration/authentication/ldap.md#user-groups-for-permissions).
-
-### Assigning Permissions to Groups
-
-Permissions can be related to groups by superusers or users with `users.add_permission` or `users.change_permission` permissions.
-
-| -                                                                      | Admin UI | API |
-| ---------------------------------------------------------------------- | -------- | --- |
-| Superusers                                                             | Yes      | Yes |
-| Staff users with `users.add_permission` or `users.change_permission`   | Yes      | Yes |
-| Regular users with `users.add_permission` or `users.change_permission` | No       | Yes |
-
-Multiple permissions can be assigned to a user group.
-
-!!! info
-    Group permission relationships can be managed in the Admin UI by modifying the group (superusers only) or the permission.

nautobot/docs/user-guide/administration/guides/prometheus-metrics.md

@@ -1,55 +0,0 @@
-# Prometheus Metrics
-
-Nautobot supports optionally exposing native Prometheus metrics from the application. [Prometheus](https://prometheus.io/) is a popular time series metric platform used for monitoring.
-
-## Configuration
-
-Metrics are not exposed by default. Metric exposition can be toggled with the `METRICS_ENABLED` configuration setting which exposes metrics at the `/metrics` HTTP endpoint, e.g. `https://nautobot.local/metrics`.
-
-In addition to the `METRICS_ENABLED` setting, database and/or caching metrics can also be enabled by changing the database engine and/or caching backends from `django.db.backends` / `django_redis.cache` to `django_prometheus.db.backends` / `django_prometheus.cache.backends.redis`:
-
-```python
-DATABASES = {
-    "default": {
-        # Other settings...
-        "ENGINE": "django_prometheus.db.backends.postgresql",  # use "django_prometheus.db.backends.mysql" with MySQL
-    }
-}
-
-# Other settings...
-CACHES = {
-    "default": {
-        # Other settings...
-        "BACKEND": "django_prometheus.cache.backends.redis.RedisCache",
-    }
-}
-```
-
-For more information see the [django-prometheus](https://github.com/korfuri/django-prometheus) docs.
-
-## Metric Types
-
-Nautobot makes use of the [django-prometheus](https://github.com/korfuri/django-prometheus) library to export a number of different types of metrics, including:
-
-- Per model insert, update, and delete counters
-- Per view request counters
-- Per view request latency histograms
-- Request body size histograms
-- Response body size histograms
-- Response code counters
-- Database connection, execution, and error counters
-- Cache hit, miss, and invalidation counters
-- Django middleware latency histograms
-- Other Django related metadata metrics
-
-For the exhaustive list of exposed metrics, visit the `/metrics` endpoint on your Nautobot instance.
-
-## Multi Processing Notes
-
-When deploying Nautobot in a multi-process manner (e.g. running multiple uWSGI workers) the Prometheus client library requires the use of a shared directory to collect metrics from all worker processes. To configure this, first create or designate a local directory to which the worker processes have read and write access, and then configure your WSGI service (e.g. uWSGI) to define this path as the `prometheus_multiproc_dir` environment variable.
-
-!!! warning
-    If having accurate long-term metrics in a multi-process environment is crucial to your deployment, it's recommended you use the `uwsgi` library instead of `gunicorn`. The issue lies in the way `gunicorn` tracks worker processes (vs `uwsgi`) which helps manage the metrics files created by the above configurations. If you're using Nautobot with gunicorn in a containerized environment following the one-process-per-container methodology, then you will likely not need to change to `uwsgi`. More details can be found in  [issue #3779](https://github.com/netbox-community/netbox/issues/3779#issuecomment-590547562).
-
-!!! note
-    Metrics from the celery worker are not available from Nautobot at this time.  However, additional tools such as [flower](https://flower.readthedocs.io/en/latest/) can be used to monitor the celery workers until these metrics are exposed through Nautobot.

nautobot/docs/user-guide/administration/guides/replicating-nautobot.md

@@ -1,70 +0,0 @@
-# Replicating Nautobot
-
-## Replicating the Database
-
-Nautobot employs a [PostgreSQL](https://www.postgresql.org/) database, so general PostgreSQL best practices apply here. The database can be written to a file and restored using the `pg_dump` and `psql` utilities, respectively.
-
-!!! note
-    The examples below assume that your database is named `nautobot`.
-
-### Export the Database
-
-Use the `pg_dump` utility to export the entire database to a file:
-
-```no-highlight
-pg_dump nautobot > nautobot.sql
-```
-
-When replicating a production database for development purposes, you may find it convenient to exclude changelog data, which can easily account for the bulk of a database's size. To do this, exclude the `extras_objectchange` table data from the export. The table will still be included in the output file, but will not be populated with any data.
-
-```no-highlight
-pg_dump --exclude-table-data=extras_objectchange nautobot > nautobot.sql
-```
-
-### Load an Exported Database
-
-When restoring a database from a file, it's recommended to delete any existing database first to avoid potential conflicts.
-
-!!! warning
-    The following will destroy and replace any existing instance of the database.
-
-```no-highlight
-psql -c 'drop database nautobot'
-psql -c 'create database nautobot'
-psql nautobot < nautobot.sql
-```
-
-Keep in mind that PostgreSQL user accounts and permissions are not included with the dump: You will need to create those manually if you want to fully replicate the original database (see the [installation docs](../installation/index.md#installing-nautobot-dependencies)). When setting up a development instance of Nautobot, it's strongly recommended to use different credentials anyway.
-
-### Export the Database Schema
-
-If you want to export only the database schema, and not the data itself (e.g. for development reference), do the following:
-
-```no-highlight
-pg_dump -s nautobot > nautobot_schema.sql
-```
-
----
-
-## Replicating Uploaded Media
-
-By default, Nautobot stores uploaded files (such as image attachments) in its media directory. To fully replicate an instance of Nautobot, you'll need to copy both the database and the media files.
-
-!!! note
-    These operations are not necessary if your installation is utilizing a [remote storage backend](../configuration/optional-settings.md#storage_backend).
-
-### Archive the Media Directory
-
-Execute the following command (which may need to be changed if you're using non-default storage path settings):
-
-```no-highlight
-tar -czf nautobot_media.tar.gz $NAUTOBOT_ROOT/media/
-```
-
-### Restore the Media Directory
-
-To extract the saved archive into a new installation, run the following from the installation root:
-
-```no-highlight
-tar -xf nautobot_media.tar.gz
-```