Closes #11559: Implement config template rendering (#11769)

* WIP

* Add config_template field to Device

* Pre-fetch referenced templates

* Correct up_to_date callable

* Add config_template FK to Device

* Update & merge migrations

* Add config_template FK to Platform

* Add tagging support for ConfigTemplate

* Catch exceptions when rendering device templates in UI

* Refactor ConfigTemplate.render()

* Add support for returning plain text content

* Add ConfigTemplate model documentation

* Add feature documentation for config rendering

docs/features/configuration-rendering.md

@@ -0,0 +1,38 @@
+# Configuration Rendering
+
+One of the critical aspects of operating a network is ensuring that every network node is configured correctly. By leveraging configuration templates and [context data](./context-data.md), NetBox can render complete configuration files for each device on your network.
+
+```mermaid
+flowchart TD
+    ConfigContext & ConfigTemplate --> Config{{Rendered configuration}}
+
+click ConfigContext "../../models/extras/configcontext/"
+click ConfigTemplate "../../models/extras/configtemplate/"
+```
+
+## Configuration Templates
+
+Configuration templates are written in the [Jinja2 templating language](https://jinja.palletsprojects.com/), and may be automatically populated from remote data sources. Context data is applied to a template during rendering to output a complete configuration file. Below is an example template.
+
+```jinja2
+{% extends 'base.j2' %}
+
+{% block content %}
+    system {
+        host-name {{ device.name }};
+        domain-name example.com;
+        time-zone UTC;
+        authentication-order [ password radius ];
+        ntp {
+            {% for server in ntp_servers %}
+                server {{ server }};
+            {% endfor %}
+        }
+    }
+    {% for interface in device.interfaces.all() %}
+        {% include 'common/interface.j2' %}
+    {% endfor %}
+{% endblock %}
+```
+
+When rendered for a specific NetBox device, the template's `device` variable will be populated with the device instance, and `ntp_servers` will be pulled from the device's available context data. The resulting output will be a valid configuration segment that can be applied directly to a compatible network device.

docs/features/context-data.md

@@ -11,6 +11,8 @@ Configuration context data (or "config contexts" for short) is a powerful featur
 }
 ```
 
+Context data can be consumed by remote API clients, or it can be employed natively to render [configuration templates](./configuration-rendering.md).
+
 Config contexts can be computed for objects based on the following criteria:
 
 | Type          | Devices          | Virtual Machines |

docs/models/dcim/device.md

@@ -72,6 +72,10 @@ The device's operational status.
 
 A device may be associated with a particular [platform](./platform.md) to indicate its operating system. Note that only platforms assigned to the associated manufacturer (or to no manufacturer) will be available for selection.
 
+### Configuration Template
+
+The [configuration template](../extras/configtemplate.md) from which the configuration for this device can be rendered. If set, this will override any config template referenced by the device's role or platform.
+
 ### Primary IPv4 & IPv6 Addresses
 
 Each device may designate one primary IPv4 address and/or one primary IPv6 address for management purposes.

docs/models/dcim/devicerole.md

@@ -19,3 +19,7 @@ The color used when displaying the role in the NetBox UI.
 ### VM Role
 
 If selected, this role may be assigned to [virtual machines](../virtualization/virtualmachine.md)
+
+### Configuration Template
+
+The default [configuration template](../extras/configtemplate.md) for devices assigned to this role.

docs/models/dcim/platform.md

@@ -22,6 +22,10 @@ A unique URL-friendly identifier. (This value can be used for filtering.)
 
 If designated, this platform will be available for use only to devices assigned to this [manufacturer](./manufacturer.md). This can be handy e.g. for limiting network operating systems to use on hardware produced by the relevant vendor. However, it should not be used when defining general-purpose software platforms.
 
+### Configuration Template
+
+The default [configuration template](../extras/configtemplate.md) for devices assigned to this platform.
+
 ### NAPALM Driver
 
 The [NAPALM driver](https://napalm.readthedocs.io/en/latest/support/index.html) associated with this platform.

docs/models/extras/configtemplate.md

@@ -0,0 +1,29 @@
+# Configuration Templates
+
+Configuration templates can be used to render [devices](../dcim/device.md) configurations from [context data](../../features/context-data.md). Templates are written in the [Jinja2 language](https://jinja.palletsprojects.com/) and can be associated with devices roles, platforms, and/or individual devices.
+
+Context data is made available to [devices](../dcim/device.md) and/or [virtual machines](../virtualization/virtualmachine.md) based on their relationships to other objects in NetBox. For example, context data can be associated only with devices assigned to a particular site, or only to virtual machines in a certain cluster.
+
+See the [configuration rendering documentation](../../features/configuration-rendering.md) for more information.
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Weight
+
+A numeric value which influences the order in which context data is merged. Contexts with a lower weight are merged before those with a higher weight.
+
+### Data File
+
+Template code may optionally be sourced from a remote [data file](../core/datafile.md), which is synchronized from a remote data source. When designating a data file, there is no need to specify template code: It will be populated automatically from the data file.
+
+### Template Code
+
+Jinja2 template code, if being defined locally rather than replicated from a data file.
+
+### Environment Parameters
+
+A dictionary of any additional parameters to pass when instantiating the [Jinja2 environment](https://jinja.palletsprojects.com/en/3.1.x/api/#jinja2.Environment). Jinja2 supports various optional parameters which can be used to modify its default behavior.