What are the components of an intent type?
Intent type components
An intent type provides the logic for the creation of an intent, and for the execution of that intent. When a user creates an intent from the intent type, a Create Intent form launches requesting the required inputs. The Target and YANG model components define the form. The Script and Resources components provide the logic required to realize the intent.
For detailed information about intent type design, see the intent types tutorial on the Network Developer Portal.
An intent type consists of the following components. The components appear as pages in the Create and Edit forms.
General
The General page includes the following panels.
General
The General panel shows the basic information about the intent type, for example, the name, labels and lifecycle state.
The Live state retrieval check box dictates whether intent state attributes will be updated in the intent details on demand or when the intent is synchronized. Enable the check box to update state attributes on demand.
The Composite check box indicates a composite intent type.
The Build field displays the build number of the intent type from the intent type code. For Nokia-created intent types, the format is release_x.y.z where the numbers x.y.z are used for version control. The x number is the Version parameter in NSP. For example, if you install an intent type with the build number 22.9_2.1.1, the intent type version will be 2, regardless of whether you have a version 1 in your system.
The Labels field lists the labels to be applied to the intent type. Labels are used to filter and group intent types. An intent type can have one or multiple labels.
If an intent type is compliant with a set of format requirements, such as Service Management, a label must be used to indicate what the intent type is configured for. For an intent type to be imported by Service Management, it must have a ServiceFulfillment label.
Policy
The Policy panel indicates the priority of the intent type and the targeted device. Policy configuration in the intent type helps NSP administer mass operations correctly.
The priority is used by NSP to determine the order of execution. An intent belonging to an intent type with a smaller priority number is executed by NSP before an intent belonging to an intent type with a bigger priority number. Setting the priority can ensure, for example, that port configurations are performed before the configuration of services that will require the ports.
The targeted device is used to allocate jobs so that only one job is executed at one time per device. This prevents delays and job timeouts due to a job attempting to run on a resource that is blocked by another job.
The targeted device is defined in JSON format using intent-type, targets, yang, inherit, and function names.
It can be defined in the following ways:
-
target component of the current intent:
"targetted-device": [ {
"target-component": "device-name"
}]
-
target component of a dependent intent:
"targetted-device": [ {
"intent-type": "l2-infra", (empty or omitted indicates this intent type)
"target-component": "device-name"
}]
-
leaf of the YANG of the current intent:
"targetted-device": [ {
"intent-type": "l2-infra", (empty or omitted indicates this intent type)
"yang": "fiber:fiber/pon-port/device-name"
}]
-
same devices as a dependent intent:
"targetted-device": [ {
"inherit": "true",
"intent-type": "device-fx"
}]
-
in special cases, we can use special logic in JavaScript:
"targetted-device": [ {
"function": "getTargettedDevices"
}]
Migration
The Migration panel is displayed for intent types with a version number greater than 1. The migration table shows the configured migration and rollback paths between versions of the intent type.
Target
The target attribute of the intent type is used to uniquely identify any intent created from the intent type. The definition must be in JSON format.
The target attribute is made up of one or more target components.
All attributes are optional: the only requirement is that the intent is uniquely defined.
When an intent is created, the target components are displayed as input fields in the intent creation dialog. NSP uses the user inputs to create the target value.
The following table describes the target attributes.
The following sample shows the structure of a target component definition.
Sample target
The following sample creates a target component:
{
"target-component": [
{
"i18n-text": "Service Name",
"name": "service-name",
"pattern": "[A-Za-z0-9_]{1,}",
"value-type": "STRING",
"order": 1
}
]
}
You can include more than one target component, if needed. The target value separates the two components with a hash; for example, service#port.
The sample target component is displayed in the form as shown in Figure 4-1, Form preview with Sample target and Sample YANG. The user input becomes the target attribute.
YANG
The YANG panel provides an abstraction for the instance of the intent type.
The following types of arguments are supported:
-
Configuration arguments: attributes where the user needs to provide a value
-
State arguments: attributes where the intent type reports relevant state information
The YANG model must extend the Nokia IBN YANG definition. The arguments must use the ibn:configuration container.
Script
The Script panel contains the realization logic of the intent type. This panel contains the programming required for the intent configuration to be performed.
The script contains an intentObject and needs to implement some predefined functions. When a user triggers an action, the predefined functions are called by the framework to fulfill the task. These methods have implementation specific to an Intent type.
The following functions are optional.
-
Validate runs at the time an intent is synchronized, either at or after intent creation. If the intent input fails the validation condition, the intent cannot be synchronized.
-
Reconcile is the opposite of a synchronize function. It will pull the configuration from the associated object and update the intent configurations to match it.
The following sample shows a basic script structure.
Sample script
var RuntimeException = Java.type('java.lang.RuntimeException');var prefixToNsMap = {"ibn" : "http://www.nokia.com/management-solutions/ibn",
"nc" : "urn:ietf:params:xml:ns:netconf:base:1.0",
"device-manager" : "http://www.nokia.com/management-solutions/anv",
};
var nsToModule = {"http://www.nokia.com/management-solutions/anv-device-holders" : "anv-device-holders"
};
function synchronize(input) {var target = input.getTarget();
var config = input.getIntentConfiguration();
var topology = input.getCurrentTopology();
//Retrieve the network state, it exists in the input argument.
var networkState = input.getNetworkState().name();
var customNetworkState = input.getCustomRequiredNetworkState();
logger.info("######### NETWORK STATE "+ networkState);//If the network state is 'custom' then we must look in the customRequiredNetworkState property to get the actual state
if(networkState === 'custom'){ logger.info("######### CUSTOM NETWORK STATE "+ customNetworkState);result.setSuccess(true);
return result;
}
function audit(input) {var report = auditFactory.createAuditReport(null, null);
// Code to audit goes here
return report
}
function validate(syncInput) { var contextualErrorJsonObj = {};var intentConfig = syncInput.getJsonIntentConfiguration();
// Code to validation here. Add errors to contextualErrorJsonObj.
// contextualErrorJsonObj["attribute"] = "Attribute must be set";
if (Object.keys(contextualErrorJsonObj).length !== 0) {utilityService.throwContextErrorException(contextualErrorJsonObj);
}
}
/*
RECONCILE
The return object that is expected from a reconcile is ReconcileOutput
ReconcileOutput POJO defined like below
updatedIntentConfiguration - filled when the intent configuration can be adapted
updatedStateXML - filled when the Intent State can be adapted
alignmentState - filled if intent needs to be aligned state after reconcile
updateDependents - whether dependent intents to be updated
syncDependents - whether dependent intents to be synched
topology - filled if there is change in Topology / Intent Dependency , XtraInfo
*/
function reconcile (input){var reconcileOutput;
var topologyXtraInfo = null;
var topologyXtraInfo = null;
var target = input.getTarget();
var topology = input.getCurrentTopology();
var targettedDevice = input.getTargettedDevices();
var networkState = input.getNetworkState();
var customRNS = input.getCustomRequiredNetworkState();
var intentConfigXml = input.getIntentConfiguration();
//Here we are changing the configuration
var testStringNode = intentConfigXml.getElementsByTagName("test-string").item(0); if(testStringNode.getTextContent() == 'reconcile'){ testStringNode.setTextContent("reconcile");}
var updatedConfig = domUtils.documentToString(intentConfigXml);
if (networkState == "delete") { logger.info("Reconcile intent with input networkState {}", networkState); throw new RuntimeException("Reconcile with required-network-state as 'delete' is not possible");}
if (networkState == "suspend") { logger.info("Reconcile intent with input networkState {}", networkState);return new ReconcileOutput(null, null, "false", false, false, null);
}
//Return for reconcile
return new ReconcileOutput(updatedConfig, null, "true", false, false, null);
}
Resources
The Resources panel shows the list of resource files required to realize the intent. The Resources are a library of files that the intent type can access.
Different intent types that target similar system configurations often use similar logic. The use of resource files allows the common logic pieces to be stored as framework and mapping files, and loaded when the intent runs.
The resource files can be in various formats, for example, YANG, JavaScript, or JSON.
To configure resource libraries, click 
More, Resource Management at the top of any view in the Network Intents path.
For detailed information about resource file creation, see the Network Intents tutorial on the Network Developer Portal.
Form
The form input describes how the Create Intent dialog is displayed when the user creates an intent. The input can be in YAML or JSON format.
NSP implements a schema file to generate and preview the form.
Intent types that are instantiated within Network Intents use the default schema file. Other schemas may be available for intent types used by other applications.
Figure 4-1: Form preview with Sample target and Sample YANG
Views
The Views panel shows the list of view files available to the intent type. View files are used to create the input form the user will see when creating an intent, or when using intent-based configuration in another application.
Nokia-signed intent types, which are installed using Artifacts, cannot be edited except to add, delete or modify Views.
The list of files includes:
-
viewConfig forms: a viewConfig form defines the fields that will appear in the input form and their properties. The viewConfig form is created by a developer.
-
schema forms: the schema form is automatically generated from the viewConfig form. NSP implements the schema form file to create the input form.
-
view.settings files: the view.settings file is automatically generated. It provides a link to the module and container defined in the intent type YANG to identify the YANG entry point.
For detailed information about View file creation, see the ViewConfig forms section of the Network Intents tutorial on the Network Developer Portal.