Expose more objects in the configuration rendering feature #8166

@jeremystretch commented on GitHub (Jun 6, 2023):

Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g.

{% for rt in RouteTarget.objects.all() %}

This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while.

We may also want to consider namespacing the models in some fashion, so that generic models like Device and Site don't conflict with user-provided context variables. (It may also be necessary to avoid naming collisions among core and plugin models.)

@jeremystretch commented on GitHub (Jun 6, 2023): Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g. ``` {% for rt in RouteTarget.objects.all() %} ``` This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while. We may also want to consider namespacing the models in some fashion, so that generic models like `Device` and `Site` don't conflict with user-provided context variables. (It may also be necessary to avoid naming collisions among core and plugin models.)

adam commented

@MajesticFalcon commented on GitHub (Jun 6, 2023):

Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g.
{% for rt in RouteTarget.objects.all() %}
This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while.

We may also want to consider namespacing the models in some fashion, so that generic models like Device and Site don't conflict with user-provided context variables. (It may also be necessary to avoid naming collisions among core and plugin models.)

Sounds good. In the meantime, is there a different method I could use to get the RT info usable inside the configuration rendering? The configuration snippet you provided would be great, but I suspect/hope there is a round-a-bout way to get the same information through the device object?

@MajesticFalcon commented on GitHub (Jun 6, 2023): > Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g. > > ``` > {% for rt in RouteTarget.objects.all() %} > ``` > > This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while. > > We may also want to consider namespacing the models in some fashion, so that generic models like `Device` and `Site` don't conflict with user-provided context variables. (It may also be necessary to avoid naming collisions among core and plugin models.) Sounds good. In the meantime, is there a different method I could use to get the RT info usable inside the configuration rendering? The configuration snippet you provided would be great, but I suspect/hope there is a round-a-bout way to get the same information through the device object?

adam commented

@DanSheps commented on GitHub (Jun 6, 2023):

I am assuming this is for L2VPNs?

Two ways:

Iterate interfaces, iterate vlans, iterate l2vpn terminations, iterate route targets
Iterate interfaces, iterate l2vpn terminations, iterate route target

This is because l2vpns can be attached to both a single interface or a vlan. There is no direct way from devices itself, unfortunately.

@DanSheps commented on GitHub (Jun 6, 2023): I am assuming this is for L2VPNs? Two ways: * Iterate interfaces, iterate vlans, iterate l2vpn terminations, iterate route targets * Iterate interfaces, iterate l2vpn terminations, iterate route target This is because l2vpns can be attached to both a single interface or a vlan. There is no direct way from devices itself, unfortunately.

adam commented

@MajesticFalcon commented on GitHub (Jun 6, 2023):

@DanSheps, thank you! I just saw your Slack message as well. Apologies for the duplicate work. I'm going to leave this open for now in hopes to get some more discussion.

@MajesticFalcon commented on GitHub (Jun 6, 2023): @DanSheps, thank you! I just saw your Slack message as well. Apologies for the duplicate work. I'm going to leave this open for now in hopes to get some more discussion.

adam commented

@ITJamie commented on GitHub (Jun 7, 2023):

maybe it would be worth passing in a dummy object which had references to all the classes. eg a "netbox" object or similar, that way it would guarantee no confusion when it comes to the existing device object.
context render would look something like:

{% for rt in netbox.RouteTarget.objects.all() %}

@ITJamie commented on GitHub (Jun 7, 2023): maybe it would be worth passing in a dummy object which had references to all the classes. eg a "netbox" object or similar, that way it would guarantee no confusion when it comes to the existing device object. context render would look something like: ``` {% for rt in netbox.RouteTarget.objects.all() %} ```

adam commented

@DanSheps commented on GitHub (Jun 7, 2023):

I like that idea, and honestly I thought of roughly the same. We would have to find a way to capture all the plugins that could be required too however.

@DanSheps commented on GitHub (Jun 7, 2023): I like that idea, and honestly I thought of roughly the same. We would have to find a way to capture all the plugins that could be required too however.

adam commented

@ITJamie commented on GitHub (Jun 12, 2023):

Maybe "netbox.plugins.classname" work for plugins. It could act as a safety wrapper too incase a context was using a pluginclass that got removed and safely error out/log? (Its actually kind of important that we make sure that works, otherwise some important config could be missing in a deployment config...)

@ITJamie commented on GitHub (Jun 12, 2023): Maybe "netbox.plugins.classname" work for plugins. It could act as a safety wrapper too incase a context was using a pluginclass that got removed and safely error out/log? (Its actually kind of important that we make sure that works, otherwise some important config could be missing in a deployment config...)

adam commented

@do9xe commented on GitHub (Jun 13, 2023):

Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g.
{% for rt in RouteTarget.objects.all() %}
This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while.

I was also just looking into how I could get all the VLANs for a device. In my case I'd like to loop through all the VLANs that match the device and create them in the configuration. If you use dynamic VLAN assignment through 802.1X most devices need the VLANs created before they can be dynamically assigned to a port. Also they don't show in the running-config of the device.

@do9xe commented on GitHub (Jun 13, 2023): > Expanded more generally, I think the underlying proposal here is to make NetBox models available directly as context variables when rendering a template. This would enable the template author to do e.g. > > ``` > {% for rt in RouteTarget.objects.all() %} > ``` > > This was a consideration raised during the initial work on the config rendering feature and ultimately punted simply because we weren't sure if it made sense at the time. I don't think there's anything necessarily precluding us from adding this, but would like to leave this open for discussion for a while. I was also just looking into how I could get all the VLANs for a device. In my case I'd like to loop through all the VLANs that match the device and create them in the configuration. If you use dynamic VLAN assignment through 802.1X most devices need the VLANs created before they can be dynamically assigned to a port. Also they don't show in the running-config of the device.

