What is a configuration template?
Overview
A configuration template is a reusable set of parameter values that implements a configuration based on the associated intent type configuration form. The intent type and the configuration form must be created before the template can be created.
You can create a template for each configuration form in each intent type, or create templates for different use cases.
Templates can be fixed or flexible. A fixed template has preset or default values for all parameters. A flexible template includes parameters that can be changed by the operator at deployment time.
Note: Validation of parameters is performed by the NSP when a template is deployed. However, for MTU in particular, non-numerical values cannot be detected by NSP due to an HTML5 behavior.
You can deploy a configuration template from the configuration templates list by clicking (Table row actions), Deploy to Network, or from the deployments list, see How do I create a logical configuration deployment? and How do I create a logical configuration deployment?.
NSP supports up to 20 000 deployments per configuration template.
Parameters
In NSP you can create configuration templates for physical configuration such as card or port configuration, or logical configuration such as QoS, LAGs, and routing policy configurations. Configuration templates are based on configuration intent types. The template inherits some properties defined in the intent type, and others are defined as part of template configuration.
The following table shows the Configuration Template parameters.
Parameter |
Predefined values |
Notes |
---|---|---|
Name |
— |
— |
Description |
— |
If no description has been configured, the Description column displays a dash. The Description column can only be filtered on configured contents. |
Life Cycle |
draft |
The template can be edited but cannot be deployed to the network. |
released |
The template is active. It can be used to deploy configuration to the network. The template cannot be edited or deleted. The status of the template cannot be changed to draft if it has been deployed. | |
obsolete |
The template is inactive and cannot be used to deploy new configurations to the network, but maintains existing configuration instances. | |
Intent Type |
— |
The configuration intent type the template is based on |
Intent Type version |
— |
The version number of the intent type |
Config Form |
— |
The intent type schema form the template is using. The intent type can have one or more schema forms: a template incorporates one form. |
Config Form State |
Up-to-date |
The config form in use by the template matches the schema form in the intent type. |
Outdated |
The config form in use by the template is no longer aligned with the intent type as a result of an intent type update. Operational actions, such as audits, will be performed against the previous version, not the updated version. The template can be cloned with the new values to create a copy of the template that incorporates the new schema form. | |
Detached |
The schema form used to create this template is deleted or otherwise unusable by the template. The template can still be audited or aligned, but it cannot be cloned, and new deployments cannot be created, including by migration. | |
Processing |
An update to the config form state is ongoing. | |
Role |
Physical |
The target is a physical object such as a port. |
Logical |
The target is a configured object such as QoS. | |
Category 1 |
— |
The type of physical or logical object being configured. |
Device Scope 1 |
SROS Model |
The template is intended for model driven SR OS devices. |
SROS Classic |
The template is intended for classically managed SR OS devices. | |
SROS Classic and Model |
The template can be used for both classic and model driven SR OS devices. | |
Wavence |
The template is intended for Wavence devices. | |
Third Party |
The template is intended for non-Nokia NEs. | |
All |
The template can be used for any device or management type. | |
Flexible |
True |
A flexible template includes parameters that can be changed by the operator at deployment time. |
False |
If all parameters are read only and have default values, the Flexible parameter is set to False. | |
Last Updated |
— |
The date and time of the most recent modification or operation performed. |
Notes:
Template options
Select a template and click (Template Details) to view information about the template.
From the (Table row actions) menu, you can:
-
If the template Life Cycle status is draft or obsolete, it can be opened for editing from the Table row actions menu. If it is in released status, a read-only View page can be opened.
-
Delete the template. Note: the template cannot be deleted if the Life Cycle status is released.
-
Open the template intent type in Network Intents to make any changes required
Attention: Be cautious when invoking bulk actions at the template level with many thousands of configuration instances as this may take many hours to complete.
Differences between classic NEs and model-driven NEs
If you are using Nokia predefined intent types audits will behave differently between classic SR OS and MD SR OS NEs.
In the case of classic SR OS targets, only those attributes defined in the associated configuration form and with a user entered value will be audited. In the case of MD SR OS targets, all attributes in the target configuration tree are audited and attributes not even in the intent type YANG tree are checked.
For example, if the deployment has two targets:
-
with classic SR OS NEs: the configured values of the user entered attributes on each target are checked to verify whether they match the configuration form. The alignment status is based on this check.
-
with MD SR OS NEs: the values of all attributes on each target are checked to verify whether they match the configuration form and each other. The alignment status is based on matching both the configuration form and the other target.
Alignments also behave differently between classic NEs and MD NEs. For MD NEs, an alignment is marked misaligned if the NE is unreachable. For classic NEs, the alignment operation checks the configuration in the NFM-P database. If the database matches the deployment configuration, the status will be aligned, regardless of the NE’s reachability.