What is a configuration intent type?
Overview
NSP uses intent types to build configuration templates, which are then used to build configurations. Users can create custom intent types or import predefined intent types into NSP. Nokia provided intent types are available from the Nokia software support download site. Nokia recommends using predefined intent types where applicable.
When an intent type is imported to NSP, it is available in Network Intents, Intent Types. To be used as a configuration intent type, the intent type must be imported to Device Management, Configuration Intent Types.
Note:
-
The intent type must have the InfrastructureConfiguration label to be used as a configuration intent type.
-
The first container name in the intent type YANG must be the same as the module name.
-
View files for predefined intent types can be added or edited in the Network Intents, Intent Types view; see “How do I add or change a View file?” in the NSP Network Automation Guide. No other changes can be made to predefined intent types.
The configuration intent type includes one or more configuration forms, called views or schema forms in Network Intents. Configuration forms define the parameters that will be set when the configuration template is deployed. The configuration form can provide a parameter value or leave the value blank, to be set during deployment. If a parameter is not included in the configuration form, deploying the configuration template will not set that parameter on the target.
The use of multiple configuration forms allows one intent type to be used to create multiple configuration templates with different configuration parameters and different parameter values.
For example, an intent type called access port could include a default configuration form with ten blank parameters, and a simple configuration form with two parameters with set values. All configuration templates created from this intent type will configure access ports. However, you can create multiple templates, for example, one to set the two parameters to predefined values, and one or more to set the ten parameters to values of your choosing.
ICM descriptor resource file
The configuration intent type also includes a resource file, icm_descriptor.json, that provides parameters for the configuration templates created from the intent type. For intent types with the logical role, this resource file also defines whether the template can be deployed to multiple targets in one deployment, and whether it can be deployed with other templates in one deployment.
The following table describes attributes that can be provided in the icm_descriptor.json file.
Attribute |
Mandatory |
Default value |
Available values |
Description |
---|---|---|---|---|
category |
Yes |
— |
Any string, such as Port, Card, or QoS |
The category is used primarily for logical grouping of the templates created using the intent type. |
role |
Yes |
— |
physical logical |
The physical role refers to physical configurations such as ports, while logical refers to logical configurations, such as QoS. |
description |
No |
— |
Any string |
— |
device-scope |
Yes |
— |
mdm classic mdm-and-classic wavence third-party all |
The device scope declares the device types the templates are intended for. |
select-template 1 |
No |
multiple for logical role single for physical role |
multiple single |
This parameter declares whether the template can be deployed along with other templates in the same deployment. |
select-target |
No |
multiple |
multiple single |
This parameter declares whether the user will be able to select single or multiple targets when the template is deployed. |
target-xpath |
No |
NEs for logical role For physical role, the default varies based on category. |
Any valid network inventory x-path |
The x-path is used to fetch the list of targets during deployment creation. |
targets |
No |
— |
targets = [ {"NSP", "NSP"}] |
The targets parameter allows a target to be provided that differs from the role defaults. For example, for NGE configuration, the target is NSP. The parameter is configured as a key-value pair. |
Notes:
If the targets parameter is set in the descriptor file, the select-template parameter defaults to single.
See “What are the components of an intent type?” in the NSP Network Automation Guide for more information about configuring intent types, and the Intent Based Networking Framework and Input Forms tutorials on the Network Developer Portal for developer information, including use of resource files.
Intent type configuration form
You can update an intent type to change one of the existing schema forms or add a new schema form. For details, see the viewConfig Forms tutorial on the Network Developer Portal.
If templates were created using the old schema form of the intent type, they will have a Config Form State of Outdated after the intent type is updated and re-imported. If a required schema form has been deleted in NSP, the Config Form State is updated to Detached. Audit or align operations on an outdated or detached template will be performed using the previous values.
The only available operations for a detached template are audit and align: no new deployments can be created, and deployments cannot be migrated to the template.
Intent type details
Select an intent type and click (Intent Type Details) to view information about the intent type.
From the (Table row actions) menu, you can:
-
Open the intent type in Network Intents to make any changes required
-
Remove the intent type from the list of configuration intent types, if it is not in use by a template
Changes to views are automatically imported.
Perform a re-import for any of the following.
Re-importing intent types
If a view or schema form in an intent type has been added, deleted, or edited in the Network Intents, Intent Types view, it is automatically updated in the Device Management configuration views.
If other changes have been made to the intent type, for example, a change to the YANG, the intent type is not automatically synched. You need to re-import the intent type to see the changes.
Important! The only changes that are automatically synched are changes made to the view files.
If a change has been made in Network Intents other than a change to a view, or if a change has been made to the intent type code or files outside NSP, for example, in a text editor, you must re-import the intent type to access the changes.