Support complex Device Config Renders by enabling custom code extensions (e.g. plugins) to change the queryset used to get objects

[sweston99]

What:
This request and use case is specific to the implementation of class DeviceRenderConfigView. It would be helpful to be able to specify Models other than Device that are used to render the Device configuration, such as proxy models that have methods that can calculate/generate the required additional data.

Why:
Complex device configurations can depend on data that is stored outside of the Device instance. For example, BGP configurations require specifying the IP address of a neighbouring interface, or the loopback IP of a neighbouring device. Although this data could possibly be stored in a local config context for the device, it would be difficult to identify all of the conditions when this would need to be re-generated prior to any request to render the device configuration. If any of those conditions were missed (such as changing a neighbour loopback IP), the local context data would be wrong as well as the resulting rendered config.

I currently solve this problem by using an extended proxy Device model with the additional required methods, create an additional tabbed Device view where I use a new View that can determine the appropriate proxy model to use and then I generate the config. However, that means that the NetBox Render Config tab does not work as the Device model does not have methods that the jinja2 templates are calling. Also, the API call to render-config will fail as well until I duplicate the rest of the render-config functionality. If I could specify the Model to use to retrieve the object, I could keep using the existing NetBox Device Render code.

Possible way to implement:

• create a new signal called get_queryset that is called in DeviceRenderConfigView that lets signal receivers specify the queryset that should be used by get_object(), for example, by device role; although I don't think it is common, Django signals do allow for signal receivers to return values to be evaluated by the sender
• DeviceRenderConfigView could check the recommended queryset model to ensure that it is an instance of Device to minimize the chance of breaking existing functionality
• if it's ok, set DeviceRenderConfigView.queryset = recommended queryset, then proceed with calling get_object()

Reason for opening this in discussion:
From the docs: https://docs.netbox.dev/en/stable/plugins/
Plugins are packaged Django apps that can be installed alongside NetBox to provide custom functionality not present in the core application. Plugins can introduce their own models and views, but cannot interfere with existing components. A NetBox user may opt to install plugins provided by the community or build his or her own.

Q: Is this considered interfering with existing components? Is the check for the recommended queryset/model being an extension of Device cover off the concern here?

We expect to see this use case over and over as device configs are so dependent on neighbour attributes.

thx.

[sweston99]

Change to the initial suggestion on how to solve:

Possible way to implement:

• create a new signal called modify_instance or possibly alter_object. This is intended to do the same thing as the alter_object() view hook, but still keep using existing Device urls, views, etc. hence the reason for using a signal
• in DeviceRenderConfigView, call get_object() using the Device model
• call the signal receivers with the Device instance that lets signal receivers alter the instance that is used by DeviceRenderConfigView. For example a receiver could examine the Device role attribute and return a proxy model instance
• DeviceRenderConfigView could check the recommended instance to ensure that it is an instance of Device to minimize the chance of breaking existing functionality; if it's ok, continue with DeviceRenderConfigView.get()

[pl0xym0r]

If I understand your need :

For example, BGP configurations require specifying the IP address of a neighbouring interface, or the loopback IP of a neighbouring device. Although this data could possibly be stored in a local config context for the device,

You'd like to access data from other objects than device in your config template? Linked or not with your device

[sweston99]

yes, that's correct.

[pl0xym0r]

You can access the whole netbox object database simply through ORM into jinja by using

{{ app_name.model_name.objects.get(id=x) }}

examples for bgp plugin:

{% for session in netbox_bgp.BGPSession.objects.filter(device=device) %}
session {{ session.name }}
{% endfor %}

For IP address it could look like
{{ ipam.IPAddress.objects.all() }}

For interfaces : #15528

Just use the model of the objects + get/filter (+ filter plugins if needed to treat your data) to find your data
Sometimes Objects come with usefull functions, check them too ( {{ device.get_config_context() }}, get_children, ... )

[sweston99]

Wow, thank you very much. That is so helpful. I'm pretty sure this will cover everything I need.

This discussion can be closed.