-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose more objects in the configuration rendering feature #12814
Comments
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.
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 |
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? |
I am assuming this is for L2VPNs? Two ways:
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, 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. |
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.
|
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. |
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...) |
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. |
Here is a rough draft that provides the models in the context data. However, for this to work, I have renamed
|
IMO it would make sense to expose the models with their native names (e.g. |
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. |
Would you want a flat structure like |
I am for the namespacing. Seems like a good plan, yes it does deviate but I think it will prevent future isssues. |
@abhi1693 I think it would need to be nested, in order to access e.g. |
* exposes all models in device context data #12814 * added app namespaces to the context data * revert object to device in context data * moved context to render method of ConfigTemplate * removed print * Include only registered models; permit passed context data to overwrite apps --------- Co-authored-by: Jeremy Stretch <jstretch@netboxlabs.com>
Please consider including the ipam models as well: ipam.Vlans.objects.all() Traceback:
|
The model is Please open a discussion for any further assistance with this. |
NetBox version
v3.5.3
Feature type
Change to existing functionality
Proposed functionality
Configuration rendering should expose the route-targets so more advanced configurations can be generated.
Use case
Unless I am missing something, currently, the implementation of configuration rendering seems to only provide access to the "device" object. Technically, you can loop through the device.interfaces.all() and create a new array of L2vpn terminations, however, I don't believe you can get the route-targets using this method.
Database changes
None.
External dependencies
None.
The text was updated successfully, but these errors were encountered: