Environment

• Python version: 3.9
• Nautobot version: v1.0.0b1

Proposed Functionality

The global search functionality returns Inventory Items within the scope of it's search

Use Case

I track device line-cards as inventory items. In a lab environment, sometimes users want to move line-cards from one device to another and to find existing line cards, users might search for them in Nautobot. Currently, to search for these items, users need to use the dedicated inventory items view. The non-inclusion of inventory items within the scope of the global search tool is confusing to users.

This FR was previously raised against the forerunner project but rejected by the developer on efficiency grounds. Re-raising here in the hope that it may gain some traction in the new project. A subsequent FR was raised which would provide the functionality via a different approach, but at the present time this remains unaccepted - I'll raise a similar FR here and link to this as, while the two are related, they actually serve different purposes.

Note: I have code which, with some refactoring, could be ported to Nautobot relatively trivially and would be happy to submit this as a PR should this FR be accepted and assigned to me.

Database Changes

None.

External Dependencies

None.

Change Type

[ ] Addition
[ x] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[x ] Installation instructions
[ ] Configuration parameters
[ ] Functionality/features
[ ] REST API
[ ] Administration/development
[ ] Other

Proposed Changes

In sections "Configuring Napalm" and "Remote File Storage", the docs recommend using the following commands:

sudo echo napalm >> /opt/nautobot/local_requirements.txt
sudo echo django-storages >> /opt/nautobot/local_requirements.txt

These commands do not work as sudo does not apply to the redirect. Using these commands will result in permission denied:

vagrant@ubuntu:/opt/nautobot$ sudo echo napalm >> /opt/nautobot/local_requirements.txt
-bash: /opt/nautobot/local_requirements.txt: Permission denied

Potential fix:

sudo sh -c "echo 'napalm' >> /opt/nautobot/local_requirements.txt"
sudo sh -c "echo 'django-storages' >> /opt/nautobot/local_requirements.txt"

Environment

• Python version:
• Nautobot version: 1.0.0b1

Steps to Reproduce

1. Go to create a new relationship
2. Scroll to destination label field
3. Profit!

Expected Behavior

Label should be "Name of the relationship as displayed on the destination object."

Observed Behavior

Label is actually "Name of the relationship as displayed on the source object."

Proposed Functionality

