starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add configuration templates rendering pre and post-processing hook scripts #8057

New Issue
Closed
opened 2025-12-29 20:31:47 +01:00 by adam · 10 comments
adam commented 2025-12-29 20:31:47 +01:00
Owner
Copy Link

Originally created by @dmulyalin on GitHub (May 15, 2023).

NetBox version

v.3.5.1

Feature type

New functionality

Proposed functionality

Add capability to run custom scripts during device configuration rendering to source data for rendering or perform post processing actions.

Use case

Currently configuration templates can use any data attached to device object or any data defined in device configuration context. This is a lot to work with, but might be not enough in certain cases, also using device object to retrieve other portions of the data stored in database might not be trivial or even possible.

Pre-processing scripts are normal custom scripts in a way that they run the same and have access to Netbox Database, but this feature request is to add support to use data outputted from those script as an input into device configuration rendering.

Several concrete use cases:

  • Compose lists of VRF, Vlans, circuits etc. using data modeled in Netbox database to render device configuration
  • Source data from external, in relation to Netbox, data sources over API e.g. record reservations or simple data retrieval
  • Send API requests to external entities e.g. to trigger provisioning/testing workflows, similar to webhooks
  • Pre-process data modeled in Netbox to transform it in a structure that is easier to render with templates

All in all configuration rendering functionality is very well welcomed addition to Netbox, but IMHO it can become even more powerful if this or similar feature will be implemented.

Database changes

None, if rendering scripts will be stored as custom scripts in the first place.

External dependencies

None

Originally created by @dmulyalin on GitHub (May 15, 2023). ### NetBox version v.3.5.1 ### Feature type New functionality ### Proposed functionality Add capability to run custom scripts during device configuration rendering to source data for rendering or perform post processing actions. ### Use case Currently configuration templates can use any data attached to `device` object or any data defined in device configuration context. This is a lot to work with, but might be not enough in certain cases, also using device object to retrieve other portions of the data stored in database might not be trivial or even possible. Pre-processing scripts are normal custom scripts in a way that they run the same and have access to Netbox Database, but this feature request is to add support to use data outputted from those script as an input into device configuration rendering. Several concrete use cases: - Compose lists of VRF, Vlans, circuits etc. using data modeled in Netbox database to render device configuration - Source data from external, in relation to Netbox, data sources over API e.g. record reservations or simple data retrieval - Send API requests to external entities e.g. to trigger provisioning/testing workflows, similar to webhooks - Pre-process data modeled in Netbox to transform it in a structure that is easier to render with templates All in all configuration rendering functionality is very well welcomed addition to Netbox, but IMHO it can become even more powerful if this or similar feature will be implemented. ### Database changes None, if rendering scripts will be stored as custom scripts in the first place. ### External dependencies None
adam added the type: featurestatus: revisions needed labels 2025-12-29 20:31:47 +01:00
adam closed this issue 2025-12-29 20:31:47 +01:00
adam commented 2025-12-29 20:31:48 +01:00
Author
Owner
Copy Link

@jonasnieberle commented on GitHub (May 15, 2023):

Yes, it would be a very nice feature if you can access the complete netbox database in the configuration templates like:

{% set sites = dcim.sites.all() %}
{% set vlans = ipam.vlans.all() %}
@jonasnieberle commented on GitHub (May 15, 2023): Yes, it would be a very nice feature if you can access the complete netbox database in the configuration templates like: ```bash {% set sites = dcim.sites.all() %} {% set vlans = ipam.vlans.all() %} ```
adam commented 2025-12-29 20:31:48 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (May 15, 2023):

Custom pre processing scripts is a more general purpose way of accessing netbox database from templates compared to injecting predefined objects like you @JonasEinfach demonstrated above, but either way would be an improvement IMHO.

@dmulyalin commented on GitHub (May 15, 2023): Custom pre processing scripts is a more general purpose way of accessing netbox database from templates compared to injecting predefined objects like you @JonasEinfach demonstrated above, but either way would be an improvement IMHO.
adam commented 2025-12-29 20:31:48 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (May 15, 2023):

Pre-processing scripts are normal custom scripts in a way that they run the same and have access to Netbox Database, but this feature request is to add support to use data outputted from those script as an input into device configuration rendering.

Please extend your feature request with a proposed implementation. Custom scripts are executed asynchronously while configuration templates are rendered synchronously. We cannot execute a script and block the webserver thread until the script finishes.

All the proposed usecases could imo be solved by using the existing JINJA_FILTERS setting to provide custom filters for the template rendering. And instead of this FR, it might be an idea to explore if it would make sense to add a way to get other querysets, for example by importing all the netbox models and adding them to the jinja context, kinda like we do with nbshell.