adam commented

@abhi1693 commented on GitHub (Aug 4, 2023):

Here is a rough draft that provides the models in the context data. However, for this to work, I have renamed device to object

diff --git a/netbox/dcim/views.py b/netbox/dcim/views.py
index 5b93e5f0b..89964c376 100644
--- a/netbox/dcim/views.py
+++ b/netbox/dcim/views.py
@@ -1,5 +1,6 @@
 import traceback
 
+from django.apps import apps
 from django.contrib import messages
 from django.contrib.contenttypes.models import ContentType
 from django.core.paginator import EmptyPage, PageNotAnInteger
@@ -19,6 +20,7 @@ from circuits.models import Circuit, CircuitTermination
 from extras.views import ObjectConfigContextView
 from ipam.models import ASN, IPAddress, Prefix, VLAN, VLANGroup
 from ipam.tables import InterfaceVLANTable
+from netbox.registry import registry
 from netbox.views import generic
 from tenancy.views import ObjectContactsView
 from utilities.forms import ConfirmationForm
@@ -2078,7 +2080,12 @@ class DeviceRenderConfigView(generic.ObjectView):
     def get_extra_context(self, request, instance):
         # Compile context data
         context_data = instance.get_config_context()
-        context_data.update({'device': instance})
+        context_data.update({'object': instance})
+        app_ns = registry['model_features']['custom_fields'].keys()
+        for app in app_ns:
+            models = apps.get_app_config(app).get_models()
+            for model in models:
+                context_data.update({model._meta.model_name: model})
 
         # Render the config template
         rendered_config = None

@abhi1693 commented on GitHub (Aug 4, 2023): Here is a rough draft that provides the models in the context data. However, for this to work, I have renamed `device` to `object` ``` diff --git a/netbox/dcim/views.py b/netbox/dcim/views.py index 5b93e5f0b..89964c376 100644 --- a/netbox/dcim/views.py +++ b/netbox/dcim/views.py @@ -1,5 +1,6 @@ import traceback +from django.apps import apps from django.contrib import messages from django.contrib.contenttypes.models import ContentType from django.core.paginator import EmptyPage, PageNotAnInteger @@ -19,6 +20,7 @@ from circuits.models import Circuit, CircuitTermination from extras.views import ObjectConfigContextView from ipam.models import ASN, IPAddress, Prefix, VLAN, VLANGroup from ipam.tables import InterfaceVLANTable +from netbox.registry import registry from netbox.views import generic from tenancy.views import ObjectContactsView from utilities.forms import ConfirmationForm @@ -2078,7 +2080,12 @@ class DeviceRenderConfigView(generic.ObjectView): def get_extra_context(self, request, instance): # Compile context data context_data = instance.get_config_context() - context_data.update({'device': instance}) + context_data.update({'object': instance}) + app_ns = registry['model_features']['custom_fields'].keys() + for app in app_ns: + models = apps.get_app_config(app).get_models() + for model in models: + context_data.update({model._meta.model_name: model}) # Render the config template rendered_config = None ``` ![image](https://github.com/netbox-community/netbox/assets/5083532/e6a985b8-e728-4a67-8051-540c502ee305)

adam commented

@jeremystretch commented on GitHub (Aug 4, 2023):

IMO it would make sense to expose the models with their native names (e.g. ConsolePort rather than console_port) in the template context.

@jeremystretch commented on GitHub (Aug 4, 2023): IMO it would make sense to expose the models with their native names (e.g. `ConsolePort` rather than `console_port`) in the template context.

adam commented

@jeremystretch commented on GitHub (Aug 7, 2023):

Thinking about this further, we probably want to incorporate the application name space in the context, to avoid potential future naming conflicts. For example, suppose a plugin introduces its own Site model, which would conflict with the native model.

We could namespace the models to avoid this, e.g. dcim.Site instead of Site. It breaks from convention a bit but does so to provide a minimally inconvenient solution for potential naming conflicts.

@jeremystretch commented on GitHub (Aug 7, 2023): Thinking about this further, we probably want to incorporate the application name space in the context, to avoid potential future naming conflicts. For example, suppose a plugin introduces its own Site model, which would conflict with the native model. We could namespace the models to avoid this, e.g. `dcim.Site` instead of `Site`. It breaks from convention a bit but does so to provide a minimally inconvenient solution for potential naming conflicts.

adam commented

@abhi1693 commented on GitHub (Aug 7, 2023):

Would you want a flat structure like dcim.Site, dcim.Rack or a grouped structure like {dcim: {Site: ..., Rack: ...}...}?

@abhi1693 commented on GitHub (Aug 7, 2023): Would you want a flat structure like `dcim.Site`, `dcim.Rack` or a grouped structure like `{dcim: {Site: ..., Rack: ...}...}`?

adam commented

@DanSheps commented on GitHub (Aug 8, 2023):

I am for the namespacing. Seems like a good plan, yes it does deviate but I think it will prevent future isssues.

@DanSheps commented on GitHub (Aug 8, 2023): I am for the namespacing. Seems like a good plan, yes it does deviate but I think it will prevent future isssues.

adam commented

@jeremystretch commented on GitHub (Aug 8, 2023):

@abhi1693 I think it would need to be nested, in order to access e.g. dcim.Site.objects.all() within a Jinja2 template.

@jeremystretch commented on GitHub (Aug 8, 2023): @abhi1693 I think it would need to be nested, in order to access e.g. `dcim.Site.objects.all()` within a Jinja2 template.

adam commented