Network Source of Truth & Network Automation Platform
APACHE-2.0 License
Bot releases are visible (Hide)
Published by bryanculver about 2 years ago
ℹ️ NOTE: This release is functionally identical to v1.4.6, just fixing the advertised version.
pyproject.toml
to be a proper full release.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.6...v1.4.7
v1.4.6 Changelog for those that might have missed it.
nautobot-plugin-nornir
in the Apps section of the documentation.pip
to install Poetry into Nautobot dev environment.oauthlib
to 3.2.1
for CVE-2022-36087
. This is a dependency of social-auth-core
so will not auto-update when upgrading. Please be sure to upgrade your local environment.ObjectChange.change_context_detail
field from 100 to 400 chars, and add truncation to it. Also adding truncation to ObjectChange.object_repr
.nautobot.core.settings
to match expected behavior on NAPALM_USERNAME
, NAPALM_PASSWORD
, and NAPALM_TIMEOUT
based on documentation.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.5...v1.4.7
Published by bryanculver about 2 years ago
nautobot-plugin-nornir
in the Apps section of the documentation.pip
to install Poetry into Nautobot dev environment.oauthlib
to 3.2.1
for CVE-2022-36087
. This is a dependency of social-auth-core
so will not auto-update when upgrading. Please be sure to upgrade your local environment.ObjectChange.change_context_detail
field from 100 to 400 chars, and add truncation to it. Also adding truncation to ObjectChange.object_repr
.nautobot.core.settings
to match expected behavior on NAPALM_USERNAME
, NAPALM_PASSWORD
, and NAPALM_TIMEOUT
based on documentation.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.5...v1.4.6
Published by bryanculver about 2 years ago
created
and last_updated
fields to Device Component
and ComponentTemplate
models.django-extensions
to 3.2.1
, drf-spectacular
to 0.24.2
, drf-yasg
to 1.21.4
.AnotherExampleModel
list view by adding a get_absolute_url()
method to the AnotherExampleModel
class and adding an AnotherExampleModel
detail view template.test_list_objects_unknown_filter_no_strict_filtering
failure if a filterset couldn't be found for a given model.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.4...v1.4.5
Published by bryanculver about 2 years ago
next
, develop
routinely.towncrier_template.j2
from root to develop directory.color
and type
filters are not set.nautobot-firewall-models
) were installed.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.3...v1.4.4
Published by gsnider2195 about 2 years ago
towncrier
for changelog fragments.drf-spectacular
dependency to version 0.24.get_route_for_model()
to support REST API routes.next
updates to address code changes per package.ObjectDynamicGroupsView
.render_filter()
method and filter
field from table columnsjob_class
no longer found behavior.invoke
tasks to be run even if rich
is not installed.dev
and final-dev
Docker images to reduce image size.inspect.getsource()
call from Job class.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.2...v1.4.3
Published by bryanculver about 2 years ago
args
and kwargs
to NavMenuItem
.dynamic_groups
field in GraphQL on objects that can belong to dynamic groups.pylint
to linting suite and CI.pylint
checkers.extras.Tag
.netutils
dependency from 1.1.x to 1.2.x.name
rather than slug
.action_buttons = None
.nautobot-dev
Docker images by clearing Poetry cacheFull Changelog: https://github.com/nautobot/nautobot/compare/v1.4.1...v1.4.2
Published by bryanculver about 2 years ago
extras.Status
to simplify exporting and importing of database dumps for Status
objects.validate_models
management command to validate each instance in the database.--pull
parameter for invoke build
to tell Docker to pull images when building containers.render_form.html
include template to not render a duplicate object_note
field.DynamicGroup.objects.get_for_model()
to support nested Dynamic Groups.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.0...v1.4.1
Published by bryanculver about 2 years ago
Objects with custom fields now support filter lookup expressions for filtering by custom field values, such as cf_date_field__gte=2022-08-11
to select objects whose date_field
custom field has a date of 2022-08-11 or later.
Custom fields now have a distinct slug
field. The custom field name
attribute should be considered deprecated, and will be removed in a future major release (see also #824.) Additionally, the label
attribute, while currently optional in the database, will become mandatory in that same future release as a consequence. When migrating from an earlier Nautobot release to version 1.4 or later, the slug
and label
for all existing custom fields will be automatically populated if not previously defined.
A new version of the /api/extras/custom-fields/
REST API endpoints has been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior (name
required, slug
and label
optional; if unspecified, the slug
and label
will receive default values based on the provided name
). A REST API client can request API version 1.4, in which case the updated API will require slug
and label
parameters in place of name
.
Additionally, REST API serialization of custom field data is itself now versioned. For all object endpoints that include custom field data under the custom_fields
key, REST API versions 1.3 and earlier will continue the previous behavior of indexing the custom_fields
dictionary by fields' name
values, but when REST API version 1.4 or later is requested, the custom_fields
data will be indexed by slug
instead.
For technical reasons of backwards-compatibility, the database (ORM) and GraphQL interfaces continue to access and store object custom field data exclusively under the name
key; this will change to use the slug
in a future major release. Again, watch #824 for plans in that regard.
A plugin may now define extra tabs which will be appended to the object view's list of tabs.
You can refer to the plugin development guide on how to add tabs to existing object detail views.
Jobs can now specify a template_name
property and provide a custom template with additional JavaScript and CSS to help with user input on the Job submission form.
You can refer to the Job class metadata attribute documentation on how to build and define this template.
Cluster, IP Address, Prefix, and Rack models can now be filtered on in Dynamic Groups and can also support nested or groups of Dynamic Groups. Some fields have been excluded from filtering until a sensible widget can be provided.
Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.
The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage
.
The DCIM, Virtualization FilterSets have been updated with over 150 new filters, including hybrid filters that support filtering on both pk
and slug
(or pk
and name
where slug
is not available). A new filter class NaturalKeyOrPKMultipleChoiceFilter
was added to nautobot.utilities.filters
to support filtering on multiple fields of a related object. See the Best Practices documentation for more information.
Jobs can now be configured to run automatically when a change event occurs on a Nautobot object. Job hooks associate jobs to content types and actions to run jobs when a create, update or delete action occurs on the selected content type. A new job base class JobHookReceiver
was introduced that jobs must subclass to be associated with a job hook. See the Job Hooks documentation for more information.
JobResult records now save the arguments with which the Job was called, allowing for easy re-execution of the Job with the same arguments as before. A "re-run" button has been added to the JobResult list view and detail view.
To locate network information more precisely than a Site defines, you can now define a hierarchy of Location Types (for example, Building
← Floor
← Room
) and then create Locations corresponding to these types within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to Location representing a specific building, wing, floor, room, etc. as appropriate to your needs.
Info: At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.
Interface and VMInterface models now have parent_interface
and bridge
keys. An interface of type Virtual
can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge
interface type has also been added, but the bridge
interface property is not restricted to interfaces of this type.)
Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py
via defining UI_RACK_VIEW_TRUNCATE_FUNCTION
. Default behavior is to split on .
and return the first item in the list.
"Save SVG" link presents the same view as what is currently displayed on screen
Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.
include=relationships
as a query parameter."relationships" -> <relationship-slug> -> "source"
or "relationships" -> <relationship-slug> -> "destination"
.nautobot.extras.api.serializers.NautobotModelSerializer
base class has been added. Using this class guarantees support for relationships, custom fields, and computed fields on the serializer, and provides for a streamlined developer experience.Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".
A new version of the /dcim/interfaces/*
REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".
Visit the documentation on REST API versioning for more information on using the versioned APIs.
New in Nautobot 1.4 is the debut of NautobotUIViewSet
: A powerful plugin development tool that can save plugin developer hundreds of lines of code compared to using legacy generic.views
. Using it to gain access to default functionalities previous provided by generic.views
such as create()
, bulk_create()
, update()
, partial_update()
, bulk_update()
, destroy()
, bulk_destroy()
, retrieve()
and list()
actions.
Note that this ViewSet is catered specifically to the UI, not the API.
Concrete examples on how to use NautobotUIViewSet
resides in nautobot.circuits.views
.
Visit the documentation on plugins/development.md for more information on how to use NautobotUIViewSet
.
Primary and Organizational models now support notes. A notes tab has been added to the Object Detail view for all models that inherit the Primary or Organizational base abstract models.
Warning: Any plugin that inherits from one of these two models and uses the
ViewTestCases.PrimaryObjectViewTestCase
orViewTestCases.OrganizationalObjectViewTestCase
for their test will need to add theNotesObjectView
to the objects URLs. See Plugin Development for more details.
Notes can also be used via the REST API at endpoint /api/extras/notes
or per object at the object's /notes
endpoint.
Info: For implementers of REST API views (core and/or plugins), a new
nautobot.extras.api.views.NautobotModelViewSet
base class has been added. Use of this class ensures that all features fromPrimaryModel
orOrganizationalModel
are accessible through the API. This includes custom fields and notes.
Dynamic Groups may now be nested in parent/child relationships. The Dynamic Group edit view now has a "Child Groups" tab that allows one to make other Dynamic Groups of the same content type children of the parent group. Any filters provided by the child groups are used to filter the members from the parent group using one of three operators: "Restrict (AND)", "Include (OR)", or "Exclude (NOT)". This allows for logical parenthetical grouping of nested groups by the operator you choose for that child group association to the parent.
Warning: The default behavior of Dynamic Groups with an empty filter (
{}
) has been inverted to include all objects matching the content type by default instead of matching no objects. This was necessary to implement the progressive layering of child filters similarly to how we use filters to reduce desired objects from basic list view filters.
A number of mixin classes have been renamed for improved self-consistency and clarity of usage. The former names of these mixins are still available for now as aliases, but inheriting from these mixins will raise a DeprecationWarning
, and these aliases will be removed in a future major release.
Former Name | New Name |
---|---|
AddRemoveTagsForm |
TagsBulkEditFormMixin |
CustomFieldBulkCreateForm |
CustomFieldModelBulkEditFormMixin |
CustomFieldBulkEditForm |
CustomFieldModelBulkEditFormMixin |
CustomFieldFilterForm |
CustomFieldModelFilterFormMixin |
CustomFieldModelForm |
CustomFieldModelFormMixin |
RelationshipModelForm |
RelationshipModelFormMixin |
StatusBulkEditFormMixin |
StatusModelBulkEditFormMixin |
StatusFilterFormMixin |
StatusModelFilterFormMixin |
Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.
A new configuration setting, STRICT_FILTERING
has been added. It defaults to True
, enabling strict validation of filter parameters, but can be set to False
to disable this validation.
Warning: Setting
STRICT_FILTERING
toFalse
can result in unexpected filtering results in the case of user error, for example a request to/api/dcim/devices/?has_primry_ip=false
(note the typoprimry
) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.
The settings_and_registry
default context processor was changed to purely settings
- the (large) Nautobot application registry dictionary is no longer provided as part of the render context for all templates by default. Added a new registry
template tag that can be invoked by specific templates to provide this variable where needed.
NautobotViewSet
and accompanying helper methods, documentation.NautobotViewSet
s.dumpdata
docs to exclude django_rq
exports.link_text
render on top of buttons.has_sensitive_variables
.v1.4.0b1
.slug
field to Custom Field model, added 1.4 REST API version of the api/extras/custom-fields/
endpoints.RelationshipModelForm
, renamed other mixins and added aliases for backwards compatibility.NaturalKeyOrPKMultipleChoiceFilter
documentation.relationships
data on model endpoints; added NautobotModelSerializer
base class.Job
with the same parameters.query_params
for ObjectVar
in Jobs documentation.get_changelog_url
to a method on objects that support changelogs, updated template context.~9.1.1
-> ~9.2.0
, black ~22.3.0
-> ~22.6.0
, coverage 6.4.1
-> 6.4.2
, django-cacheops 6.0
-> 6.1
, django-cryptography 1.0
-> 1.1
, django-debug-toolbar ~3.4.0
-> ~3.5.0
, django-extensions ~3.1.5
-> ~3.2.0
, drf-yasg ~1.20.0
-> ^1.20.0
, importlib-metadata ~4.4
-> ^4.4.0
, jsonschema ~4.4.0
-> ~4.8.0
, mkdocs 1.3.0
-> 1.3.1
, mkdocs ==1.3.0
-> ==1.3.1
, mkdocs-include-markdown-plugin ~3.2.3
-> ~3.6.0
, mkdocs-include-markdown-plugin ==3.2.3
-> ==3.6.1
, social-auth-core ~4.2.0
-> ~4.3.0
, svgwrite 1.4.2
-> 1.4.3
__source
with message: "" is not a valid UUID.!!! attention
next
and develop
introduced conflicting migration numbers during the release cycle. This necessitates reordering the migration in next
. If you installed v1.4.0a1
, you will need to roll back a migration before upgrading/installing v1.4.0a2
and newer. If you have not installed v1.4.0a
this will not be an issue.
Before upgrading, run: `nautobot-server migrate extras 0033_add__optimized_indexing`. This will revert the reordered migration `0034_configcontextschema__remove_name_unique__create_constraint_unique_name_owner`, which is now number `0035`.
Perform the Nautobot upgrade as usual and proceed with post-installation migration.
No data loss is expected as the reordered migration only modified indexing on existing fields.
nautobot.extras.forms.NautobotBulkEditForm
base class. All bulk-edit forms for models that support both custom fields and relationships now inherit from this class.NaturalKeyOrPKMultipleChoiceFilter
to nautobot.utilities.filters
.nautobot.dcim.filters
FilterSets.cable_terminations
to the model_features
registry.settings_and_registry
default context processor to purely settings
, moving registry dictionary to be accessible via registry
template tag.parent_interface
and bridge
fields to Interface and VMInterface models.hyperlinked_object
template filter to consistently reference objects in templates.STRICT_FILTERING
setting is added and enabled by default.name
, owner_content_type
, owner_object_id
instead of just name
).parent_interface
and bridge
from 1.4 serializer of Interfaces.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.10...v1.4.0
Published by bryanculver about 2 years ago
Custom fields now have a distinct slug
field. The custom field name
attribute should be considered deprecated, and will be removed in a future major release (see also #824.) Additionally, the label
attribute, while currently optional in the database, will become mandatory in that same future release as a consequence. When migrating from an earlier Nautobot release to version 1.4 or later, the slug
and label
for all existing custom fields will be automatically populated if not previously defined.
A new version of the /api/extras/custom-fields/
REST API endpoints has been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior (name
required, slug
and label
optional; if unspecified, the slug
and label
will receive default values based on the provided name
). A REST API client can request API version 1.4, in which case the updated API will require slug
and label
parameters in place of name
.
Additionally, REST API serialization of custom field data is itself now versioned. For all object endpoints that include custom field data under the custom_fields
key, REST API versions 1.3 and earlier will continue the previous behavior of indexing the custom_fields
dictionary by fields' name
values, but when REST API version 1.4 or later is requested, the custom_fields
data will be indexed by slug
instead.
For technical reasons of backwards-compatibility, the database (ORM) and GraphQL interfaces continue to access and store object custom field data exclusively under the name
key; this will change to use the slug
in a future major release. Again, watch #824 for plans in that regard.
Jobs can now specify a template_name
property and provide a custom template with additional JavaScript and CSS to help with user input on the Job submission form.
You can refer to the Job class metadata attribute documentation on how to build and define this template.
Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.
The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage
.
The DCIM, Virtualization FilterSets have been updated with over 150 new filters, including hybrid filters that support filtering on both pk
and slug
(or pk
and name
where slug
is not available). A new filter class NaturalKeyOrPKMultipleChoiceFilter
was added to nautobot.utilities.filters
to support filtering on multiple fields of a related object. See the Best Practices documentation for more information.
Jobs can now be configured to run automatically when a change event occurs on a Nautobot object. Job hooks associate jobs to content types and actions to run jobs when a create, update or delete action occurs on the selected content type. A new job base class JobHookReceiver
was introduced that jobs must subclass to be associated with a job hook. See the Job Hooks documentation for more information.
JobResult records now save the arguments with which the Job was called, allowing for easy re-execution of the Job with the same arguments as before. A "re-run" button has been added to the JobResult list view and detail view.
To locate network information more precisely than a Site defines, you can now define a hierarchy of Location Types (for example, Building
← Floor
← Room
) and then create Locations corresponding to these types within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to Location representing a specific building, wing, floor, room, etc. as appropriate to your needs.
Info:
At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.
A plugin may now define extra tabs which will be appended to the object view's list of tabs.
You can refer to the plugin development guide on how to add tabs to existing object detail views.
Interface and VMInterface models now have parent_interface
and bridge
keys. An interface of type Virtual
can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge
interface type has also been added, but the bridge
interface property is not restricted to interfaces of this type.)
Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py
via defining UI_RACK_VIEW_TRUNCATE_FUNCTION
. Default behavior is to split on .
and return the first item in the list.
"Save SVG" link presents the same view as what is currently displayed on screen
Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.
include=relationships
as a query parameter."relationships" -> <relationship-slug> -> "source"
or "relationships" -> <relationship-slug> -> "destination"
.nautobot.extras.api.serializers.NautobotModelSerializer
base class has been added. Using this class guarantees support for relationships, custom fields, and computed fields on the serializer, and provides for a streamlined developer experience.Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".
A new version of the /dcim/interfaces/*
REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".
Visit the documentation on REST API versioning for more information on using the versioned APIs.
Primary and Organizational models now support notes. A notes tab has been added to the Object Detail view for all models that inherit the Primary or Organizational base abstract models.
Warning:
Any plugin that inherits from one of these two models and uses theViewTestCases.PrimaryObjectViewTestCase
orViewTestCases.OrganizationalObjectViewTestCase
for their test will need to add theNotesObjectView
to the objects URLs. See Plugin Development for more details.
Notes can also be used via the REST API at endpoint /api/extras/notes
or per object at the object's /notes
endpoint.
Info:
For implementers of REST API views (core and/or plugins), a newnautobot.extras.api.views.NautobotModelViewSet
base class has been added. Use of this class ensures that all features fromPrimaryModel
orOrganizationalModel
are accessible through the API. This includes custom fields and notes.
Dynamic Groups may now be nested in parent/child relationships. The Dynamic Group edit view now has a "Child Groups" tab that allows one to make other Dynamic Groups of the same content type children of the parent group. Any filters provided by the child groups are used to filter the members from the parent group using one of three operators: "Restrict (AND)", "Include (OR)", or "Exclude (NOT)". This allows for logical parenthetical grouping of nested groups by the operator you choose for that child group association to the parent.
Warning:
The default behavior of Dynamic Groups with an empty filter ({}
) has been inverted to include all objects matching the content type by default instead of matching no objects. This was necessary to implement the progressive layering of child filters similarly to how we use filters to reduce desired objects from basic list view filters.
A number of mixin classes have been renamed for improved self-consistency and clarity of usage. The former names of these mixins are still available for now as aliases, but inheriting from these mixins will raise a DeprecationWarning
, and these aliases will be removed in a future major release.
Former Name | New Name |
---|---|
AddRemoveTagsForm |
TagsBulkEditFormMixin |
CustomFieldBulkCreateForm |
CustomFieldModelBulkEditFormMixin |
CustomFieldBulkEditForm |
CustomFieldModelBulkEditFormMixin |
CustomFieldFilterForm |
CustomFieldModelFilterFormMixin |
CustomFieldModelForm |
CustomFieldModelFormMixin |
RelationshipModelForm |
RelationshipModelFormMixin |
StatusBulkEditFormMixin |
StatusModelBulkEditFormMixin |
StatusFilterFormMixin |
StatusModelFilterFormMixin |
Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.
A new configuration setting, STRICT_FILTERING
has been added. It defaults to True
, enabling strict validation of filter parameters, but can be set to False
to disable this validation.
Warning:
SettingSTRICT_FILTERING
toFalse
can result in unexpected filtering results in the case of user error, for example a request to/api/dcim/devices/?has_primry_ip=false
(note the typoprimry
) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.
The settings_and_registry
default context processor was changed to purely settings
- the (large) Nautobot application registry dictionary is no longer provided as part of the render context for all templates by default. Added a new registry
template tag that can be invoked by specific templates to provide this variable where needed.
slug
field to Custom Field model, added 1.4 REST API version of the api/extras/custom-fields/
endpoints.RelationshipModelForm
, renamed other mixins and added aliases for backwards compatibility.NaturalKeyOrPKMultipleChoiceFilter
documentation.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.0-beta.1...v1.4.0-rc.1
Published by bryanculver about 2 years ago
remove_stale_scheduled_jobs
management command which removes all stale scheduled jobs and also added has_sensitive_variables
field to Job model which prevents the job's input parameters from being saved to the database.--local
option to nautobot-server runjob
command.--data
parameter to nautobot-server runjob
command.HIDE_RESTRICTED_UI
is enabled and user is not authenticated.mkdocs
, svgwrite
.IMPORTANT
With introducing thehas_sensitive_variables
flag on Job classes and model (see: #2091), jobs can be prevented from storing their inputs in the database. Due to the nature of queuing or scheduling jobs, the desired inputs must be stored for future use.New safe-default behavior will only permit jobs to be executed immediately, as
has_sensitive_variables
defaults toTrue
. This value can be overridden by the Job class itself or the Job model edit page. Values entered for jobs executing immediately go straight to the Celery message bus and are cleaned up on completion of execution.Scheduling jobs or requiring approval necessitates those values to be stored in the database until they have been sent to the Celery message bus for execution.
During installation of
v1.3.10
, a migration is applied to set thehas_sensitive_variables
value toTrue
to all existing Jobs. However to maintain backwards-compatibility, past scheduled jobs are permitted to keep their schedule. New schedules cannot be made until an administrator has overridden thehas_sensitive_variables
for the desired Job.A new management command exists (
remove_stale_scheduled_jobs
) which will aid in cleaning up schedules to past jobs which may still have sensitive data stored in the database. This command is not exhaustive nor intended to clean up sensitive values stored in the database. You should review theextras_scheduledjob
table for any further cleanup.Note: Leveraging the Secrets and Secret Groups features in Jobs does not need to be considered a sensitive variable. Secrets are retrieved by reference at run time, which means no secret value is stored directly in the database.
Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.9...v1.3.10
Published by bryanculver about 2 years ago
New in Beta 1
Jobs can now specify a template_name
property and provide a custom template with additional JavaScript and CSS to help with user input on the Job submission form.
You can refer to the Job class metadata attribute documentation on how to build and define this template.
Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.
The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage
.
New in Beta 1
The DCIM, Virtualization FilterSets have been updated with over 150 new filters, including hybrid filters that support filtering on both pk
and slug
(or pk
and name
where slug
is not available). A new filter class NaturalKeyOrPKMultipleChoiceFilter
was added to nautobot.utilities.filters
to support filtering on multiple fields of a related object. See the Best Practices documentation for more information.
New in Beta 1
Jobs can now be configured to run automatically when a change event occurs on a Nautobot object. Job hooks associate jobs to content types and actions to run jobs when a create, update or delete action occurs on the selected content type. A new job base class JobHookReceiver
was introduced that jobs must subclass to be associated with a job hook. See the Job Hooks documentation for more information.
New in Beta 1
JobResult records now save the arguments with which the Job was called, allowing for easy re-execution of the Job with the same arguments as before. A "re-run" button has been added to the JobResult list view and detail view.
To locate network information more precisely than a Site defines, you can now define a hierarchy of Location Types (for example, Building
← Floor
← Room
) and then create Locations corresponding to these types within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to Location representing a specific building, wing, floor, room, etc. as appropriate to your needs.
ℹ️ At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.
A plugin may now define extra tabs which will be appended to the object view's list of tabs.
You can refer to the plugin development guide on how to add tabs to existing object detail views.
Interface and VMInterface models now have parent_interface
and bridge
keys. An interface of type Virtual
can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge
interface type has also been added, but the bridge
interface property is not restricted to interfaces of this type.)
Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py
via defining UI_RACK_VIEW_TRUNCATE_FUNCTION
. Default behavior is to split on .
and return the first item in the list.
"Save SVG" link presents the same view as what is currently displayed on screen
Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.
New in Beta 1
include=relationships
as a query parameter."relationships" -> <relationship-slug> -> "source"
or "relationships" -> <relationship-slug> -> "destination"
.nautobot.extras.api.serializers.NautobotModelSerializer
base class has been added. Using this class guarantees support for relationships, custom fields, and computed fields on the serializer, and provides for a streamlined developer experience.Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".
A new version of the /dcim/interfaces/*
REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".
Visit the documentation on REST API versioning for more information on using the versioned APIs.
New in Beta 1
Primary and Organizational models now support notes. A notes tab has been added to the Object Detail view for all models that inherit the Primary or Organizational base abstract models.
⚠️ Any plugin that inherits from one of these two models and uses the
ViewTestCases.PrimaryObjectViewTestCase
orViewTestCases.OrganizationalObjectViewTestCase
for their test will need to add theNotesObjectView
to the objects URLs. See Plugin Development for more details.
New in Beta 1
Dynamic Groups may now be nested in parent/child relationships. The Dynamic Group edit view now has a "Child Groups" tab that allows one to make other Dynamic Groups of the same content type children of the parent group. Any filters provided by the child groups are used to filter the members from the parent group using one of three operators: "Restrict (AND)", "Include (OR)", or "Exclude (NOT)". This allows for logical parenthetical grouping of nested groups by the operator you choose for that child group association to the parent.
⚠️ The default behavior of Dynamic Groups with an empty filter (
{}
) has been inverted to include all objects matching the content type by default instead of matching no objects. This was necessary to implement the progressive layering of child filters similarly to how we use filters to reduce desired objects from basic list view filters.
Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.
A new configuration setting, STRICT_FILTERING
has been added. It defaults to True
, enabling strict validation of filter parameters, but can be set to False
to disable this validation.
⚠️ Setting
STRICT_FILTERING
toFalse
can result in unexpected filtering results in the case of user error, for example a request to/api/dcim/devices/?has_primry_ip=false
(note the typoprimry
) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.
The settings_and_registry
default context processor was changed to purely settings
- the (large) Nautobot application registry dictionary is no longer provided as part of the render context for all templates by default. Added a new registry
template tag that can be invoked by specific templates to provide this variable where needed.
Attention:
next
anddevelop
introduced conflicting migration numbers during the release cycle. This necessitates reordering the migration innext
. If you installedv1.4.0a1
orv1.4.0a2
, you will need to roll back a migration before upgrading/installingv1.4.0b1
. If you have not installed eitherv1.4.0a1
orv1.4.0a2
this will not be an issue.Before upgrading, run:
nautobot-server migrate extras 0033_add__optimized_indexing
. This will revert to migrations prior to those introduced in 1.4.Perform the Nautobot upgrade as usual and proceed with post-installation migration.
Data loss may occur from features in earlier alphas!
relationships
data on model endpoints; added NautobotModelSerializer
base class.~9.1.1
-> ~9.2.0
, black ~22.3.0
-> ~22.6.0
, coverage 6.4.1
-> 6.4.2
, django-cacheops 6.0
-> 6.1
, django-cryptography 1.0
-> 1.1
, django-debug-toolbar ~3.4.0
-> ~3.5.0
, django-extensions ~3.1.5
-> ~3.2.0
, drf-yasg ~1.20.0
-> ^1.20.0
, importlib-metadata ~4.4
-> ^4.4.0
, jsonschema ~4.4.0
-> ~4.8.0
, mkdocs 1.3.0
-> 1.3.1
, mkdocs ==1.3.0
-> ==1.3.1
, mkdocs-include-markdown-plugin ~3.2.3
-> ~3.6.0
, mkdocs-include-markdown-plugin ==3.2.3
-> ==3.6.1
, social-auth-core ~4.2.0
-> ~4.3.0
, svgwrite 1.4.2
-> 1.4.3
Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.0-alpha.2...v1.4.0-beta.1
Published by bryanculver about 2 years ago
IPAddress
objectsFull Changelog: https://github.com/nautobot/nautobot/compare/v1.3.8...v1.3.9
Published by bryanculver over 2 years ago
Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.
The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage
.
New in Alpha 2
To locate network information more precisely than a Site defines, you can now define a hierarchy of Location Types (for example, Building
← Floor
← Room
) and then create Locations corresponding to these types within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to Location representing a specific building, wing, floor, room, etc. as appropriate to your needs.
At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.
Interface and VMInterface models now have parent_interface
and bridge
keys. An interface of type Virtual
can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge
interface type has also been added, but the bridge
interface property is not restricted to interfaces of this type.)
Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py
via defining UI_RACK_VIEW_TRUNCATE_FUNCTION
. Default behavior is to split on .
and return the first item in the list.
"Save SVG" link presents the same view as what is currently displayed on screen
Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.
Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".
A new version of the /dcim/interfaces/*
REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".
Visit the documentation on REST API versioning for more information on using the versioned APIs.
New in Alpha 2
A plugin may now define extra tabs which will be appended to the object view's list of tabs.
You can refer to the plugin development guide on how to add tabs to existing object detail views.
New in Alpha 2
The DCIM FilterSets have been updated with 137 new filters, including hybrid filters that support filtering on both pk
and slug
(or pk
and name
where slug
is not available). A new filter class NaturalKeyOrPKMultipleChoiceFilter
was added to nautobot.utilities.filters
to support filtering on multiple fields of a related object. See the Best Practices documentation for more information.
Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.
A new configuration setting, STRICT_FILTERING
has been added. It defaults to True
, enabling strict validation of filter parameters, but can be set to False
to disable this validation.
Setting
STRICT_FILTERING
toFalse
can result in unexpected filtering results in the case of user error, for example a request to/api/dcim/devices/?has_primry_ip=false
(note the typoprimry
) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.
New in Alpha 2
The settings_and_registry
default context processor was changed to purely settings
- the (large) Nautobot application registry dictionary is no longer provided as part of the render context for all templates by default. Added a new registry
template tag that can be invoked by specific templates to provide this variable where needed.
Attention:
next
anddevelop
introduced conflicting migration numbers during the release cycle. This necessitates reordering the migration innext
. If you installedv1.4.0a1
, you will need to roll back a migration before upgrading/installingv1.4.0a2
and newer. If you have not installedv1.4.0a
this will not be an issue.Before upgrading, run:
nautobot-server migrate extras 0033_add__optimized_indexing
. This will revert the reordered migration0034_configcontextschema__remove_name_unique__create_constraint_unique_name_owner
, which is now number0035
.Perform the Nautobot upgrade as usual and proceed with post-installation migration.
No data loss is expected as the reordered migration only modified indexing on existing fields.
nautobot.extras.forms.NautobotBulkEditForm
base class. All bulk-edit forms for models that support both custom fields and relationships now inherit from this class.NaturalKeyOrPKMultipleChoiceFilter
to nautobot.utilities.filters
.nautobot.dcim.filters
FilterSets.cable_terminations
to the model_features
registry.settings_and_registry
default context processor to purely settings
, moving registry dictionary to be accessible via registry
template tag.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.4.0-alpha.1...v1.4.0-alpha.2
Published by bryanculver over 2 years ago
cf_
.celery >= 5.2.7
, django-jinja >= 2.10.2
, and mysqlclient >= 2.1.1
versions in lock file (patch updates).Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.7...v1.3.8
Published by bryanculver over 2 years ago
next
.HIDE_RESTRICTED_UI
is TrueFileAttachment.mimetype
to 255 to allow for all mime types to be used.pyproject.toml
.HIDE_RESTRICTED_UI
is activated_abs_length
validation error.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.6...v1.3.7
Published by bryanculver over 2 years ago
Nautobot's UI now supports dark mode, both explicitly and via browser preference selection.
The "Theme" link in the footer provides a modal popup to select the preferred theme. This preference is saved per browser via localStorage
.
Interface and VMInterface models now have parent_interface
and bridge
keys. An interface of type Virtual
can now associate to a parent physical interface on the same device, virtual chassis, or virtual machine, and an interface of any type can specify another interface as its associated bridge interface. (A new Bridge
interface type has also been added, but the bridge
interface property is not restricted to interfaces of this type.)
Users can now toggle device full name and truncated name in the rack elevation view. The truncating function is customizable in nautobot_config.py
via defining UI_RACK_VIEW_TRUNCATE_FUNCTION
. Default behavior is to split on .
and return the first item in the list.
"Save SVG" link presents the same view as what is currently displayed on screen
Current preferred toggle state is preserved across tabs (requires refresh) and persists in-browser until local storage is cleared. This presents a consistent behavior when browsing between multiple racks.
**Currently missing in changelog in release v1.4.0-alpha.1
.
Interface and VMInterface models now support a status. Default statuses that are available to be set are: Active, Planned, Maintenance, Failed, and Decommissioned. During migration all existing interfaces will be set to the status of "Active".
A new version of the /dcim/interfaces/*
REST API endpoints have been implemented. By default this endpoint continues to demonstrate the pre-1.4 behavior unless the REST API client explicitly requests API version=1.4. If you continue to use the pre-1.4 API endpoints, status is defaulted to "Active".
Visit the documentation on REST API versioning for more information on using the versioned APIs.
Filtering of object lists in the UI and in the REST API will now report an error if an unknown or unrecognized filter parameter is specified. This is a behavior change from previous Nautobot releases, in which unknown filter parameters would be silently discarded and ignored.
A new configuration setting, STRICT_FILTERING
has been added. It defaults to True
, enabling strict validation of filter parameters, but can be set to False
to disable this validation.
Warning:
Setting
STRICT_FILTERING
toFalse
can result in unexpected filtering results in the case of user error, for example a request to/api/dcim/devices/?has_primry_ip=false
(note the typoprimry
) will result in a list of all devices, rather than the intended list of only devices that lack a primary IP address. In the case of Jobs or external automation making use of such a filter, this could have wide-ranging consequences.
parent_interface
and bridge
fields to Interface and VMInterface models.STRICT_FILTERING
setting is added and enabled by default.parent_interface
and bridge
from 1.4 serializer of Interfaces.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.6...v1.4.0-alpha.1
Published by bryanculver over 2 years ago
TransactionTestCase
.next
.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.5...v1.3.6
Published by bryanculver over 2 years ago
Interface
and VMInterface
objects via the REST API while specifying untagged_vlan
without mode
also set in the payload. A 400 error will now be raised as expected.nautobot-server dumpdata
not working due to django_rq
update. Updated documentation.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.4...v1.3.5
Published by bryanculver over 2 years ago
SearchFilter
that is now used on all core filtersets to provide the q=
search parameter for basic searching in list view of objects./api/dcim/devices/
and /api/virtualization/virtual-machines/
relating to configuration contexts.SANITIZER_PATTERNS
optional setting and nautobot.utilities.logging.sanitize
function and use it for redaction of Job log entries.Full Changelog: https://github.com/nautobot/nautobot/compare/v1.3.3...v1.3.4
Published by bryanculver over 2 years ago
run_job_for_testing
helper method for testing Jobs in plugins, internally.drf-spectacular
.get_return_url
for plugin reverse URLs.docker/Dockerfile
.STATICFILES_STORAGE
settings.NestedVMInterfaceSerializer
referencing the wrong model.