ca_file_path to Webhook model to support user supplied CA certificate verification of webhook requestsget_lldp_neighors_detail to validation LLDP neighborsrack_group field to PowerFeed CSV exportrack and site filters for cablesMultiObjectVar for custom scriptscommit_default custom script attribute to not commit changes by defaultdevice to parent in interface editing VLAN filtering logicchanged_object_idparseURL related to variables in API URLlocal_context_data boolean filter for devicesIPNetworkVarCustom scripts allow for the execution of arbitrary code via the NetBox UI. They can be used to automatically create, manipulate, or clean up objects or perform other tasks within NetBox. Scripts are defined as Python files which contain one or more subclasses of extras.scripts.Script. Variable fields can be defined within scripts, which render as form fields within the web UI to prompt the user for input data. Scripts are executed and information is logged via the web UI. Please see the docs for more detail.
Note: There are currently no API endpoints for this feature. These are planned for the upcoming v2.7 release.
mac_address filter for virtual machinesprefetch_related() instead of select_related() and removing use of update()virtual_chassis_member device filterNetBox now supports power circuit modeling via two new models: power panels and power feeds. Power feeds are terminated to power panels and are optionally associated with individual racks. Each power feed defines a supply type (AC/DC), amperage, voltage, and phase. A power port can be connected directly to a power feed, but a power feed may have only one power port connected to it.
Additionally, the power port model, which represents a device's power input, has been extended to include fields denoting maximum and allocated draw, in volt-amperes. This allows a device (e.g. a PDU) to calculate its total load compared to its connected power feed.
To improve performance, NetBox now supports caching for most object and list views. Caching is implemented using Redis, which is now a required dependency. (Previously, Redis was required only if webhooks were enabled.)
A new configuration parameter is available to control the cache timeout:
# Cache timeout (in seconds)
CACHE_TIMEOUT = 900
Django 2.1 introduced the ability to enforce view-only permissions for different object types. NetBox now enforces these by default. You can grant view permission to a user or group by assigning the "can view" permission for the desired object(s).
To exempt certain object types from the enforcement of view permissions, so that any user (including anonymous users)
can view them, add them to the new EXEMPT_VIEW_PERMISSIONS setting in configuration.py:
EXEMPT_VIEW_PERMISSIONS = [
'dcim.site',
'ipam.prefix',
]
To exclude all objects, effectively disabling view permissions and restoring pre-v2.6 behavior, set:
EXEMPT_VIEW_PERMISSIONS = ['*']
Custom links are created under the admin UI and will be displayed on each object of the selected type. Link text and URLs can be formed from Jinja2 template code, with the viewed object passed as context data. For example, to link to an external NMS from the device view, you might create a custom link with the following URL:
https://nms.example.com/nodes/?name={{ obj.name }}
Custom links appear as buttons at the top of the object view. Grouped links will render as a dropdown menu beneath a single button.
NetBox now supports exposing native Prometheus metrics from the application. Prometheus is a
popular time series metric platform used for monitoring. Metric exposition can be toggled with the METRICS_ENABLED
configuration setting; it is not enabled by default. NetBox exposes metrics at the /metrics HTTP endpoint, e.g.
https://netbox.local/metrics.
NetBox makes use of the django-prometheus library to export a number of different types of metrics, including:
For the exhaustive list of exposed metrics, visit the /metrics endpoint on your NetBox instance. See the documentation
for more details on using Prometheus metrics in NetBox.
Redis is an in-memory data store similar to memcached. While Redis has been an optional component
of NetBox since the introduction of webhooks in version 2.4, it is now required to support NetBox's new caching
functionality (as well as other planned features). Redis can be installed via your platform's package manager: for
example, sudo apt-get install redis-server on Ubuntu or sudo yum install redis on CentOS.
The Redis database is configured using a configuration setting similar to DATABASE in configuration.py:
REDIS = {
'HOST': 'localhost',
'PORT': 6379,
'PASSWORD': '',
'DATABASE': 0,
'CACHE_DATABASE': 1,
'DEFAULT_TIMEOUT': 300,
'SSL': False,
}
Note that if you were using these settings in a prior release with webhooks, the DATABASE setting remains the same but
an additional CACHE_DATABASE setting has been added with a default value of 1 to support the caching backend. The
DATABASE setting will be renamed in a future release of NetBox to better relay the meaning of the setting. It is
highly recommended to keep the webhook and cache databases seperate. Using the same database number for both may result
in webhook processing data being lost during cache flushing events.
Previously, specifying a related object in an API request required knowing the primary key (integer ID) of that object. For example, when creating a new device, its rack would be specified as an integer:
{
"name": "MyNewDevice",
"rack": 123,
...
}
The NetBox API now also supports referencing related objects by a set of sufficiently unique attrbiutes. For example, a rack can be identified by its name and parent site:
{
"name": "MyNewDevice",
"rack": {
"site": {
"name": "Equinix DC6"
},
"name": "R204"
},
...
}
There is no limit to the depth of nested references. Note that if the provided parameters do not return exactly one object, a validation error is raised.
The rendered config context for devices and VMs is now included by default in all API results (list and detail views).
Previously, the rendered config context was available only in the detail view for individual objects. Users with large
amounts of context data may observe a performance drop when returning multiple objects. To combat this, in cases where
the rendered config context is not needed, the query parameter ?exclude=config_context may be appended to the request
URL to exclude the config context data from the API response.
NetBox now makes use of its own Tag model instead of the stock model which ships with django-taggit. This new model
lives in the extras app and thus any permissions that you may have configured using "Taggit | Tag" should be changed
to now use "Extras | Tag." Also note that the admin interface for tags has been removed as it was redundant to the
functionality provided by the front end UI.
If you have the CORS_ORIGIN_WHITELIST configuration parameter defined, note that each origin must now incldue a URI
scheme. This change was introuced in django-cors-headers 3.0.
dns_name field to IPAddress/api/extras/_custom_field_choices/color field for tagsdescription field to console/power components and device bayscomments field for tagsform_factor to type (backward-compatible until v2.7)/metrics view from authenticationpower_port and feed_leg fields to power outlet creation form/api/dcim/power-panels/ and /api/dcim/power-feeds//api/extras/_custom_field_choices/prefix_count and vlan_count.id__in filter is now deprecated and will be removed in v2.7. (Begin using the ?id=1&id=2 format instead.)description field for all device components.instance_count has been renamed to device_count.form_factor has been renamed to type. Backward compatibility for form_factor will be maintained until NetBox v2.7.type filter has been renamed to kind.count_* read-only fields have been renamed to *_count for consistency with other objects.virtualmachine_count read-only field.color and comments fields to the Tag serializer.