Although it’s already technically possible for plugins to use Nautobot’s generic views (nautobot.views.generic.) and templates (templates/generic/.html and templates/inc/*.html), this hasn’t been officially “blessed” by the development team and it has not been guaranteed in the past that these will be considered part of the plugin API (affecting SemVer, etc. when updated). This proposal is to officially “bless” these as part of the API available to plugins and agree to avoid breaking changes to these views/templates unless undergoing a “major” version change.

Use Case

As a plugin developer, using existing views and templates both reduces development time required and ensures that the plugin’s added UI elements are consistent with Nautobot’s visual style.

Database Changes

None.

External Dependencies

None.

Environment

• Python version: 3.9
• Nautobot version: v1.0.0b

Proposed Functionality

Relating to #38, users should be able to choose what models to include in the scope of their searches. A users' preference for the models to be searched should be saved for future searches.

My proposal is to replace the type selection widget in the search page with a styled multiple selection widget that, to conserve space on the home page, is only displayed when the user clicks an 'advanced search' button. The additional selection widget does not fit well within the navigation bar search, so this would be refactored to search only the previously selected set of models - a 'quick search' if you like.

Use Case

Some may choose not to use all models within the Nautobot tool which are included in the global search scope, but make more use of models which are not included. There is little point using processor cycles searching empty tables, when populated tables containing useful data cannot be searched using the global search functionality. Users should be free to choose a list of multiple models to be searched depending on their preferences and organisational use of the tool.

Note: An unaccepted FR exists for this in the forerunner project. I have proof of concept code for this functionality developed already which could trivially be refactored and ported to Nautobot. I'd be happy to submit a PR for Nautobot if this feature is accepted and assigned to me.

Database Changes

None

External Dependencies

None

Proposed Functionality

Define contact information at a broader and more granular level than is possible today supporting the ability to define contact information for individual regions, devices, circuits, circuit providers, etc.

Use Case

As a network organization, my team has different contacts and domain owners for different resources stored in Nautobot. I’d like to be able to define who is the proper contact owner for tenants, sites, regions, devices, circuits, and circuit providers.

Database Changes

Yes - create new generic model for contact information, migrate existing circuit/site/etc. contact info to new model, remove fields from existing circuit/site/etc. models, add relation to all models that should support contact information.

External Dependencies

None.

Change Type

[x] Addition
[ ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[ ] Installation instructions
[x] Configuration parameters
[x] Functionality/features
[x] REST API
[x] Administration/development
[ ] Other

Proposed Changes

The new custom relationships feature is not yet tested or documented. This should track the work for documentation.

The way I see it, this is an advanced feature and the documentation for it needs to be verbose, and would be better with screenshots and examples. For example, the source/destination filters are easy to get wrong, and after defining them, how should they be tested to make sure they work as intended? I think the Device to VLANs example we've been using to describe this would be perfect use-case for how to implement and expand the documentation.

Documentation should include

• User guide
• Developer guide

Environment

• Python version: 3.7
• Nautobot version: 1.0.b

Proposed Functionality

The removal of user/password fields from in a way that will not auto-fill for users of standard browser password management systems.

Use Case

As a user of the git data source, it is highly likely that I would not realize my password manager filled out the user/passwords when filling out the data source and accidentally populate with my own credentials unintentionally.

Database Changes

N/A

External Dependencies

N/A

Change Type

Correction

Area

Multiple

Proposed Changes

See also #64 .

All of the below should be changed either to relative links or link to latest instead of stable:

% git grep -i 'nautobot.readthedocs.*stable'
CHANGELOG.md:The changelog has been moved to the [project release notes](https://nautobot.readthedocs.io/en/stable/release-notes/).
CONTRIBUTING.md:Contributing Guidelines are located in the [docs](https://nautobot.readthedocs.io/en/stable/development/#contributing).
contrib/nautobot-rq.service:Documentation=https://nautobot.readthedocs.io/en/stable/
contrib/nautobot.service:Documentation=https://nautobot.readthedocs.io/en/stable/
nautobot/core/templates/home.html:            <a href="https://nautobot.readthedocs.io/en/stable/installation/upgrading/">Upgrade instructions</a>
nautobot/core/templates/media_failure.html:                Refer to <a href="https://nautobot.readthedocs.io/en/stable/installation/">the installation
nautobot/docs/installation/4-gunicorn.md:       Docs: https://nautobot.readthedocs.io/en/stable/

Proposed Functionality

Provide code-based signals or callbacks that are invoked when a plugin is first installed or after a plugin has been removed. These can be used for one-time setup at installation time (see for example the “Register “extras” features such as CFs, webhooks, export templates, links, relationships from plugins” use case), for one-time cleanup when a plugin is no longer needed (e.g., removing plugin-data tables from the database), and potentially as a way to provide for deeper introspection of the capabilities and offerings of each installed plugin.

Use Case

• As a plugin developer, I want to ensure that my plugin fully cleans up after itself when uninstalled.
• As a Nautobot administrator, I want to be able to safely install and uninstall various plugins without concern that they will leave Nautobot itself in an invalid or inconsistent state.

Database Changes

TODO

External Dependencies

TODO

Ideas for Enhancements

• Documentation improvements for cleaning up plugins
• Evaluate if plugins can provide uninstall code
• Evaluate management commands to "clean up" prior plugins schemas

Proposed Functionality

Although it’s technically possible for plugins to use Nautobot’s ChangeLoggedModel base class to provide automatic change-logging for the plugin’s custom model classes, this hasn’t been officially “blessed” by the development team and it has not been guaranteed in the past that this class is considered part of the plugin API (affecting SemVer etc when updated). This proposal is to officially “bless” this class as part of the plugin API and agree to avoid breaking changes to this class outside of a “major” version change.

Use Case

As a plugin developer, I want to provide the same change logging and historical view of my plugin data models as is provided for base Nautobot models.

Database Changes

None

External Dependencies

None

Proposed Functionality

Support a model to define OSs that should be used by each device and ensure there is also a relationship between vendor and platform.

Use Case

As a user, I should be able to define the intended OS or list of supported OSs per device. I should preferably be able to run search queries within the UI using greater than and less than (<>) operators to verify if my devices.

Database Changes

Yes, will require a new database model(s), as well as updates to Vendor and Platform models

External Dependencies

Maybe - need to explore external library(ies) for parsing idiosyncratic vendor OS version strings.

Environment

• Python version: N/A
• Nautobot version: N/A

Proposed Functionality

Officially maintained bindings (Generated from swagger) for golang / others
There is an existing community maintained version for Netbox here https://github.com/netbox-community/go-netbox
However due to various swagger definition problems in Netbox the generated client generally needed modification in areas.
Issues: 4808, 4804, 4803 among others

Most of the existing issues can be resolved by fixing up the swagger definitions and by adding tests.

Use Case

Enhanced usability in external applications for automation tooling.

Database Changes

N/A

External Dependencies

N/A

Environment

• Python version: from docker-compose
• Nautobot version: 52847736a40e (v1.0.0b1)

Steps to Reproduce

1. connect cable between interface and front port
2. connect circuit between two rear ports
3. connect another cable between remote front port and interface

Expected Behavior

I expecteded the connection trace to go over a circuit, which is described in the documentation https://nautobot.readthedocs.io/en/latest/core-functionality/devices/#cables

I expected the circuit to appear in cable overview as one single cable, however it appears as two cables.
See screenshot of what happened, and my paint-job as to what I wanted to achive.

Observed Behavior

When tracing the connection (cable id 411e2ca8-0e95-47a4-95ad-5ba3abb8a2e0), it stops at the circuit. Also the circuit appears as two cables in the cable overview.

Proposed Changes

Throughout the documentation there are many places to pip3 install foo such as napalm, django-storages, etc...

I would like to implement these as extras instead, for example to install nautobot w/ napalm:

pip3 install nautobot[napalm]

or for SSO dependencies (just examples):

pip install nautobot[sso]
pip install nautobot[sso,oidc]
pip install nautobot[sso,saml] 
pip install nautobot[ldap]

or to install Nautobot with ALL optional dependencies

pip3 install nautobot[all]

Justification

This simplifies the installation and reduces the need for additional pip3 install commands for common cases and also allows us to certify vetted versions of those optional dependent libraries.

Preface/disclaimer: I don't know enough to have any smart words about the actual legal bits of licensing/forking and I want to make it clear I am not trying to say that things were done in bad faith or against a license or anything like that -- this is just a friendly comment/inquiry!

Would you consider retaining the Netbox commit history? Fork away, by all means, but it :feelsbadman: that 147 peoples work that made Netbox what it is, and made it into something ya'll wanted to fork and build off of has been completely erased from this project. Removing that history, while maybe totally legit per licensing things (I have no idea, and again, not speculating if its right or wrong), is a pretty bad look.

Feel free to close, but thought it was worth raising.

Environment

• Python version:3.8.5
• Nautobot version: 1.0.0b1

Steps to Reproduce

1. Follow the installation docs for http server: https://nautobot.readthedocs.io/en/latest/installation/5-http-server/
2. When you get to the step of Confirm Connectivity, it will fail. A static error for CSS errors will come up when you try to browse to the server page.

Expected Behavior

1. Expect to see the home page of nautobot.

Observed Behavior

1. You get a Static error CSS not found page.

Root Cause

1. The root cause for this error is because the static page linked in the /opt/nautobot/contrib/apache.conf (or nginx.conf) links to a non-existent directory.

When you git clone the repo, you get a /opt/nautobot/nautobot/project-static directory, and the .conf files references to /opt/nautobot/static instead. I'd open a PR for this, but i'm not sure whether this is a documentation error, or a contrib config file error, so not sure which file to put the PR for. Either way, should be a super easy fix.

Proposed Changes

Add documentation to help users get started using Nautobot. This should articulate the steps in which users need to create tenants, regions, sites, platforms, device types, devices, interfaces, VLANs, IPs, to construct a basic inventory. The goal is to help users understand order of operations when starting with an empty database.

This may be able to be added a user guide.

Change Type

[ ] Addition
[X ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[X] Installation instructions
[ ] Configuration parameters
[ ] Functionality/features
[ ] REST API
[ ] Administration/development
[ ] Other

Proposed Changes

nautobot/core/templates/nautobot_config.py.j2

• Fix typo Postres -> Postgres
• Fix comment for EXTRA_INSTALLED_APPS. "http://nautobot.readthedocs.io/configuration/optional-settings/#extra-applications" does not load various css/js files.

Proposed Functionality

There should be the ability to customize the navigation bar by removing top-level items.

Use Case

As a user if I’m not using a core model like Virtualization or Secrets, I should be able to easily remove that from the navigation bar (and home page). I should also be able to change the location of a top-level item in the nav bar.

Need to determine if this should be a per-user configuration option (similar to how users customize the table view columns today) or an admin configuration option (show/hide/reorganize for all users) or some combination thereof.

Database Changes

TODO

External Dependencies

None.

Proposed Changes

Add a user guide for using the Custom Validators feature.

Justification

There is not currently a user guide and we want to have guides for all of the advanced features including examples and common usage patterns. Currently, this is buried under "Developing Plugins" > "Implementing Custom Validators. While it does give a code example, this feature especially could benefit from examples of how this code is used in practice, common issues, how to test that it is working, etc.

Proposed Functionality

Provide an option to do a “dry run” of a Git repository sync/refresh and report what data (config contexts, export templates, etc.) would be changed as a result, without actually applying the change.

Use Case

Sanity checks, especially when adding a new Git repository for the first time.

Database Changes

None.

External Dependencies

None.

Proposed Changes

Expand the "Getting Started" section of the developer docs to better describe and install Invoke, and common operations used in working inside the Docker environment.

Justification

Invoke is a new concept and we just kind of skim it. Examples on how each of the commands are used is also going to be very helpful.

Proposed Functionality

Trigger webhooks for models that are created and used within plugins (non-core models).

Use Case

As a developer, if I create a model to store network ACLs or VXLAN, I need the ability to trigger webhooks on CRUD operations of those models.

Database Changes

None.

External Dependencies

None.

Change Type

[ ] Addition
[X ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[ X] Installation instructions
[ ] Configuration parameters
[ X] Functionality/features
[ ] REST API
[ ] Administration/development
[ ] Other

Proposed Changes

On the readthedocs page, there's a reference to Golden Configuration plugin:

• https://nautobot.readthedocs.io/en/latest/#key-use-cases

.. which links to a missing project on github:

• https://github.com/nautobot/nautobot-plugin-golden-configuration

Should this exist? Is it locked down? Is this plug-in commercial?

Environment

• Python version: Python 3.8.5
• Nautobot version: v1.0.0b1

Steps to Reproduce

1. Go to Devices and click on a existing Device
2. Click Edit Button
3. Scroll Down to "Location" and Open "Position"

Expected Behavior

When opening the List it should display the Units of the assigned Rack.

Observed Behavior

It just shows: "The results could not be loaded"

It is only possible to assigne a Device to a Rack position while creating it. After the Device was created it's not possible to edit the position anymore. I've cross checked it with https://demo.nautobot.com/ - same Behavior.

Environment

• Python version: 3.8.5
• Nautobot version: 1.0.0b1

Steps to Reproduce

1. Navigate to an existing device -> interfaces tab
2. Click "Edit" button for any interface or navigate to interface and click "Edit"

Expected Behavior

Buttons at bottom of edit form should be "Update" / "Update and Continue Editing"

Observed Behavior

Buttons at bottom of edit form are "Create" / "Create and Add Another"

Issue appears to be here:

congrats on the launch today!
great talks at NFD24.
really looking forward to kicking the tires on it.

Proposed Changes

The new custom relationships feature set is not tested. We need to implement unit tests for this feature.

Environment

• Python version: 3.8.5
• Nautobot version: 1.0.0b1
• VSCode version: 1.53.2
• Windows 10
• WSL2 / Ubuntu-20.04
• Docker version: 20.10.3, build 48d30b5

Steps to Reproduce

1. Clone develop branch of repo to WSL2 VM
2. Open directory in VSCode from within WSL2 - code .
3. Select "Reopen in Container" from the popup for the dev container

Expected Behavior

Workspace should be opened in Docker container for development

Observed Behavior

VSCode shows error "Cannot reconnected. Please reload the window." and shows "Disconnected from Dev Container".

development_nautobot_1 container shows "Exited" status, but all other containers are running.

11:38 $ docker ps -a
CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS                      PORTS      NAMES
8a2908da6f59   nautobot/nautobot-py   "nautobot-server rqw…"   54 seconds ago   Up 53 seconds                          development_worker_1
562271b77719   nautobot/nautobot-py   "/tmp/nautobot/docke…"   54 seconds ago   Exited (2) 48 seconds ago              development_nautobot_1
96597bc37bc2   postgres:10            "docker-entrypoint.s…"   55 seconds ago   Up 54 seconds               5432/tcp   development_postgres_1
d67dd930db96   redis:5-alpine         "docker-entrypoint.s…"   55 seconds ago   Up 54 seconds               6379/tcp   development_redis_1

11:39 $ docker logs development_nautobot_1
Operations to perform:
  Apply all migrations: admin, auth, circuits, contenttypes, dcim, extras, ipam, sessions, taggit, tenancy, users, virtualization
Running migrations:
  No migrations to apply.
↩️ Skip creating the superuser
sleep: 1: sleep: Syntax error: end of file unexpected (expecting "do")

Possible Workaround / Fixes

This issue appears to be caused by this line:

Changing these lines to command: "sleep infinity" resolves the issue.

Alternatively, removing the reference to "../development/docker-compose.debug.yml" from devcontainer.json also fixes the issue, but doesn't provide the desired behavior for debugging:

Proposed Functionality

This proposal is to support a "no code" option to take advantage of and simplify the consumption of the Data Validation API. In the current form, plugins are required and therefore, Python code needs to be built and managed to implement Data Validation. The proposal is to develop this as a plugin that uses the Data Validation API.

Use Case

As a network engineer, I want a streamlined way in the UI to implement data validation for rules such as adhering to RegEx patterns and min/max values for any data being added Nautobot.

Database Changes

TBD

External Dependencies

None.

Proposed Functionality

Support MySQL as a backend. This is in addition to PostgreSQL.

Use Case

As a user, my company only uses MySQL. Nautobot needs to support MySQL for me to be able to deploy it.

Database Changes

TODO

External Dependencies

TODO

Environment

• Python version:
• Nautobot version: 1.0.0a2

Steps to Reproduce

1. Install nautobot using poetry install
2. Try to run poetry run nautobot-server runserver 0.0.0.0:8000

Expected Behavior

Dev server should start.

Observed Behavior

$ poetry run nautobot-server runserver 0.0.0.0:8000 --insecure
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/jathan/sandbox/src/nautobot/nautobot/core/cli.py", line 55, in main
    run_app(
  File "/Users/jathan/sandbox/src/nautobot/nautobot/core/runner/runner.py", line 268, in run_app
    management.execute_from_command_line([runner_name, command] + command_args)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
    utility.execute()
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/__init__.py", line 395, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/base.py", line 330, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 61, in execute
    super().execute(*args, **options)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/base.py", line 371, in execute
    output = self.handle(*args, **options)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 96, in handle
    self.run(**options)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 103, in run
    autoreload.run_with_reloader(self.inner_run, **options)
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/utils/autoreload.py", line 620, in run_with_reloader
    exit_code = restart_with_reloader()
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/utils/autoreload.py", line 246, in restart_with_reloader
    args = get_child_arguments()
  File "/Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/lib/python3.9/site-packages/django/utils/autoreload.py", line 233, in get_child_arguments
    raise RuntimeError('Script %s does not exist.' % py_script)
RuntimeError: Script nautobot-server does not exist.

If I run poetry shell first to enter the virtualenv and then follow that with nautobot-server ... it works as expected.

$ poetry shell
Spawning shell within /Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9

$ . /Users/jathan/Library/Caches/pypoetry/virtualenvs/nautobot-b2ttWva6-py3.9/bin/activate

$ nautobot-server runserver 0.0.0.0:8000 --insecure
Performing system checks...

System check identified no issues (0 silenced).
February 24, 2021 - 18:59:51
Django version 3.1.7, using settings 'nautobot_config'
Starting development server at http://0.0.0.0:6789/
Quit the server with CONTROL-C.
nautobot     INFO     Nautobot initialized!

Change Type

[x] Addition
[ ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[ ] Installation instructions
[x] Configuration parameters
[ ] Functionality/features
[ ] REST API
[ ] Administration/development
[ ] Other

Proposed Changes

Create documentation around configuring SELinux to allow Nautobot to work properly.

Proposed Changes

As per docs/development/release-checklist.md:

• Update all Python dependencies to their latest patch versions
• Update static dependencies:
  • Bootstrap 3
  • Material Design Icons
  • Select2
  • jQuery
  • jQuery-UI
• Add/update release notes
• Update version number (poetry version major)

Justification

Following a consistent release process.

Proposed Changes

Add a user guide for using the Relationships feature.

Justification

There is not currently a user guide and we want to have guides for all of the advanced features including examples and common usage patterns. This feature especially could benefit from examples of source/destination filter expressions, common issues, how to test your relationships, etc.

Proposed Changes

Add a user guide for using the Jobs feature.

Justification

There is not currently a user guide and we want to have guides for all of the advanced features.

Change Type

• [ X] Correction

Area

• [ X] Administration/development

Proposed Changes

Fix link from https://nautobot.readthedocs.io/en/stable/development/getting-started/ to

/development/getting-started/

Proposed Functionality

Support ability to create, update, and delete GraphQL queries in the UI and API.

Use Case

As a user, I want a way to save and re-run common GraphQL queries from an API endpoint. I also want to be able to easily execute saved queries within GraphiQL.

Database Changes

Yes - will likely require a model for saving GraphQL queries to the DB - maybe just a JSONField?

External Dependencies

None.

Environment

GitHub

Steps to Reproduce

1. See issue for documentation update
2. See the check boxes showing up as [ ] only

Expected Behavior

Checkboxes render properly

Observed Behavior

Note above

Environment

• Python version: n/a
• Nautobot version: 1.0.0b1

Steps to Reproduce

1. Attempt to add an image attachment to a Device, an error is reported.
2. Various IPAM views do not correctly distinguish between allocated and non-allocated prefixes and addresses
3. Probably others

Expected Behavior

Functionality should work correctly.

Observed Behavior

Errors or incorrect behavior are observed.

I'm opening this as a single "global" issue as there are a number of distinct symptoms with the same underlying cause, that is, that when we were previously using integer PKs, a record that did not exist in the database had a zero PK (and so we could do things like if record.pk or if not object.pk to determine whether it was a DB record), but now that we're using UUID PKs, records always have a UUID PK. Alternate patterns exist in the code to replace this check and have it work correctly with the new PK format, but it appears we missed several of these in the initial changeset.

Proposed Functionality

It should be possible to add specific plugins, or groups of plugins, as a top-level item.

Use Case

As a developer, I want to make it easy for users to find a given functionality that is implemented within a plugin. If I’m developing a solution-centric plugin, I should be able to make that a top-level item on the navigation bar.

Database Changes

None.

Plugin API Changes

Will need to extend the current PluginMenuItem API to allow the user to specify a target menu grouping.

External Dependencies

None.

After some discussions around the timing behind whether we should replace the User model, we decided it would be a good idea.

This gives us the opportunity go move the user model to have a UUID as primary key, and to prepare for future use-cases not supported by the default Django user model.

Change Type

[x] Addition
[x] Correction
[x] Deprecation
[x] Cleanup (formatting, typos, etc.)

Area

[x] Installation instructions
[x] Configuration parameters
[x] Administration/development

Proposed Changes

The key changes that we made in Nautobot for how it can be installed, configured, developed, administered, and deployed need to be revised. The initial fork and release only did the minimum required to make sure Nautobot could be installed. As indicated above, the following key documentation areas need to be revised:

• Installation guide - spit into per-platform instructions, with a quick start guide for the common case)
• Configuration guide - centralize all optional settings including permissions and authentication, into a single configuration section
• Deployment guide - break install and production deployment into distinct sections. Getting Nautobot running is very different than running it in an enterprise-grade production environments
• Development guide - How to use "invoke", the basics of the Docker container that comes w/ Nautobot and how to use that

Currently REMOTE/SOCIAL_AUTH_* settings are spread across the Remote Auth, SSO docs, and smattered also in the Permissions and Optional Settings docs. Let's get them all into one place (IMO: a dedicated security/auth/permissions section in optional settings).

Environment

• Python version: Not known using https://demo.nautobot.com/
• Nautobot version: v1.0.0b1

Steps to Reproduce

1. Open Nautobot Demo on https://demo.nautobot.com/
2. Click GraphQL at the footer
3. Try to query for Devices where role = "Backbone" using the GraphQL query below:

{ 
  devices(role: "Backbone") {
    id,
    name
  }
}

Expected Behavior

Exected two see the two Backbone devices

{
  "data": {
    "devices": [
      {
        "id": "7b871f65-d4d5-4ab5-8fd5-211a8e093976",
        "name": "jcy-bb-01.infra.ntc.com"
      },
      {
        "id": "bfcd2323-5b32-4388-af61-05a7ed1404f7",
        "name": "nyc-bb-01.infra.ntc.com"
      }
    ]
  }
}

Observed Behavior

I am getting all the devices instead:

{
  "data": {
    "devices": [
      {
        "id": "60833d08-7bdd-4b40-a8c4-33c1984ccc90",
        "name": "ams-edge-01"
      },
      {
        "id": "c8886c88-6eff-4c4f-a079-4ef16b53d4f6",
        "name": "ams-edge-02"
      },
      {
        "id": "eee88e11-107f-4f19-b341-cbc6a61d7ab5",
        "name": "ams-leaf-01"
      },
      {
        "id": "fde5a607-4014-41c7-90bb-753dfc0f621c",
        "name": "ams-leaf-02"
      },
      {
        "id": "7815a8a8-ab8e-407a-a998-1f2ec961f06c",
        "name": "ams-leaf-03"
      },
      {
        "id": "8fa89044-c16f-497d-be85-03647a19433b",
        "name": "ams-leaf-04"
      },
      {
        "id": "6c71fd4f-15d8-4a6e-ae71-3fb82c809713",
        "name": "ams-leaf-05"
      },
      {
        "id": "a85ac1aa-094f-4de9-8ba6-16cb088a1b74",
        "name": "ams-leaf-06"
      },
      {
        "id": "7dc8d292-98fc-438e-b01e-962002ac5403",
        "name": "ams-leaf-07"
      }
     **** Omitted for brevity ****
    ]
  }
}

Further check

If I filter by role_id and use the id of the "Backbone" role it works:

Query:

{ 
  devices(role_id: "28f69768-f251-49ee-976e-41e190dfd672") {
    id,
    name
  }
}

The output is as expected:

{
  "data": {
    "devices": [
      {
        "id": "7b871f65-d4d5-4ab5-8fd5-211a8e093976",
        "name": "jcy-bb-01.infra.ntc.com"
      },
      {
        "id": "bfcd2323-5b32-4388-af61-05a7ed1404f7",
        "name": "nyc-bb-01.infra.ntc.com"
      }
    ]
  }
}

Environment

• Python version: 3.7.9
• Nautobot version: develop

Steps to Reproduce

1. Browse to https://nautobot.readthedocs.io/en/latest/
2. Select Installation - 3. Nautobot
3. Scroll down to the Remote File Storage section.
4. Click on desired storage backend

Expected Behavior

Links to STORAGE_BACKEND in the Optional Settings

Observed Behavior

404 error

Proposed Functionality

Read-only computed custom fields using existing data already stored in the database. This will allow users to be able to build lightweight Jinja (or Python) templates to populate a read-only custom field value.

Use Case

As a user, I want to dynamically generate interface descriptions using device, neighboring device, circuit, or circuit ID. All data already stored in Nautobot, I should be able to use Jinja templating, similar to custom links, to build that string thus simplifying the network configuration templates that are used to generate full configurations. As a user, I should be able to auto-generate fields that are required by automation systems like Ansible, e.g. ansible_network_os being "{{ vendor }}.{{ os }}.{{ os }}".

Database Changes

Will require some sort of database record to define and store these templates. Probably a new model as the existing custom-fields model is not directly applicable.

External Dependencies

None.