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.
Role	Logical	The target is a configured object such as QoS.
Category¹	—	The type of physical or logical object being configured.
Device Scope ¹	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.
Flexible	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:

This parameter is defined in the icm_descriptor resource file in the configuration intent type.

Template options

Select a template and click (Template Details) to view information about the template.

From the (Table row actions) menu, you can:

View/Edit the template

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.
View the list of deployments using the template
Migrate deployments to another template
Deploy the template to the network
Associate the template to the network
Audit/Align deployments:
- Audit all config
  
  Audit deployments for configuration drift that may occur over time
- Align config
  
  Realign the network configuration back to the intended and defined configuration
- Align misaligned only
Delete

Delete the template. Note: the template cannot be deleted if the Life Cycle status is released.
Open in Network Intents

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.