@kkthxbye-code commented on GitHub (May 15, 2023): > Pre-processing scripts are normal custom scripts in a way that they run the same and have access to Netbox Database, but this feature request is to add support to use data outputted from those script as an input into device configuration rendering. Please extend your feature request with a proposed implementation. Custom scripts are executed asynchronously while configuration templates are rendered synchronously. We cannot execute a script and block the webserver thread until the script finishes. All the proposed usecases could imo be solved by using the existing `JINJA_FILTERS` setting to provide custom filters for the template rendering. And instead of this FR, it might be an idea to explore if it would make sense to add a way to get other querysets, for example by importing all the netbox models and adding them to the jinja context, kinda like we do with nbshell.
adam commented 2025-12-29 20:31:48 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (May 15, 2023):

Ic, yeah, you right, adding some form of DB entry point might be easier from implementation perspectives. But yeah, rendering hook scripts would need to be run synchronously unless rendering would be changed to be implemented by async workers.

@dmulyalin commented on GitHub (May 15, 2023): Ic, yeah, you right, adding some form of DB entry point might be easier from implementation perspectives. But yeah, rendering hook scripts would need to be run synchronously unless rendering would be changed to be implemented by async workers.
adam commented 2025-12-29 20:31:48 +01:00
Author
Owner
Copy Link

@jonasnieberle commented on GitHub (May 15, 2023):

All the proposed usecases could imo be solved by using the existing JINJA_FILTERS setting to provide custom filters for the template rendering. And instead of this FR, it might be an idea to explore if it would make sense to add a way to get other querysets, for example by importing all the netbox models and adding them to the jinja context, kinda like we do with nbshell.

But you can't implement other querysets with JINJA_FILTERS, allright ?

@jonasnieberle commented on GitHub (May 15, 2023): > All the proposed usecases could imo be solved by using the existing JINJA_FILTERS setting to provide custom filters for the template rendering. And instead of this FR, it might be an idea to explore if it would make sense to add a way to get other querysets, for example by importing all the netbox models and adding them to the jinja context, kinda like we do with nbshell. But you can't implement other querysets with JINJA_FILTERS, allright ?
adam commented 2025-12-29 20:31:49 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (May 15, 2023):

But you can't implement other querysets with JINJA_FILTERS, allright ?

Why not?

In configuration.py:

def get_some_stuff(value):
    from ipam.models import VLAN

    return VLAN.objects.filter(name=value)

JINJA2_FILTERS = {
    "get_some_stuff": get_some_stuff
}

Configuration template:

{% for vlan in "Data"|get_some_stuff %}
{{ vlan.vid }} - {{ vlan.site.name }}
{% endfor %}

Rendered:

image

@kkthxbye-code commented on GitHub (May 15, 2023): > But you can't implement other querysets with JINJA_FILTERS, allright ? Why not? In configuration.py: ```python def get_some_stuff(value): from ipam.models import VLAN return VLAN.objects.filter(name=value) JINJA2_FILTERS = { "get_some_stuff": get_some_stuff } ``` Configuration template: ```jinja2 {% for vlan in "Data"|get_some_stuff %} {{ vlan.vid }} - {{ vlan.site.name }} {% endfor %} ``` Rendered: ![image](https://github.com/netbox-community/netbox/assets/400797/eee1106e-2fcb-4507-95df-fef9c614f116)
adam commented 2025-12-29 20:31:49 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (May 15, 2023):

@kkthxbye-code yes, this is what I was looking for, this can definitely serve as pre-processing scripts. But, Jinja2 filters are not exposed in a user friendly way by the look of it, it would be good to have a UI section similar to custom scripts/templates/reports to load Jinja filters into Netbox as well as to be able to sync them with remote data sources. That way it will be easier to maintain them.

@dmulyalin commented on GitHub (May 15, 2023): @kkthxbye-code yes, this is what I was looking for, this can definitely serve as pre-processing scripts. But, Jinja2 filters are not exposed in a user friendly way by the look of it, it would be good to have a UI section similar to custom scripts/templates/reports to load Jinja filters into Netbox as well as to be able to sync them with remote data sources. That way it will be easier to maintain them.
adam commented 2025-12-29 20:31:49 +01:00
Author
Owner
Copy Link

@jonasnieberle commented on GitHub (May 15, 2023):

@kkthxbye-code Thank you very much :)

Very cool Feature, I didn't know that this is possible. I think it would be very useful if you add this to the global netbox documentation.

@jonasnieberle commented on GitHub (May 15, 2023): @kkthxbye-code Thank you very much :) Very cool Feature, I didn't know that this is possible. I think it would be very useful if you add this to the global netbox documentation.
adam commented 2025-12-29 20:31:49 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (May 19, 2023):

Finally a good reason came along to learn the ins and out of Jinja2, NetBox 3.5 FTW!

@bitcollector1 commented on GitHub (May 19, 2023): Finally a good reason came along to learn the ins and out of Jinja2, NetBox 3.5 FTW!
adam commented 2025-12-29 20:31:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 25, 2023):

It seems like a solution has been identified to satisfy the cited use case, and the proposal here would need far more detail to be actionable anyway, so I'm going to close this out.

@jeremystretch commented on GitHub (May 25, 2023): It seems like a solution has been identified to satisfy the cited use case, and the proposal here would need _far_ more detail to be actionable anyway, so I'm going to close this out.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: revisions needed type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8057
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?