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

nautobot/docs/user-guide/feature-guides/git-data-source.md

@@ -1,307 +0,0 @@
-# Git as a Data Source
-
-The "Git™ as a Data Source" feature was developed to provide the ability to populate existing data, templates, scripts, and much more into Nautobot; while leveraging the benefits that tools such as GitHub and GitLab already provide, including issue tracking, discussions, pipelines, and approvals.  For example having the ability to have users approve the YAML data that is used for Nautobot  `config context` along with running tests on that data, or having the users approve Jinja2 templates that are used for Nautobot `export templates`.  These examples and more can be accomplished by used Git as a Data Source.
-
-For more technical details on how to use this feature, please see the documentation on [Git Repositories](../platform-functionality/gitrepository.md).
-
-## Supported Providers
-
-The feature uses the concept of a `provides` field to map a repository to a use case. A list of the supported options is provided below.
-
-### Core Functionality
-
-|Name|Summary|
-|:--|:--|
-|[Export Templates](../platform-functionality/exporttemplate.md)|Nautobot allows users to define custom templates that can be used when exporting objects.|
-|[Jobs](../platform-functionality/jobs/index.md)|Jobs are a way for users to execute custom logic on demand from within the Nautobot UI. Jobs can interact directly with Nautobot data to accomplish various data creation, modification, and validation tasks.|
-|[Config Contexts](../core-data-model/extras/configcontext.md)|Config contexts can be used to provide additional data that you can't natively store in Nautobot.|
-|[Config Context Schemas](../core-data-model/extras/configcontextschema.md)|Schemas enforce data validation on config contexts.|
-
-### Examples of Plugins Defining Additional Providers
-
-Additional Git providers can be added by using Nautobot's flexible plugin system.
-
-|Name|Summary|Related Plugin|
-|:--|:--|:--|
-|Backup Configs|Backup configuration data.|[Golden Config](https://github.com/nautobot/nautobot-plugin-golden-config)|
-|Intended Configs|Stores the intended configurations, this grabs Nautobot data and runs through Jinja Templates.|[Golden Config](https://github.com/nautobot/nautobot-plugin-golden-config)|
-|Jinja Templates|Repository that holds Jinja templates to be used to generate intended configs.|[Golden Config](https://github.com/nautobot/nautobot-plugin-golden-config)|
-
-## Repository Details
-
-This table defines repository parameters that are required to establish a repository connection.
-
-|Field|Explanation|
-|:--|:--|
-|Name|User friendly name for the repo.|
-|Slug|Computer-friendly name for the repo. Auto-generated based on the `name` provided, but you can change it if you wish.|
-|Remote URL|The URL pointing to the Git repo. Current git url usage is limited to `http` or `https`.|
-|Branch|The branch in the Git repo to use. Defaults to `main`.|
-|Secrets Group|(Optional) Grouping containing a *HTTP token* and/or *HTTP username* as needed to access the repository.|
-|Provides|Resource type(s) provided by this Git repo.|
-
-- [GitHub Personal Access Token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token)
-- [GitLab Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)
-- [Bitbucket Personal Access Token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html)
-
---- 2.0.0
-    In Nautobot 1.x it was possible to configure the secrets (`username` and/or `token`) for a private Git Repository directly in Nautobot's database. Due to security concerns and maintainability challenges, this option has been removed. To access a private Git repository you now must use Secrets Groups.
-
-## Using Git Data Sources
-
-This section will focus on examples and use the `user-guide` branch on the `demo-git-datasources` repo: `https://github.com/nautobot/demo-git-datasource/tree/user-guide`.
-
-### Export Templates
-
-[Export Templates](../platform-functionality/exporttemplate.md) allow a user to export Nautobot objects based on a custom template.  Export templates can change over time depending on the needs of a user.  Allowing export templates to reference a Git repo makes managing templates easier.
-
-A template can be used to put objects into a specific format for ingestion into another system, tool, or report.  It is possible that different templates are needed depending on specific users or teams.  This can lead to sprawl of export templates.  To keep accurate templates synced with Nautobot the Git Data Sources extensibility feature can be used.
-
-#### Add a Repository
-
-Navigate to the Data Sources Git integration. **Extensibility -> Git Repositories**.
-
-![Menu showing "Git Repositories" Item](./images/git-as-data-source/01-git-data-source.png)
-
-Click [+] or [Add]
-
-That loads a default page to add a repository.
-
-![Add a New Git Repository](./images/git-as-data-source/02-git-data-source.png)
-
-!!! note
-    By default only config contexts, export templates, and jobs are available resource types.  Others may be added when specific plugins are used.
-
-#### Fill out Repository Details
-
-Fill out the details for the Git repository. More information on the inputs can be found in the [fields section](#repository-details).
-
-![Example Details Export-Templates](./images/git-as-data-source/03-git-data-source.png)
-
-As soon as you click on **Create & Sync**, Nautobot will clone and sync the repository and provide status of the job.
-
-!!! note
-    If you are using a self-signed Git repository, the Server Administrator will need to ensure the [`GIT_SSL_NO_VERIFY`](../administration/configuration/optional-settings.md#git_ssl_no_verify) environment variable is set to permit this.
-
-![View of Synchronization Status](./images/git-as-data-source/04-git-data-source.png)
-![Status of Export-Templates](./images/git-as-data-source/06-git-data-source.png)
-
-The repository will now be displayed on the main Git Repository page.
-
-![Default Repository Menu](./images/git-as-data-source/05-git-data-source.png)
-
-Once the repository is synced each template will now be available in the Export Templates section.  **Extensibility -> Export Templates**.
-
-![List of Loaded Export-Templates](./images/git-as-data-source/07-git-data-source.png)
-
-!!! note
-    If the templates don't populate, make sure the Git directory is named `export_templates` and the sub-directory and sub-sub-directory names correctly match the Nautobot `content type`.
-
-Example below:
-
-```no-highlight
-▶ tree export_templates
-export_templates
-└── dcim
-    └── device
-        ├── markdown_export.md
-        ├── text_export.txt
-        └── yaml_export.yml
-
-2 directories, 3 files
-```
-
-#### Modifying a File and Sync Changes
-
-Now that the export templates have been loaded into Nautobot they can be utilized as normal.  For example navigate to **Devices -> Devices** and click on **Export** in the top right corner, the dropdown will now include the templates loaded from the Git repository.
-
-The power of having export templates utilizing the Git integration comes with the native source control features that Git comes with.  To illustrate a simple Git sync within Nautobot assume the following template needs to be updated.
-
-Filename: `/export_templates/dcim/device/yaml_export.yml`
-
-Current contents:
-
-```jinja
----
-{% for device in queryset %}
-{% if device.status %}
-- {{ device.name }}:
-{% endif %}
-{% endfor %}
-...
-```
-
-The template needs to be modified to provide more information than just a list of hostnames. The location needs to be added.
-
-The updated template is now:
-
-```jinja
----
-{% for device in queryset %}
-{% if device.status %}
-- {{ device.name }}:
-  location: {{ device.location }}
-{% endif %}
-{% endfor %}
-...
-```
-
-Once the contributor updates the Git repository via normal Git processes and it is reviewed and merged into the branch that was used, a sync process from Nautobot needs to be completed.  This can be done from the default Git view, or within a specific detailed view of a Git repository.
-
-From the default Git repositories view:
-![Sync Repository from Default Menu](./images/git-as-data-source/08-git-data-source.png)
-
-From the detailed view:
-![Sync Repository from Detailed Menu](./images/git-as-data-source/09-git-data-source.png)
-
-!!! tip
-    Once the repository has been synced it's easy to check the history for the templates.
-    Navigate to **Git Repositories** and select the repository in question.  Once you're in the detailed view you can look through the **Synchronization Status** or **Change Log** tabs.
-
-Now that the Git repository is linked for export templates it can be controlled via the normal Git operations workflow, which allows users or groups of users to perform code reviews using Pull Requests etc.
-
-### Jobs
-
-Jobs are a way for users to execute custom logic on demand from within the Nautobot UI. Jobs can interact directly with Nautobot data to accomplish various data creation, modification, and validation tasks.
-
-For technical details on jobs, please see the [documentation on jobs](../platform-functionality/jobs/index.md#jobs).
-
-Jobs allow a user to write scripts in Python.  By integrating the scripts with Git, a user can utilize Git workflows to manage source control, versioning, and pipelines.
-
-Setting up the repository can be done following the same steps from [Export Templates](#export-templates).  The only differences is the `provides` selection changes to `jobs`.
-
-Jobs need to be defined in `/jobs/` directory at the root of a Git repository.
-
-An example tree for `/jobs/`.
-
-```no-highlight
-▶ tree jobs
-jobs
-├── __init__.py
-└── get-device-connection.py
-
-1 directory, 2 files
-```
-
-!!! note
-    As shown in the above example, the `/jobs/` directory must contain a file called `__init__.py`. This may be an empty file, but it must exist.
-
-Once the repository is created in Nautobot.
-![Example Details Jobs](./images/git-as-data-source/10-git-data-source.png)
-
-!!! tip
-    The same repository and branch can be used for the different `provides` methods.  Nautobot Git as a data source will look for specific root directory names.
-
-Once the scripts have been pushed into the repository, a sync needs to be executed, after which navigating to Jobs via **Jobs -> Jobs** will show the new jobs loaded from the Git repository.
-
-![Default Repository Menu](./images/git-as-data-source/11-git-data-source.png)
-
-Jobs now shows the job from the Git repository.
-
-![List of Loaded Jobs](./images/git-as-data-source/12-git-data-source.png)
-
-At this point all changes, and history can be kept using Git.  A simple `sync` operation can be done from Nautobot to pulldown any changes.
-
-### Config Contexts
-
-Detailed information on [config contexts](../platform-functionality/gitrepository.md#configuration-contexts) in Git Repositories.
-
-Config contexts may be provided as JSON or YAML files located in the `/config_contexts/` folder, which must be in the root of the Git repository.
-
-Config contexts can be used to provide additional details to different automation tooling.  For example Ansible variables, or any other data that you can't natively store in Nautobot.  It can also be used in the Golden Configuration Nautobot plugin to provide extra details to generate configuration templates.
-
-A few simple examples of Configuration Context data might be:
-
-- DNS Servers
-- NTP Servers
-- ACL Data
-- Routing Information such as BGP ASNs etc.
-
-Similar to the other data sources, the repository can be added by navigating to **Extensibility -> Git repositories**. Click on **Add**, and fill out the repository details.
-
-![Example Details Config Contexts](./images/git-as-data-source/13-git-data-source.png)
-
-Once the repository syncs the details can be found in the **Synchronization Status** tab.  For example, the platform specifics were synced:
-
-![Synchronization Menu With Loaded Contexts](./images/git-as-data-source/14-git-data-source.png)
-
-The repository structure is:
-
-```no-highlight
-▶ tree config_contexts
-config_contexts
-├── devices
-│   ├── location-a-bb-01.yml
-│   ├── location-a-rtr-01.yml
-│   ├── location-a-rtr-02.yml
-│   ├── location-a-spine-01.yml
-│   ├── location-a-spine-02.yml
-│   ├── location-b-bb-01.yml
-│   ├── location-b-leaf-01.yml
-│   ├── location-b-leaf-02.yml
-│   ├── location-b-rtr-01.yml
-│   ├── location-b-rtr-02.yml
-│   ├── location-b-spine-01.yml
-│   └── location-b-spine-02.yml
-├── platform_eos.yml
-├── platform_junos.yml
-├── platform_nxos.yml
-└── role_spine.yml
-
-1 directory, 16 files
-```
-
-Configuration Context details:
-
-- Follows an inheritance methodology similar to what Ansible implements.  Global contexts can be overwritten by local contexts at both a group level, as well as at a device specific level.
-- Nautobot UI provides a simple view to see merged config contexts.  It can be visualized by navigating to a device and clicking on the **config contexts** tab.
-
-Here's an example, with some of the details omitted for brevity.
-
-![Config Contexts Display Pane](./images/git-as-data-source/15-git-data-source.png)
-
-There is a huge benefit to having `config contexts` managed by a Git workflow.  This type of data can be modified often, especially platform specifics, or new device roles.  Utilizing a standard Git workflow allows for all the proper reviews and approvals to be accomplished before accepting the changes into Nautobot for use.
-
-### Config Context Schemas
-
-Detailed information on [config context schemas](../platform-functionality/gitrepository.md#configuration-context-schemas) in Git Repositories.
-
-Config context schemas are used to enforce data validation on config contexts. These schema are managed via the [config context schema model](../core-data-model/extras/configcontextschema.md) and are optionally linked to config context instances, in addition to devices and virtual machines for the purpose of validating their local context data.
-
-```no-highlight
-▶ tree config_contexts
-config_context_schemas
-├── schema_1.yaml
-├── schema_2.json
-```
-
-## Additional Git Data Sources
-
-As seen in [Fill out Repository Details](#fill-out-repository-details), the standard installation of Nautobot will come natively with export templates, jobs, and config contexts.  Additional data sources can be incorporated using the Nautobot plugin system.  For example, the [nautobot-plugin-golden-config](https://github.com/nautobot/nautobot-plugin-golden-config) plugin implements four additional data sources.
-
-- Config Contexts
-- Backup Configs
-- Intended Configs
-- Jinja Templates
-
-For more information for the Golden Configuration specific data sources, navigate to [Nautobot Golden Config Repo](https://github.com/nautobot/nautobot-plugin-golden-config/blob/develop/docs/navigating-golden.md#git-settings).
-
-## Common Issues and Troubleshooting
-
-1. Repository is linked, but data is not properly loaded into Nautobot.
-    - Validate the root directory is set to the proper name.
-    - Export Templates -> `export_templates`.
-    - Jobs -> `jobs`.
-    - Config Contexts -> `config_contexts`.
-2. Synchronization Status Failures.
-    - Validate branch is correct and exists in the remote repository.
-    ![Error Branch Doesn't Exist](./images/git-as-data-source/16-git-data-source.png)
-    - Validate the remote url is correct and is the `http(s)` url.  `ssh` urls are not currently supported.
-    ![Error Remote URL Incorrect](./images/git-as-data-source/17-git-data-source.png)
-3. Authentication Issues.
-    - Check repository permissions.
-    - Ensure the password is the Personal Access Token (PAT) for the username supplied.
-    - Ensure the PAT permissions are setup properly.
-      - At a minimum the `repo` option should be checked or access.
-
-    ![Error Authentication Issue](./images/git-as-data-source/18-git-data-source.png)

nautobot/docs/user-guide/feature-guides/graphql.md

@@ -1,342 +0,0 @@
-# GraphQL User Guide
-
-## Introduction
-
-### What is GraphQL?
-
-[GraphQL](https://graphql.org/) is a query language for your APIs and a runtime for fulfilling those queries with your existing data.
-
-### How GraphQL simplifies API Interactions
-
-When interacting with APIs, It's often necessary to build relationships between multiple models to achieve the result that is desired. Doing this typically requires multiple API calls to create the relationships. For example, lets assume that there are two devices in Nautobot. Each are assigned a location, region, roles, interfaces, and IP Addresses.
-
-Simply querying the `/api/dcim/devices/` API route provides:
-
-??? info "View API Results"
-
-    ```json
-    {
-      "count": 2,
-      "next": "https://demo.nautobot.com/api/dcim/devices/?limit=1&offset=2",
-      "previous": "https://demo.nautobot.com/api/dcim/devices/?limit=1",
-      "results": [
-        {
-          "id": "c8886c88-6eff-4c4f-a079-4ef16b53d4f6",
-          "url": "https://demo.nautobot.com/api/dcim/devices/c8886c88-6eff-4c4f-a079-4ef16b53d4f6/",
-          "name": "ams-edge-02",
-          "display": "ams-edge-02",
-          "device_type": {
-            "id": "244ea351-3c7a-4d23-ba80-5db6b65312cc",
-            "url": "https://demo.nautobot.com/api/dcim/device-types/244ea351-3c7a-4d23-ba80-5db6b65312cc/",
-            "manufacturer": {
-              "id": "687f53d9-2c51-40fd-83aa-875e43d01a05",
-              "url": "https://demo.nautobot.com/api/dcim/manufacturers/687f53d9-2c51-40fd-83aa-875e43d01a05/",
-              "name": "Arista",
-            },
-            "model": "DCS-7280CR2-60",
-            "display": "Arista DCS-7280CR2-60"
-          },
-          "role": {
-            "id": "a3637471-6b4d-4f5a-a249-838d621abe60",
-            "url": "https://demo.nautobot.com/api/dcim/device-roles/a3637471-6b4d-4f5a-a249-838d621abe60/",
-            "name": "edge",
-          },
-          "tenant": null,
-          "platform": null,
-          "serial": "",
-          "asset_tag": null,
-          "location": {
-            "id": "4ad439e9-4f1b-41c9-bc8c-dd7c1c921dc3",
-            "url": "https://demo.nautobot.com/api/dcim/locations/4ad439e9-4f1b-41c9-bc8c-dd7c1c921dc3/",
-            "name": "ams",
-          },
-          "rack": {
-            "id": "bff3f7af-bd77-49b6-a57a-9c4b8fc7673a",
-            "url": "https://demo.nautobot.com/api/dcim/racks/bff3f7af-bd77-49b6-a57a-9c4b8fc7673a/",
-            "name": "ams-102",
-            "display": "ams-102"
-          },
-          "position": 40,
-          "face": {
-            "value": "front",
-            "label": "Front"
-          },
-          "parent_device": null,
-          "status": {
-            "value": "active",
-            "label": "Active"
-          },
-          "primary_ip": null,
-          "primary_ip4": null,
-          "primary_ip6": null,
-          "cluster": null,
-          "virtual_chassis": null,
-          "vc_position": null,
-          "vc_priority": null,
-          "comments": "",
-          "local_config_context_data": null,
-          "tags": [],
-          "custom_fields": {},
-          "config_context": {},
-          "created": "2021-02-25T00:00:00Z",
-          "last_updated": "2021-02-25T14:51:57.609598"
-        }
-      ]
-    }
-    ```
-
-<!-- markdownlint-disable-next-line MD033 -->
-<br />
-There is a lot of useful information in that API call, but there is also a lot of information that is missing; such as interfaces and ip addresses associated with the devices. There is also potentially a lot of information that isn't needed for the specific task. To retrieve the missing information, subsequent API calls would need to be performed; and those API results would need to be correlated to the correct device.
-
-GraphQL reduces the complexity of performing multiple API calls and correlating results by empowering the user to create their own query that provides the user exactly what they want and nothing that they don't, in a single API call.
-
-### Exploring GraphQL in Nautobot
-
-In Nautobot, there is a link to the GraphQL web interface at the bottom right-hand side of the page. The GraphQL web interface is called GraphiQL. Navigating to the URI (`/graphql`), brings up the GraphiQL tool for creating queries. This interface is useful for exploring the possibilities of GraphQL and validating that written queries execute successfully.
-
-![GraphiQL Interface](./images/graphql/00-graphiql.png)
-
-### Documentation Explorer
-
-If you're new to GraphQL, take a little bit of time to explore the *Documentation Explorer*. This can be accomplished by clicking the `< Docs` link in the GraphiQL interface. The information within *Documentation Explorer* is specific to creating queries in Nautobot.
-
-![Documentation Explorer](./images/graphql/01-graphiql-explorer.png)
-
-In the *Documentation Explorer*, search for `devices`. The results are all of the models that utilize the `devices` model.
-
-![Documentation Explorer: Devices](./images/graphql/02-graphiql-explorer-device-query.png)
-
-From the `devices` query, select `devices` from `Query.devices`. This will display all of the potential query fields from devices.
-
-![Documentation Explorer: Device Attributes](./images/graphql/03-graphiql-explorer-device-attributes.png)
-
-### First Query
-
-Now that you have a basic understanding of how to obtain information to query from the *Documentation Explorer*, let's craft a query. Earlier in the guide, a sample REST API call was performed to obtain device information. While the query had a lot of important information, it also lacked a lot of information. In this section, lets explore how to craft a GraphQL query that displays all of the information that we want.
-
-GraphQL queries are encapsulated in `query { }` flags (simply `{ }` is also acceptable). With that in mind, let's craft our query from the GraphiQL interface to inspect all devices and display their device names. To do this, let's execute:
-
-```graphql
-query {
-  devices {
-    name
-  }
-}
-```
-
-This query will retrieve a list of all devices by their hostname.
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/04-graphql-query-01.png">
-
-<!-- markdownlint-disable-next-line MD033 -->
-<br />
-Now, let's modify the query to provide interface names for each device. We can do that by modifying the existing query to add `interfaces { name }` as a sub-query of `devices`. GraphiQL makes this process a bit easier, because it has syntax completion built in.
-
-![GraphQL: Autocompletion](./images/graphql/05-graphiql-autocomplete.png)
-
-```graphql
-query {
-  devices {
-    name
-    interfaces {
-      name
-    }
-  }
-}
-```
-
-The result is a list of all the devices by their hostname and associated interfaces by their names.
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/06-graphql-query-02.png">
-
-<!-- markdownlint-disable-next-line MD033 -->
-<br />
-We can continue iterating on the query until we get exactly what we want from the query. For example, if I wanted to iterate on the previous query to not only display the interfaces of the devices, but also display the interface description, the IP Addresses associated with the interface, and whether or not the interface was a dedicated management interface; I would structure the query like:
-
-```graphql
-query {
-  devices {
-    name
-    interfaces {
-      name
-      description
-      mgmt_only
-      ip_addresses {
-        address
-      }   
-    }
-  }
-}
-```
-
-The results of the query look like:
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/07-graphql-query-03.png">
-
-### Filtering Queries
-
-These queries are great, but they are displaying the interface attributes and device names for every device in the Nautobot inventory. Nautobot allows users to filter queries at any level as desired to narrow the scope of the returned data. As an example, we can filter the queried devices by their location. This is done by adding `(location: "<location name>")` after `devices`. For example: `query { devices(location: "ams") { name }}` will display all devices in the `ams` location.
-
-As an example. We can query devices by their location. This is done by adding `(location: "<location name>")` after `devices`. For example: `query { devices(location: "ams") { name }}` will display all devices in the `ams` location.
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/08-graphql-query-04.png">
-
-<!-- markdownlint-disable-next-line MD033 -->
-<br />
-GraphQL also allows you to filter by multiple attributes at once if desired. You can use the *Documentation Explorer* to assist you in finding criteria attributes to filter on. In this example, I add the `role` attribute in addition to `location`.
-
-```graphql
-query {
-  devices(location: "ams", role: "edge") {
-    name
-  }
-}
-```
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/09-graphql-query-05.png">
-
-<!-- markdownlint-disable-next-line MD033 -->
-<br />
-You can also filter at deeper levels of the query. On many to one relationships you can filter the results based on an attribute of the field. Any attribute that relates to a GraphQLType can be filtered.
-
-```graphql
-query {
-  devices(location: "ams", role: "edge") {
-    name
-    interfaces(name: "Ethernet1/1") {
-      name
-    }
-  }
-}
-```
-
-```graphql
-query {
-  locations(name: "ams") {
-    devices(role: "edge") {
-      name
-      interfaces(name: "Ethernet1/1") {
-        name
-      }
-    }
-  }
-}
-```
-
-??? info "View GraphQL Query Results"
-    <!-- markdownlint-disable-next-line MD033 -->
-    <img src="../images/graphql/11-graphql-query-06.png">
-
-+++ 1.3.0
-    You can also paginate the results returned to you when the data set gets larger. To do so, use the keywords "limit" and "offset". The "limit" keyword will limit the count of results returned after the "offset". If no "offset" is specified, then the default offset is zero.
-
-    ```graphql
-    query {
-      devices(location: "ams01", , limit: 1, offset: 1) {
-        name
-      }
-    }
-    ```
-
-## Using the GraphQL API in Nautobot
-
-Now that we've explored how to use the GraphiQL interface to help us create GraphQL queries, let's take our queries and call them with the REST API. This is where the real advantage is going to come in to play, because it will allow us to utilize these queries in a programmatic way.
-
-![GraphQL: Swagger](./images/graphql/10-graphql-swagger.png)
-
-From the [Nautobot Swagger documentation](https://demo.nautobot.com/api/docs/), we can see that the API calls to `/api/graphql` require a HTTP POST method. In the HTTP POST, the `query` field is required, as it is where we specify the GraphQL query. The `variables` field is optional; it's where we can assign values to any variables included in the query, if we choose to do so.
-
-To simplify the process even more, we'll utilize the [PyNautobot SDK](https://pynautobot.readthedocs.io/en/latest/index.html).
-
-Here is an example Python script using the PyNautobot SDK to query GraphQL:
-
-```python
-#!/usr/bin/env python3
-
-import pynautobot
-import json
-
-query = """
-query {
-  devices {
-    name
-    interfaces {
-      name
-      description
-      mgmt_only
-      ip_addresses {
-        address
-      }
-    }
-  }
-}
-"""
-nb = pynautobot.api(
-    url="http://localhost",
-    token="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
-)
-gql = nb.graphql.query(query=query)
-
-print(json.dumps(gql.json, indent=2))
-```
-
-The contents of the `query` variable was taken directly from the example above where we grabbed all device interfaces and associated attributes. We then take the output and print the contents as a JSON object. Now, let's iterate on the script to filter the contents with the `variable` flag. Just as we did above, we'll filter by `location`.
-
-```python
-#!/usr/bin/env python3
-
-import pynautobot
-import json
-
-variables = {"location_name": "ams"}
-query = """
-query ($location_name: String!) {
-  devices (location: $location_name) {
-    name
-    interfaces {
-      name
-      mgmt_only
-      ip_addresses {
-        address
-      }
-    }
-  }
-}
-"""
-nb = pynautobot.api(
-    url="http://localhost",
-    token="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
-)
-gql = nb.graphql.query(query=query, variables=variables)
-
-print(json.dumps(gql.json, indent=2))
-```
-
-In the updated script, we add the `variables = {"location_name": "ams"}` variable. We then update the query to let GraphQL know that we will be sending parameters to to filter by `location`. The updated output is still a JSON object. Instead of fetching all devices, we are filtering by devices in the `ams` location. The PyNautobot SDK has some [excellent GraphQL examples](https://pynautobot.readthedocs.io/en/latest/api/core/graphql.html). Be sure to check out the documentation.
-
-### Saving Queries
-
-+++ 1.1.0
-
-Queries can now be stored inside of Nautobot, allowing the user to easily rerun previously defined queries.
-
-Inside of **Extensibility -> Data Management -> GraphQL Queries**, there are views to create and manage GraphQL queries.
-
-Saved queries can be executed from the detailed query view or via a REST API request. The queries can also be populated from the detailed query view into GraphiQL by using the "Open in GraphiQL" button. Additionally, in the GraphiQL UI, there is now a menu item, "Queries", which can be used to populate GraphiQL with any previously saved query.
-
-To execute a stored query via the REST API, a POST request can be sent to `/api/extras/graphql-queries/[uuid]/run/`. Any GraphQL variables required by the query can be passed in as JSON data within the request body.
-
-## Closing
-
-GraphQL is a powerful, yet simple, tool for querying the exact information that is necessary for the task at hand. For further information about GraphQL, be sure to check out the [GraphQL Docs](https://graphql.org/learn/)!