BGP sessions management tool
include_*
directive in templates (by @rwielk)created_by_request
and updated_by_request
fields/provisioning/available-ix-peers/
to /peeringdb/available-ixp-peers/
PEERINGMANAGER_CONFIGURATION
environment variable to change configuration module to loadshared_facilities
Jinja2 filter to get a list of facilities in which both networks are, according to PeeringDB recordspassive
field to BGP sessions (IXP and direct) to denote a session that will wait for open messagesmultihop_ttl
column to BGP sessions (IXP and direct) tablesThe 1.8.x releases require Python 3.8 or later as well as PostgreSQL 12 or later.
JobResult
model has been moved from the extras app to core and renamed to Job
. Accordingly, its REST API endpoint has been moved from /api/extras/job-results/
to /api/core/jobs/
obj_type
field on the Job
model (previously JobResult
) has been renamed to object_type
for consistencyJOBRESULT_RETENTION
configuration parameter has been renamed to JOB_RETENTION
/api/docs/
is now /api/schema/swagger-ui/
/api/redoc/
is now /api/schema/redoc/
Tag
model has been moved from the utils app to extras. Accordingly, its REST API endpoint has been moved from /api/utils/tags/
to /api/extras/tags/
ObjectChange
model has been moved from the utils app to extras. Accordingly, its REST API endpoint has been moved from /api/utils/object-changes/
to /api/extras/object-changes/
CACHE_TIMEOUT
configuration parameter has been removedA lot of efforts has been put in making the global code base more maintainable and future proof. This shouldn't have impact on using Peering Manager in general. However it brings some changes to users as well by improving API schema.
Also changing the selected affiliated AS via API as seen its dedicated endpoint removed. It is still possible to change it but users must now use the user preferences endpoint at /api/users/userpref/
.
This global code refactoring is also the reason of the above mentioned API breaking changes and the below mentioned models normalisation.
Models have been normalised using common classes and now inherit automatically some fields. This means that some fields (name
, slug
, description
) have been added to some models.
All name
fields have been limited to 100 characters as well as the slug
fields. If values in these fields exceed the 100 characters limit, you'll need to adjust them prior to the upgrade.
pyixapi
Fields has been added to store IX-API tokens and their respective expiration times. The use of pyixapi
allows cleaner code and better maintainability. Data retrieval has been improved and is now faster by fetching all data instead of doing multiple calls to IX-API instances with filtering. Data correlation is done in memory but it should not explode in RAM as data amount is relatively small.
To lookup prefixes, the default settings used to include a long list of IRR sources, some of them being less relevant as of today (year 2023). This list has been reduce to include only authoritative sources as the default. This means that it now includes:
The default host for prefix lookup has been changed to use NTT's which is located at rr.ntt.net
.
These changes are made in an attempt to follow Internet best pratices in term of IRR trust by deprecating non-authoritative sources.
The webhook framework has been extended to allow more flexibility and less triggers.
Webhooks can now be created as regular objects, without the use of the admin panel. They can be found in the "Other" menu of the sidebar and in the /api/extras/webhooks/
API endpoint.
Also webhooks are now attached to content types which mean they can be triggered only for selected object types. Additional headers can be added, the body of the webhook can be changed using templating and Jinja2. Conditions can be defined to fire a webhook only if some terms are met.
Reviewing the webhook model documentation is highly encouraged to get to know more about it.
It has been raised several times that there were not enough statuses to fit users workflows. Several statuses have been added to address this issue.
Pre and post maintenance statuses for BGP groups, IXPs and devices have been included to better reflect maintenance work and allow according workflow.
BGP sessions have 6 more possible statuses to reflect the life cycle of a session from requested to decommissioned. Possible statuses are now: requested, provisioning, enabled, pre-maintenance, maintenance, post-maintenance, disabled, decommissioning, and decommissioned.
contact
Jinja2 filterexists_in_peeringdb
IXP session property and display as table columnunique
::1
(by @netravnen)The 1.7.4 release is the last one to support PostgreSQL 10. Next releases will require at least PostgreSQL 11.
running
when they failed in an unpredictable wayserialize_object
instead of model_to_dict
; this should fix as_json
and as_yaml
filters behaviourip
filterprefix_list
filterixp_sessions
filter when using ixp
parameterTASKS_REDIS_UNIX_SOCKET_PATH
and CACHING_REDIS_UNIX_SOCKET_PATH
settings (by @@yu-re-ka)quote
filter for templatesConnection
; the mac_address
field can be used to track MAC addresses associated to
connections; only valid Ethernet MAC address formats are accepted (EUI-64 included); a mac
Jinja2 filter is provided to change MAC addresses format in template (e.g. for Cisco users)inherited_status
Jinja2 filter for group-less direct sessions-v 0
as a silencer for common scripts, show prefix counts when using grab_prefixes
indent
Jinja2 filter to manipulate spacing in templatesprefix_list
Jinja2 filterapi/peering/internet-exchanges/<id>/prefixes/
in favour of the peeringdb_prefixes
field in api/peering/internet-exchanges/<id>
, the prefixes endpoint will be removed in the next features releaseThe 1.7.x releases require Python 3.8 or later as well as PostgreSQL 10 or later.
status
field has been added.status
field has been added.status
field has been added.enabled
field has been removed (replaced by status
). Templating will not be broken as an enabled
property is still exposed (not in the REST API though) which reflects the boolean value of the expression status == "enabled"
.device_state
field has been renamed to status
.state
field has been renamed to status
.Configuration contexts used to be a feature restricted to few objects. With this release's improvements, they are available on almost all objects. A new configuration context object is also provided to use common contexts for several objects.
Objects have two levels of contexts. The first level is about config contexts assigned to objects with weights. The second level is the local context data, specific to the object itself. The two levels will be merged into one final context given the CONFIG_CONTEXT_RECURSIVE_MERGE
and CONFIG_CONTEXT_LIST_MERGE
settings (possible values are detailed in the documentation).
Peering Manager now allows users to define custom templates that can be used when exporting objects. To create an export template, navigate to Others > Export Templates.
Each export template is associated with a certain type of object and uses the Jinja2 templating engine. Therefore all filters available for configuration templates are also available for export templates.
The list of objects returned from the database when rendering an export template is stored in the dataset
variable, which you'll typically want to iterate through using a for loop. Object properties can be access by name. For example:
+---------------------------------------------------------------------
| Internet Exchange Points
+---------------------------------------------------------------------
{% for ixp in dataset %}
{{ ixp.name }}
{% for connection in ixp | connections %}
- {{ "{:<15}".format(connection.ipv4_address | ip) }} | {{ connection.ipv6_address | ip }}
{% endfor %}
+---------------------------------------------------------------------
{% endfor %}
If you need to use the config context data in an export template, you'll should use the property config_context
to get all the config context data.
Connections, routers, direct peering sessions and IXP peering sessions have a status
field indicating their operational state. For sessions, this field replace the old enabled
field. The enabled
property is still exposed as part of the templating system (corresponding to a status
with value enabled
) but users should start migrating to prepare of its removal in a later release.
As status can be changed at different level, a inherited_status
Jinja2 filter is introduced to be able to get the status of an object taking into account the one of its parent (if any). For instance, if a connection is disabled but an IXP session attached to it is enabled, the filter will tell that the session is disabled. Also if a connection as a router linked to it and the router is in maintenance status, the session will be considered as in maintenance even if the connection is enabled.
Possible values for status
are: enabled
, maintenance
and disabled
.
housekeeping
CommandObject changelog and job results used to be cleanup automatically. This is no longer the case as the code logic has been entirely moved to the new housekeeping
command. By default, changelog and job results will not be cleaned unless users run the command for it. This command also checks the availability of new releases.
The housekeeping
command is intended to be run regularly, at any interval users want.
In addition to the command, a new JOBRESULT_RETENTION
setting, with a default value of 90 days, has been added to allow different retention periods for changelog and job results.
--tasks
flag to peeringdb_sync
commandunique
filter for queryset in templatesRELEASE_CHECK_TIMEOUT
, not needed with new housekeeping
commandtype
field optionalinclude_configuration
and include_email
) support for templatesip
filter work with all IP fields