Network Source of Truth & Network Automation Platform
APACHE-2.0 License
Bot releases are visible (Hide)
Published by glennmatthews 9 months ago
/files/get/
URL endpoint (for viewing FileAttachment files in the browser), as it was unused and could potentially pose security issues.render_markdown()
utility function used to render comments, notes, job log entries, etc.comments
, description
, Notes, Job log entries, etc.) to also permit the use of a limited subset of "safe" HTML tags and attributes.nh3
HTML sanitization library as a dependency.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.9...v1.6.10
Published by gsnider2195 9 months ago
nautobot-server runjob
management command.nautobot_database_ready
signal handlers with a warning.ruff
development dependency to ~0.1.10
.black
and flake8
as development dependencies as they're fully replaced by ruff
now.black
and flake8
steps from CI.DJ
Ruff rules (flake8-django
) and addressed all warnings raised.PIE
Ruff rules except for PIE808
(flake8-pie
) and addressed all warnings raised.RUF
Ruff rules except for RUF012
and addressed all warnings raised.S
Ruff rules (flake8-bandit
) and addressed all warnings raised.DynamicGroupModelTest.test_member_caching_enabled
test case.I
Ruff rules (isort
) and addressed all warnings raised.isort
as a development dependency as it's fully replaced by ruff
now.Published by gsnider2195 9 months ago
Published by glennmatthews 10 months ago
Django Admin Log Entries record administrative changes made under the "Admin" section of the user interface. Changes (add/delete/update) to Objects like Users, Group, Object Permissions, etc. in the "Admin" user interface are now displayed as "Log Entries" under the "Administration" section of the Admin UI.
Django Admin Log Entries are automatically created when adminstrative changes happen and have always existed natively in Django Admin. This feature is simply providing a read-only UI view for admin/privileged users to access them with more ease.
See Administrative Change-logging for more details.
A new ExternalIntegration
model has been added which provides a centralized store for data such as URLs and credentials that are used to access systems external to Nautobot. This information can then be used by jobs or apps to perform actions such as creating DNS records or updating configuration management tickets.
The panels displayed on the Nautobot home page have been modified to enable a more personalized user experience. Individual panels can now be collapsed, hiding the contents from view. Additionally, panels can be reordered by dragging and dropping the panels to the desired order.
The Job
base class now includes a create_file(filename, content)
method which can be called by a Job to create a persistent file with the provided content when run. This file will be linked from the Job Result detail view for subsequent downloading by users, and can also be downloaded via the REST API (/api/extras/file-proxies/<id>/download/
) as desired.
The size of files Jobs can create via this method are constrained by the JOB_CREATE_FILE_MAX_SIZE
settings variable.
The specific storage backend used to retain such files is controlled by the
JOB_FILE_IO_STORAGE
settings variable. The default value of this setting uses the Nautobot database to store output files, which should work in all deployments but is generally not optimal and better alternatives may exist in your specific deployment. Refer to the documentation link above for more details.
Users must have permission to
view
theextras > file proxy
object type in order to list and download files from the REST API.
Provides the ability to have native JSON data inputs for Jobs, this is provided by a multi-line text input on the Job form and the provided JSON data is serialized prior to passing to the run()
method of the Job.
isnull
Filter on Nullable Fields (#1905)Models with nullable fields (i.e. model fields with null=True
) can now be filtered in the UI and the API with <field>__isnull=true/false
filters. These filters are automatically added to all appropriate fields.
Model fields that have the value
""
(i.e. blank) will not match with__isnull=True
. Instead, they will match with__isnull=False
.
The data export functionality in all object list views (allowing export of all or a filtered subset of objects to CSV, YAML, and/or as defined by an ExportTemplate
) has been changed from a synchronous operation to an asynchronous background task, leveraging the new ExportObjectList
system Job. As a result, exports of thousands of objects in a single operation will no longer fail due to browser timeout.
Users now must have the
run
action permission forextras > job
(specifically thenautobot.core.jobs.ExportObjectList
Job) in order to export objects, in addition to the normalview
permissions for the objects being exported.
The Nautobot UI has been updated with a customized theme, giving it a brand new look. In addition, Nautobot's navigation bar has been moved from the top to the left.
Support for versions of PostgreSQL prior to 12.0 has been removed as these versions are no longer maintained and contain bugs that prevent migrations from running in certain scenarios. The nautobot-server migrate
or nautobot-server post_upgrade
commands will now abort when detecting an unsupported PostgreSQL version.
HIDE_RESTRICTED_UI
Toggle (#4787)Support for HIDE_RESTRICTED_UI
has been removed. UI elements requiring specific permissions will now always be hidden from users lacking those permissions. Additionally, users not logged in will now be automatically redirected to the login page.
Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.6...v2.1.0
Published by glennmatthews 10 months ago
cryptography
to 41.0.7
due to CVE-2023-49083. As this is not a direct dependency of Nautobot, it will not auto-update when upgrading. Please be sure to upgrade your local environment.extras.run_job
and extras.run_jobbutton
permissions to run a Job via a Job Button. Only extras.run_job
permission is now required.paramiko
to 3.4.0
due to CVE-2023-48795. As this is not a direct dependency of Nautobot, it will not auto-update when upgrading. Please be sure to upgrade your local environment./extras/job-button/<uuid>/run/
URL endpoint; Job Buttons now use /extras/jobs/<uuid>/run/
endpoint like any other job.ensure_git_repository
.example_plugin.jobs.ExampleComplexJobButtonReceiver
.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.7...v1.6.8
Published by glennmatthews 10 months ago
custom_fields
decorator from InterfaceRedundancyGroupAssociation as it's not a supported feature for this model.SECURITY.md
.ensure_git_repository
while the desired commit is already checked out.Location.base_site
.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.6...v1.6.7
Published by glennmatthews 10 months ago
cryptography
to ~41.0.6
due to CVE-2023-49083. As this is not a direct dependency of Nautobot, it will not auto-update when upgrading. Please be sure to upgrade your local environment.@adobe/css-tools
to version 4.3.2 due to CVE-2023-48631.clean()
methods to save()
methods for ComputedField
, CustomField
, and Relationship
models to protect against creation of invalid data.get_default_namespace
and get_default_namespace_pk
methods to nautobot.apps.models
API.generate_secret_key.py
to use Python secrets
library instead of random
.nautobot.extras.choices.JobSourceChoices
.- #4805 - Removed check for __init__.py
in JOBS_ROOT
directory.SECURITY.md
.ensure_git_repository
while the desired commit is already checked out.my_apps/app1/
+ my_apps/app2/
), and lookups for UI view testing.AttributeError
raised by get_absolute_url()
when a valid absolute url cannot be found.IPAddress
default namespace, when no namespace is provided.prefix
, within
, within_include
, contains
.prefix
.django-tree-queries
to 0.16.1
to bring in some desired feature fixes.is_safe_url()
Django API with url_has_allowed_host_and_scheme()
replacement API.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.5...v2.0.6
Published by HanlinMiao 11 months ago
isnull
filters when model field is nullable.status
filters to support filtering by ID (UUID) as an alternative to filtering by name
.Job.create_file()
API and JOB_FILE_IO_STORAGE
configuration setting.ExternalIntegration
model to track connections to systems external to Nautobot.ExportObjectList
system Job.BRANDING_FILEPATHS["header_bullet"]
to customize the view header appearance.BRANDING_FILEPATHS["nav_bullet"]
to customize the nav menu appearance.files
to the /api/extras/job-results/
REST API./download/
endpoint for downloading the file content.HIDE_RESTRICTED_UI
. UI elements requiring specific permissions will now always be hidden from users lacking those permissions. Additionally, users not logged in will now be automatically redirected to the login page.ObjectPermission
where users.user
permissions could not be created.media_root
volume to developer Docker Compose environment.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.5...v2.1.0-beta.1
Published by gsnider2195 11 months ago
render_jinja2()
API to no longer automatically call mark_safe()
on the output.sdist
and wheel
packages from 69 MB to 29 MB.mkdocs
development dependency to 1.5.3
.examples/example_plugin
.ruff
to invoke tasks and CI.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.5...v1.6.6
Published by gsnider2195 11 months ago
render_jinja2()
API to no longer automatically call mark_safe()
on the output.rack_group
as a required field when creating a rack.sdist
and wheel
packages from 86 MB to 31 MB.psycopg2-binary
dependency to version 2.9.9.pylint
development dependency to version 2.17.7.mkdocs
development dependency to 1.5.3
.examples/example_plugin
.ruff
to invoke tasks and CI.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.4...v2.0.5
Published by glennmatthews 11 months ago
Django
minimum version to 3.2.23 to protect against CVE-2023-46695.axios
to version 1.6.0 due to CVE-2023-45857.tags
filters.None
when the device redundancy group was deleted.group
instead of tenant_group
.django_filters.DateTimeFilter
for only exact date matches.BaseModel.get_absolute_url
returning an AttributeError instead of raising it.documentation
category to release-notes.nautobot.apps
module throughout.nautobot-dev
images as latest
.NAUTOBOT_DYNAMIC_GROUPS_MEMBER_CACHE_TIMEOUT
environment variable reference from settings documentation.ModelChoiceField
in DCIM forms with more appropriate DynamicModelChoiceField
.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.3...v2.0.4
Published by glennmatthews 11 months ago
device_redundancy_groups
field to ConfigContextSerializer
.ltm/1.6
branch to ltm-1.6
.failover-strategy
field was required for the device redundancy group api.nautobot-dev
images as latest
.None
when the device redundancy group was deleted.django_filters.DateTimeFilter
for only exact date matches.host
and prefix_length
.NAUTOBOT_DYNAMIC_GROUPS_MEMBER_CACHE_TIMEOUT
environment variable reference from settings documentation.urllib3
to 2.0.7 due to CVE-2023-45803. This is not a direct dependency so it will not auto-update when upgrading. Please be sure to upgrade your local environment.Django
minimum version to 3.2.23 to protect against CVE-2023-46695.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.4...v1.6.5
Published by glennmatthews 12 months ago
ENABLE_ALPHA_UI
configuration option to the settings, which is initially set to False. When set to True, this option enables the "Alpha UI 2.0" feature.--no-build-ui
to --build-ui
, and its default value to False for the nautobot-server post-upgrade
command.post_upgrade
bug involving potential left over references to Aggregate, DeviceRole, and RackRole ContentTypes in ObjectChange records.'IPAddressBulkAddForm' has no field named 'parent'
when bulk creating IPs via UI.ScheduledJob.job_class
values are correctly transferred to ScheduledJob.task
during v2 migration.Meta
attributes into nested serializers (depth >= 1
).password
and sha256
that shouldn't generally appear in REST API responses.urllib3
to 2.0.7 due to CVE-2023-45803. This is not a direct dependency so it will not auto-update when upgrading. Please be sure to upgrade your local environment.JobResult
traceback and result output when a GitRepositorySync
job fails in certain ways.?depth=1
query parameter. For more details, please refer to GHSA-r2hw-74xv-4gqp.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.2...v2.0.3
Published by glennmatthews about 1 year ago
SUPPORT_MESSAGE
configuration setting.display
property of Location
and LocationType
, mitigating duplicated SQL queries in the related API views.stable
tagging for container builds in LTM release workflow.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.3...v1.6.4
Published by glennmatthews about 1 year ago
SUPPORT_MESSAGE
configuration setting.nautobot-server audit_graphql_queries
management command for evaluating breaking filter changes to existing GraphQLQuery instances.nautobot_config.py.j2
template that wouldn't detect the MySQL engine when Prometheus metrics are enabled.DeviceFilterForm.device_redundancy_group_priority
.docs/user-guide/administration/upgrading/from-v1/tables/v2-filters-renamed-fields.yml
.FEEDBACK_BUTTON_ENABLED
configuration setting.dns
to dnf
for install on RHEL systems.urllib3
to 2.0.6 due to CVE-2023-43804. This is not a direct dependency so it will not auto-update when upgrading. Please be sure to upgrade your local environment.postcss
npm
package to 8.4.31 to address CVE-2023-44270.babel/traverse
npm
dependency to 7.23.2 to address CVE-2023-45133.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.1...v2.0.2
Published by HanlinMiao about 1 year ago
Virtual
, LAG
, and Bridge
to be selected as a virtual Interface's parent
.invoke eslint
not running against local development environment.test_bulk_delete_form_contains_all_filtered
and test_bulk_edit_form_contains_all_filtered
generic tests to fail more gracefully if insufficient test data is available.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.0...v2.0.1
Published by HanlinMiao about 1 year ago
release.yml
and pre-release.yml
workflow files to target ci_integration.yml
in its own branch.ci_pullrequest.yml
for ltm/1.6
.GitPython
to 3.1.36
to address CVE-2023-41040
.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.2...v1.6.3
Published by glennmatthews about 1 year ago
💡 Please thoroughly review the release overview below to see what changes may affect you during upgrade. Our "Upgrading from Nautobot v1.X" guide provides a lot of information around pre- and post-migration helpers we have written that should assist you in a successful 2.0 upgrade. If you have any questions, please reach out to us on the #nautobot channel on Network to Code's Slack community or GitHub Discussions.
Nautobot 2.0 includes an "alpha" version of a new user interface (UI) for Nautobot, based on the React web framework.
Users can switch between the existing UI and new UI for views supported in the new UI via a "View in New UI" link in the page footer of the existing UI and a "Return to Legacy UI" link in the left sidebar of the new UI.
💡 The new UI also includes a "Submit Feedback" link that can be used to easily submit feedback regarding the new UI to the Nautobot maintainers.
As of Nautobot release 2.0.0, the new UI supports read-only access to Locations, Device Types, Devices, Prefixes, and IP Addresses; these views will be enhanced and refined, and support for additional models and workflows will be added, throughout the Nautobot 2.x release lifecycle.
ℹ️ As of Nautobot release 2.0.0, the new UI, as an alpha feature, does not yet support Nautobot Apps (plugins), but this capability will be added and supported in a future release.
Introduced the ability to assign one IPAddress
to multiple Interfaces
/Devices
and VMInterfaces
/VirtualMachines
by creating a many to many relationship between IPAddress
and Interface
/VMInterface
models represented as a through table model IPAddressToInterface
. This feature allows you to model a network environment where you have anycast IPAddresses
are shared extensively among a large number of Devices
/VirtualMachines
.
As a result of this feature and associated changes, you can no longer assign Interfaces
/VMInterfaces
during bulk creation of IPAddresses
, but a separate bulk-create endpoint has been introduced to allow the bulk import of IPAddressToInterface
assignments.
DeviceRole
, RackRole
, IPAM Role
, and IPAddressRoleChoices
have all been merged into a single generic Role
model. A Role
can now be created and associated to one or more of the content-types that support reference to a role
. These model content-types include dcim.device
, dcim.rack
, virtualization.virtualmachine
, ipam.ipaddress
, ipam.prefix
, and ipam.vlan
.
The new Namespace model expands on the functionality previously provided by VRF.enforce_unique
and the ENFORCE_GLOBAL_UNIQUE
settings flag, both of which have now been removed. Within a namespace, all VRFs, prefixes, and IP addresses must be unique and non-duplicated. For more details please refer to the documentation.
Nautobot's BaseModel
base class and related classes now implement automatic support for Django natural keys for lookup and referencing. For example:
>>> DeviceType.objects.first().natural_key()
['MegaCorp', 'Model 9000']
>>> DeviceType.objects.get_by_natural_key("MegaCorp", "Model 9000")
<DeviceType: Model 9000>
Developers can refer to the documentation on natural keys for details on how to support and use this feature.
Two new configuration settings, DEVICE_NAME_AS_NATURAL_KEY
and LOCATION_NAME_AS_NATURAL_KEY
, have been added to allow an administrator to customize the natural-key behavior of these two widely-used models.
Added the ?depth
query parameter in Nautobot v2.X to replace the ?brief
parameter in the REST API. It enables nested serialization functionality and offers a more dynamic and comprehensive browsable API. It allows users greater control of the API response data and it is available for both retrieving a single object and a list of objects. This parameter is a positive integer value that can range from 0 to 10. To learn more more, check out the documentation on the ?depth
query parameter.
Added Site Model Fields to Location. Location Model now has asn
, comments
, contact_email
, contact_name
, contact_phone
, facility
, latitude
, longitude
, physical_address
, shipping_address
and time_zone
fields.
The ipam.Aggregate
model has been removed and all existing aggregates will be migrated to ipam.Prefix
with type
set to "Container". The Aggregate.date_added
field will be migrated to Prefix.date_allocated
and changed from a Date field to a DateTime field with the time set to 00:00
. Aggregate.tenant
, Aggregate.rir
and Aggregate.description
will be migrated over to the same fields on Prefix
.
See the upgrade guide for more details on the data migration.
created
Field to DateTimeField for ChangeLoggedModel (#2076)The created
field of all models that inherit from ChangedLoggedModel
, which includes OrganizationalModel
and PrimaryModel
and therefore most objects in the core data model, has been changed from a DateField
to a DateTimeField
for added granularity. Preexisting records will show as created at midnight UTC on their original creation date.
All such objects may now be filtered by date or time or a combination of both. All other date-based behavior such as filtering works as it did before.
nautobot.utilities
into nautobot.core
(#2721)nautobot.utilities
no longer exists as a separate Python module or Django app. Its functionality has been collapsed into the nautobot.core
app. See details at Python Code Location Changes.
The Site
and Region
models have been removed in v2.0 and have been replaced with Location
of specific LocationType
. As a result, the existing Site
and Region
data will be migrated to corresponding LocationType
and Location
objects. Here is what to expect:
If you do not have any Site
and Region
instances in your existing database, running this data migration will do nothing.
If you only have Region
instances in your existing database, a LocationType
named Region will be created and for each legacy Region
instance, a corresponding Location
instance with the same attributes (id
, name
, description
, etc.) and hierarchy will be created.
If you only have Site
instances in your existing database:
A LocationType
named Site will be created and every preexisting root level LocationType
in your database will be updated to have the new Site LocationType
as their parent.
For each legacy Site
instance, a corresponding Location
instance with the same attributes (id
, name
, description
, tenant
, facility
, asn
, latitude
, longitude
, etc.) will be created, and any preexisting Locations
in your database will be updated to have the appropriate "site" Locations
as their parents.
Model instances that had a site
field (CircuitTermination
, Device
, PowerPanel
, RackGroup
, Rack
, Prefix
, VLANGroup
, VLAN
, Cluster
) assigned and did not have a location
attribute assigned will be updated to have their location
point to the new Location
corresponding to that Site
. All other attributes on these models will remain unchanged.
Model instances that were previously associated to the ContentType
for Site
(ComputedField
, CustomField
, CustomLink
, ExportTemplate
, ImageAttachment
, JobHook
, Note
, Relationship
, Status
, Tag
and Webhook
) will have their ContentType
replaced with Location
. All other attributes on these models will remain unchanged.
For Example:
We will start with a Site
instance with name AMS01 as the base Site
for two top-level Location
objects with names root-01 and root-02 respectively.
During the data migration, a LocationType
named Site will be created, and a Location
of Site LocationType
named AMS01 with all the information (asn
, latitude
, etc.) from the base Site
will be created.
The Location
objects named root-01 and root-02 will have this AMS01 Location
set as their parent
.
If you have both Site
and Region
instances in your existing database:
A LocationType
named Region will be created.
For each legacy Region
instance, a corresponding Location
instance with the same attributes (id
, name
, description
, etc.) will be created.
A LocationType
named Site will be created with the new LocationType
named Region set as its parent
.
Every pre-existing root-level LocationType
in your database will be updated to have the new LocationType
named Site as its parent
.
For each legacy Site
instance, a corresponding "site" Location
instance with the same attributes (id
, name
, description
, tenant
, facility
, asn
, latitude
, longitude
, etc.) will be created with its parent set to the corresponding "region" Location
if any.
Site
instances in your database without a Region
assigned to them, one additional Location
named Global Region of LocationType
Region will be created and each Location
of LocationType
Site created from the legacy region-less Site
instances will have the Global Region Location
as their parent.Model instances that had a site
attribute (CircuitTermination
, Device
, Location
, PowerPanel
, Rack
, RackGroup
, Prefix
, VLANGroup
, VLAN
, Cluster
) assigned and did not have a location
attribute assigned will be updated to have their location
point to the new Location
of LocationType
Site. All other attributes on these models will remain unchanged.
Model instances that were previously associated to the ContentType
for Site
or Region
(ComputedField
, CustomField
, CustomLink
, ExportTemplate
, ImageAttachment
, JobHook
, Note
, Relationship
, Status
, Tag
and Webhook
) will have their ContentType
replaced with Location
. All other attributes on these models will remain unchanged.
For Example:
There are two Site
instances and one Region
instance in your existing database. The Region
with name America has one child Site
instance named AMS01. And the other Site
instance named AUS01 is not associated with any Region
(region
attribute is set to None
).
The Site
AMS01 is the base Site
for two top-level Location
objects with names root-01 and root-02 respectively.
During the data migration, a LocationType
named Region and a Location
of this LocationType
named America with all the same information will be created.
The LocationType
named Site with its parent
set as the new LocationType
Region and a Location
of LocationType
named AMS01 with all the same information (asn
, latitude
, etc.) will be created. The Location
AMS01 will have Location
America as its parent
and each - Location
root-01 and root-02 will have Location
AMS01 as its parent
.
Finally, the Site
instance AUS01, since it does not have a Region
instance associated with it, its corresponding Location
AUS01 will have a new Location
named Global Region of LocationType
Region as its parent
.
In addition, legacy Site
instance with name AMS01 also has three Device
instances associated with it named ams01-edge-01, ams01-edge-02, and ams01-edge-03.
However, ams01-edge-01 only has its site
attribute set as Site
AMS01 whereas ams01-edge-02 and ams01-edge-03 have both its site
and location
attributes set Site
AMS01 and Location
root-01 respectively.
During the data migration, ams01-edge-01's location
attribute will point to the new Location
of LocationType
Site with name AMS01 while devices ams01-edge-02 and ams01-edge-03 will remain unchanged.
Region
and Site
relationships are being removed from these models: CircuitTermination
, Device
, Location
, Rack
, RackGroup
, PowerFeed
, PowerPanel
, ConfigContext
, Prefix
, VLAN
, VLANGroup
, Cluster
.
The ContentType
for Region
and Site
are being replaced with Location
on these models: ComputedField
, CustomField
, CustomLink
, ExportTemplate
, ImageAttachment
, JobHook
, Note
, Relationship
, Status
, Tag
and Webhook
.
The region
and site
fields are being removed in the filter
data of DynamicGroup
objects. The previously associated values are being added to the existing location
field and its associated list of filter values or to a new location
key with an empty list if one does not exist.
Check out the API and UI endpoints changes incurred by the changes stated above in the "Upgrading from Nautobot v1.X" guide.
Check out the Region and Site Related Data Model Migration Guide to learn how to migrate your Nautobot Apps and data models from Site
and Region
to Location
.
⚠️ This change may introduce breaking changes to your existing
DynamicGroup
filters,ObjectPermission
filters,Relationship
filters, and any other saved references to these fields. You should review any existing instances of these models before and after upgrading your production environment for any potentially subtle change. Please refer to the Upgrading from Nautobot v1.X guide for more details.
There were also instances where a foreign-key related field (e.g. console_ports
) was incorrectly mapped to a boolean membership filter (e.g. has_console_ports
), making it impossible to filter based on specific values of the foreign key:
For example in v1.x:
/dcim/devices/?console_ports=True
and /dcim/devices/?has_console_ports=True
are functionally the same and this behavior is incorrect.
This has been addressed in v2.x as follows:
console_ports
and similar filters are taking foreign key UUIDs as input values and can be used in this format: /dcim/devices/?console_ports=<uuid>
whereas has_console_ports
and similar filters remain the same.
Check out the specific changes documented in the table at UI and REST API Filter Changes
⚠️ This change may introduce breaking changes to your existing
DynamicGroup
filters,ObjectPermission
filters,Relationship
filters, and any other saved references to these fields. You should review any existing instances of these models before and after upgrading your production environment for any potentially subtle change. Please refer to the Upgrading from Nautobot v1.X guide for more details.
Many filter fields have been enhanced to enable filtering by both names and UUID primary keys.
For example in v1.X, to filter RackGroups
with a specific parent
value in the UI or make changes to them via the REST API, you could only to input slugs as the filter values:
/dcim/rack-groups/?parent=<slug>
Now in v2.x, you are able to filter those RackGroups
by their parent(s) names or UUID primary keys:
/dcim/rack-groups/?parent=<name>
or /dcim/rack-groups/?parent=<uuid>
Check out the specific changes documented in the table at UI and REST API Filter Changes
The DeviceRole
, RackRole
, ipam.Role
, and IPAddressRoleChoices
have all been removed and replaced with a extras.Role
model, This means that all references to any of the replaced models and choices now points to this generic role model.
In addition, the role
field of the IPAddress
model has also been changed from a choice field to a foreign key related field to the extras.Role
model.
Within Nautobot 2.0, Jobs has undergone significant changes within the overall functionality of Jobs along with migration for existing 1.x Jobs operation. Database changes for Jobs will affect DryRun functionality. Other significant changes to Jobs in 2.0 provide greater interoperability with Celery for registering, logging, and tracking however 2.0 will be moving away from previous backwards compatibility scripts. These improvements will simplify Job implementation and help reduce administration overhead for status tracking on completions and/or failures. For more details, refer to Migrating Jobs from Nautobot v1.X to Nautobot v2.0.
is_pool
Field and "Container" Status replaced by New Field Prefix.type
(#1362)A new type
field was added to Prefix
to replace the is_pool
boolean field and the "Container" status. The type
field can be set to "Network", "Pool" or "Container", with "Network" being the default.
Existing prefixes with a status of "Container" will be migrated to the "Container" type. Existing prefixes with is_pool
set will be migrated to the "Pool" type. Prefixes with both is_pool
set and a status of "Container" will be migrated to the "Pool" type.
The "Container" status will be removed and all prefixes will be migrated to the "Active" status if it exists. If the "Active" status was deleted, prefixes will be migrated to the first available prefix status in the database that is not "Container".
⚠️ This change may introduce breaking changes to your existing
DynamicGroup
filters,ObjectPermission
filters,Relationship
filters, and any other saved references to these fields. You should review any existing instances of these models before and after upgrading your production environment for any potentially subtle change. Please refer to the Upgrading from Nautobot v1.X guide for more details.
Some Foreign Key fields have been renamed to follow a more self-consistent pattern across the Nautobot app. This change is aimed to offer more clarity and predictability when it comes to related object database operations:
For example in v1.x to create a circuit object with type
"circuit-type-1", you would do:
Circuit.objects.create(
cid="Circuit 1",
provider="provider-1",
type="circuit-type-1",
status="active",
)
and to filter Circuit
objects of type
"circuit-type-2", you would do:
Circuit.objects.filter(type="circuit-type-2")
Now in v2.x, we have renamed the Foreign Key field type
on Circuit Model to circuit_type
, because this naming convention made it clearer that this Foregin Key field is pointing to the model CircuitType
. The same operations would look like:
Circuit.objects.create(
cid="Circuit 1",
provider="provider-1",
circuit_type="circuit-type-1",
status="active",
)
Circuit.objects.filter(circuit_type="circuit-type-2")
Check out more Foreign Key related changes documented in the table Renamed Database Fields
In addition to the changes made to Foreign Key fields' own names, some of their related_names
are also renamed:
For example in v1.x, to query Circuit
objects with CircuitTermination
instances located in sites ["ams01", "ams02", "atl03"], you would do:
Circuit.objects.filter(terminations__site__in=["ams01", "ams02", "atl03"])
Now in v2.x, we have renamed the Foreign Key field circuit
's related_name
attribute terminations
on CircuitTermination
Model to circuit_terminations
, the same operations would look like:
Circuit.objects.filter(circuit_terminations__site__in=["ams01", "ams02", "atl03"])
Check out more related-name
changes documented in the table Renamed Database Fields
⚠️ This change may introduce breaking changes to your existing
DynamicGroup
filters,ObjectPermission
filters,Relationship
filters, and any other saved references to these fields. You should review any existing instances of these models before and after upgrading your production environment for any potentially subtle change. Please refer to the Upgrading from Nautobot v1.X guide for more details.
Some filter fields have been renamed to reflect their functionalities better.
For example in v1.X, to filter FrontPorts
that has a cable attached in the UI or make changes to them via Rest API, you would use the cabled
filter:
/dcim/front-ports/?cabled=True
Now in v2.x, you would instead use the has_cable
filter which has a more user-friendly name:
/dcim/front-ports/?has_cable=True
Check out the specific changes documented in the table at UI and REST API Filter Changes
In Nautobot 2.0 and later, the REST API defaults, when the caller doesn't request a specific API version, to using the latest available version of the REST API. This is a change from Nautobot 1.x, where the default behavior was to use the 1.2 version of the REST API even when newer versions were available.
Exporting objects and lists of objects to CSV format has been totally reimplemented in a new framework for ease of use and maintainability. Instead of accessing http://nautobot/<app>/<model>/?export
users can now use the URL pattern http://nautobot/api/<app>/<model>/?format=csv
(the "Export" links in the UI have of course been updated accordingly), as the new CSV rendering for exports is based on the REST API serializer definitions. This results in substantially more comprehensive CSV representations of many models.
Conversely, importing objects from CSV format has also been reimplemented in the same new framework. The REST API can now accept CSV files as well as the existing JSON support, and the UI for importing CSVs uses this same framework behind the scenes.
⚠️ The Nautobot 2.0 CSV formats for exports and imports are not backwards-compatible with the Nautobot 1.x CSV formats. In general, the CSV formats are subject to refinement in future releases, and should not be considered a stable API for data portability between differing Nautobot versions.
An immediate benefit users can notice from this reimplementation is that CSVs should now generally be "round-trip" capable, meaning that you can export a set of records to CSV format and then import that CSV into a different Nautobot instance (or delete the records and use the CSV to recreate them) without needing to "massage" the CSV into a different set of columns or fields. One caveat to this is many-to-many fields (such as VRF.import_targets
or Interface.tagged_vlans
), which are not currently included in CSV exports or supported for CSV import, with the exception of object tags
which are supported. Support for many-to-many export and import via CSV may be added in a future release.
A benefit to App developers is that data models no longer need to define a csv_headers
attribute or implement a to_csv
method, because implementing the REST API for a model is now sufficient to enable CSV import/export support for that model. Similarly, there is no longer a need to implement a CSVForm
for each model in order to support CSV import.
In addition to the above improvements, you can now reference related objects in your CSV by using a combination of unique fields. For instance:
Instead of:
name,rack
Device one,7f3ca431-8103-45cc-a9ce-b94c1f784a1d
you can use:
name,rack__location__name,rack__name
Device one,Equinix DC6,R204
This enhancement allows you to specify related objects using their unique attributes, making data import even more intuitive and flexible.
Support for ?brief
REST API query parameter and Nested*Serializers
have been removed in Nautobot v2.X. They are replaced by the new ?depth
query parameter.
django-cacheops
(#1721)Nautobot no longer uses django-cacheops
for caching of database queries or other information. In some cases this has been replaced by the use of Django's native Redis caching capabilities.
The configuration settings CACHEOPS
, CACHEOPS_DEFAULTS
, CACHEOPS_DEGRADE_ON_FAILURE
, CACHEOPS_ENABLED
, CACHEOPS_HEALTH_CHECK_ENABLED
, CACHEOPS_REDIS
, etc. are now unused by Nautobot and may be removed from your configuration.
manage.py
Removed (#1634)When we launched Nautobot we introduced the nautobot-server
command as the primary entrypoint to managing your application, replacing the legacy manage.py
script that is common with Django-based applications. The original manage.py
was left there initially in v1.0.0 as a fallback, however it is no longer needed, so we have removed it in Nautobot 2.0.
⚠️ This change may introduce breaking changes to your existing
DynamicGroup
filters,ObjectPermission
filters,Relationship
filters, and any other saved references to these fields. You should review any existing instances of these models before and after upgrading your production environment for any potentially subtle change. Please refer to the Upgrading from Nautobot v1.X guide for more details.
As a part of breaking changes made in v2.X, shadowed filter/filterset fields are being removed throughout Nautobot.
In Nautobot 1.x, for some of the foreign-key related fields:
- The field was shadowed for the purpose of replacing the PK filter with a lookup-based on a more human-readable value (typically slug
, if available).
- A PK-based filter was available as well, generally with a name suffixed by _id
Now these two filter fields will be replaced by a single filter field that can support both names and UUID primary keys as inputs; As a result, PK-based filters suffixed by _id
will no longer be supported in v2.0.
For example in v1.X, to filter Circuits
with a specific provider
value in the UI or make changes to them via the REST API with a UUID primary key, you would use:
/circuits/circuits/?provider_id=<uuid>
Now in v2.x, that format is no longer supported. Instead, you would use:
/circuits/circuits/?provider=<uuid>
Check out the specific changes documented in the table at UI and REST API Filter Changes
Support for RQ and django-rq
, deprecated since Nautobot 1.1.0, has been fully removed from Nautobot 2.0.
The slug
field has been removed from all core models except for GitRepository
. Generally, Nautobot URLs that referenced the slug
field have been changed to use the primary key instead. For example, the URL for https://nautobot/dcim/locations/building-01
would change to a URL similar to https://nautobot/dcim/locations/e41f381a-a53b-485a-886f-9d36859b47a1
. There are a small number of URLs that still reference a value that's not the primary key, including some URLs related to secrets providers, cables and jobs.
A natural_slug
property has been added to all models that inherit from BaseModel
to provide a human-readable value for use in tools that require a loose reference to a Nautobot object, but this value is not equivalent to the slug
field and is not guaranteed to be unique.
A natural key interface has been provided for most models to allow for uniquely referencing objects by a name that is friendlier than the primary key. For more information on the usage of natural keys vs primary keys see the documentation for Uniquely Identifying a Nautobot Object.
Full Changelog: https://github.com/nautobot/nautobot/compare/v1.6.2...v2.0.0
Published by HanlinMiao about 1 year ago
IPAddressToInterface
objects.netutils_parser
to network_driver
.BaseModelSerializer.determine_view_options()
API for use in new UI.fix_custom_fields
management command.ObjectList
view filters in FiltersPanelContent
component of the new UI.nautobot.apps
namespace.q
filter to list and detail views./api/extras/jobs/<name>/...
REST API endpoints as an alternative option to the existing /api/extras/jobs/<uuid>/...
endpoints.slugify
Django template tag as a Jinja filter.manage.py
.ChangedLoggedModel.created
field from DateField
to DateTimeField
.test_notes_url_functionality
test case to APIViewTestCases.NotesURLViewTestCase
generic test class.api
parameter to NotesMixin.get_notes_url()
model method.tagged_vlans
and untagged_vlan
as selected/prefetched in (VM)Interface API views.ip_addresses
as prefetched in VMInterface API views.natural_key_field_names
for Prefix from ["namespace", "prefix"]
to ["namespace", "network", "prefix_length"]
nautobot.core.api.metadata
to nautobot.core.api.serializers
.comments
and tags
fields (if present) in the appropriate location to avoid needing every serializer to specify these fields in its configuration.fix_custom_fields
to skip models without any custom fields.CablePath matching query does not exist
exception when deleting a device with multiple types of connected interfaces.nautobot-server fix_custom_fields
on large datasets.alter_queryset
not being respected by list views based on NautobotUIViewSet
.tags
field from Job input forms.tags
field from DynamicGroup filter options in DynamicGroupEditForm
.alter_queryset
not being called when constructing a table.test_notes_url_on_object
test case that never actually tested anything./notes/
action endpoints./notes/
action endpoints that was inadvertently introduced in #4517.npm
in Docker image to use 30s timeout, pinned npm
to 9.X, and changed Docker build to use npm ci
instead of npm install
to improve builds.RoleModelSerializerMixin
, RoleRequiredRoleModelSerializerMixin
and RoleSerializerField
from generic Role-related documentation.semver
npm package.cryptography
to 41.0.4 due to GHSA-v8gr-m533-ghj9. This is not a direct dependency so will not auto-update when upgrading. Please be sure to upgrade your local environment.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.0-rc.3...v2.0.0-rc.4
Published by bryanculver about 1 year ago
We implemented the natural_slug
property on all BaseModel
objects. A Natural Slug is a natural-key-derived, human-readable, automation-friendly representation of the object it references. It cannot be used to look up an object and is intended for a one-way "slug-ification" of the natural key.
With changing the IPAddress
model's interface
field from a ForeignKey
to a ManyToManyField
, the IPAddressToInterface
model was introduced to track the many-to-many relationship between IPAddress
and Interface
(and VMInterface
) objects. This model is now exposed via the REST API as a new endpoint. You can find more information about this endpoint in the auto-generated API documentation.
Namespace
column to VRFDeviceAssignmentTable
and VRFPrefixAssignmentTable
to display assigned VRFs' namespace
property.namespace
attribute to rendering of "IP Addresses" columns of relevant Interface
and InterfaceRedundancyGroup
tables.namespace
attribute to rendering of primary_ip
fields in DeviceDetailView
and VirtualMachineDetailView
.primary_ip
field in VirtualMachineDetailView
..natural_slug
property on all models.install_system.md
file.object_type
to the Advanced tab of new-UI detail views in general.__all__
on Meta.fields
and custom_fields
displayed a JSON blob.TreeNodeMultipleChoiceFilter
filtering that could result in incorrect inclusion of unrelated records with the same name located elsewhere in the tree.setup_XX.x
deprecated script.next
branch to remove some redundant tests, run more tests in parallel and test the container build.ltm-1.6
and develop
branch tags respectively.ip_family
queryset annotation from PrefixQuerySet
and IPAddressQuerySet
.tags
, custom-fields
, computed-fields
, relationships
from new-UI object detailnotes_url
from new-UI object detail views.GitPython
to 3.1.36
to address CVE-2023-41040
.Full Changelog: https://github.com/nautobot/nautobot/compare/v2.0.0-rc.2...v2.0.0-rc.3