Deployments

Overview

Deployments model the communication requests made from the management domain via the NFM-P GUI or OSS to the network. Deployments are created by the NFM-P at system startup and are present in a finite deployment pool to be used to:

• perform actions from the NFM-P to the managed network

• queue configuration requests from GUI and OSS clients

Deployment objects have data about the current state of deployment and can be used to track changed objects and parameters (elements) that need to be sent to the network. When the deployment performs the network change, all data is cleared from the deployment. If the deployment fails, it attempts to redeploy the request based on the deployment policy configuration.

OSS applications that send configuration requests to the network must monitor deployments. When changes are sent to the network, deployments are created, queued, and dispatched to the managed routers. When the deployment is successful, the NFM-P notifies the OSS that the deployment is completed for the request that triggered the deployment. If the deployment fails, an alarm creation or change event is generated and sent using JMS. It is important that OSS applications clear deployments after they are used.

See the following sections for more information:

• Deployment failures in this section for more information about managing deployment failures

• Deployment failure recovery procedures in this section for more information about how to recover from deployment failure, depending on the type of configuration request

• Deployment alarms and events in this section for more information about the deployment alarm format and DeployerEvent

• Chapter 4, Event monitoring using JMS for more information about JMS events

Deployment types

Deployment related methods are found in the generic package and all configuration methods require a specified deployment type, as specified in the <deployer> tag. The deployment type is specified in the xmlApiTypes.xsd file. Deployments specify how and when deployment occurs. The valid values (with numeric equivalents) are:

• immediate (-1) to deploy to the network immediately

• followTransaction (-2) reserved for future use

• postponed (-3) reserved for future use

• ignored (-4) to not deploy to the network, so changes are only added to the database

Synchronous and asynchronous requests

You can configure the following deployment types:

• asynchronous (default)

• synchronous

Synchronous requests

Users can specify synchronous network requests using the <synchronousDeploy> and other tags. These requests are sent by the OSS to the NFM-P server where the request is validated and then saved to the NFM-P database. Subsequently, a deployment is created and queued on the NFM-P server for dispatching to the network. When the deployment has successfully performed the deployment across the network, or when all of the retries specified in the request are completed, the synchronous response is returned and the deployment put back in the pool of available deployments. There may be cases where a deployment causes some objects to be resynchronized from the NE. In these cases, the response is deferred until after the resynchronization has completed.

If there is a failure of all retries, an alarm is raised that contains details of the failed deployment and a failure XML response is sent back containing the failed deployment Id. See Figure 9-2, Database interaction with synchronous network deployment for a synchronous network deployment.

The following figure shows the setting of previously discussed deployment parameters when deleting an object. The parameters &lt;deployRetries&gt; and &lt;deployRetryInterval&gt; may be omitted to use default values.

Figure 15-9: Synchronous deployment request example

<SOAP:Body>

   <generic.GenericObject.deleteInstance xmlns="xmlapi_1.0">

      <deployer>immediate</deployer>

      <synchronousDeploy>true</synchronousDeploy>

      <clearOnDeployFailure>true</clearOnDeployFailure>

      <deployRetries>0</deployRetries>

      <deployRetryInterval>0</deployRetryInterval>

      <distinguishedName>network:10.1.202.93</distinguishedName>

   </generic.GenericObject.deleteInstance>

</SOAP:Body>

Asynchronous requests

Asynchronous requests are sent by the OSS to the NFM-P server where the request is validated and then saved to the NFM-P database. Subsequently, a response from the server is sent back to the OSS. A deployment is created and queued on the NFM-P server for dispatching to the network. When the deployment has successfully performed the deployment across the network, or when all of the retries specified in the request are completed, the deployment is put back in the pool of available deployments.

If there is a failure of all retries, an alarm is raised that contains details of the deployment. See Deployment alarms and events in this section for more information. The default setting is that requests are made asynchronously across the network.

Note: If the OSS is not listening for alarms, it will not know if the deployments was successful, and may have to retrieve deployment information to verify. See Deployment failures in this section for more information.

See Figure 9-3, Database interaction with asynchronous network deployment for an asynchronous network deployment.

The sample synchronous request shown in Figure 15-9, Synchronous deployment request example can be changed to an asynchronous request by changing <synchronousDeploy> to false:

<synchronousDeploy>false</synchronousDeploy>

Deployment failures

In the case of synchronous request failures, the XML API notifies the OSS of the deployment failure in the returned XML response. For asynchronous request failures, the OSS will not receive an XML response about the deployment failure. For both cases, the OSS must subsequently perform procedures for error-recovery.

If the OSS connection is lost or times out before the XML API returns a result to the OSS application, the OSS may not be aware of any subsequent success or failure notifications of the request. Steps must be taken at a later time, either manually or through the OSS, to verify whether the request was successful. If the request was unsuccessful, for example, because of a failed deployment, the OSS must perform procedures for error-recovery.

Error recovery methods

If there is a deployment failure, the failed deployment has more information on the failed state of the deployment for the OSS to retrieve and recover. The following table describes the methods from the generic.GenericObject class that are available to help with recovering from failed deployments.

Table 15-2: Generic methods for error recovery

Filtering can be applied when retrieving information about deployments using the following methods:

• generic.GenericObject.getDeployers

• generic.GenericObject.getDeployer

• generic.GenericObject.getDeployersShallow

The following figure shows an example of filtering on the generic.DeployerInfo class. The filter returns the name of each deployment that fails with an error code of 16, which represents an internal error.

Figure 15-10: Example of filtering based on generic.DeployerInfo

<filter>    

   <and class="generic.DeployerInfo">           

      <equal name="state" value="16" />

      <wildcard value="Default.DeployerBank:depl-%" name="objectFullName" />

   </and>

</filter>

The following figure shows a failed response exception message for a deployment request. When all retries fail, the failure response indicates the failed deployment ID. An alarm is not raised until all retries are attempted. See the XML API SDK Sample Code Navigator for a sample XML request to retrieve deployment information.

Figure 15-11: Failed deployment exception example

<?xml version="1.0" encoding="UTF-8"?>

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">

   <SOAP:Header>

      <header xmlns="xmlapi_1.0">

         <requestID>XML_API_client@n</requestID>

         <requestTime>11-Dec-2006 10:53:48 AM</requestTime>

         <responseTime>11-Dec-2006 10:53:49 AM</responseTime>

      </header>

   </SOAP:Header>

   <SOAP:Body>

      <generic.GenericObject.configureChildInstanceException xmlns="xmlapi_1.0">

         <description> [ app: generic ] [ class: generic.GenericObject ] [ instance: N/A ] [ descr: Operation Failed During Deployment ]

         </description>

         <deployers>

            <deployer>Default.DeployerBank:depl-482</deployer>

            <deployer>Default.DeployerBank:depl-480</deployer>

         </deployers>

      </generic.GenericObject.configureChildInstanceException>

   </SOAP:Body>

</SOAP:Envelope>

Note: The <responseTime> tag in the header is the time at which the response stream is opened.

Deployment failure recovery procedures

The deployment failure recovery procedures to be carried out varies with the type of action (creation, modification, or deletion):

• If deployment fails during object creation, you must clear the deployments to remove the previously created object from the database. To remove the possibility of partially-created objects on an NE, resynchronize the object (this can be done using the generic.GenericObject.triggerResync method) and remove all partially-created objects using the XML API or the NFM-P.

• If deployment fails during object modification, clearing a deployment does not reset the modified object in the database. To reset to the previous object setting, resynchronize the object. In there are partially-modified objects, set the objects back to their original values using the XML API or the NFM-P.

• If deployment fails during object deletion, clearing a deployment completes the object deletion in the NFM-P database. To reset to the previous object setting, resynchronize the object.

See Workflow to handle deployment failures in this chapter for more information about handling a deployment error that has caused the NFM-P database to be out of synchronization with the managed network.

Deployment alarms and events

OSS applications that rely on alarms and events to notify them of deployment failures must subscribe to the JMS interface. See Chapter 4, Event monitoring using JMS for information.

The DeployerEvent indicates the success or failure of an asynchronous deployment request and will return a successList and failedList of deployerIds. See Figure B-7, DeployerEvent message example for a DeployerEvent message example. An OSS can then take the failed deployerId and retrieve more information on the reason for the failure and then perform the required recovery procedure.

Deployment alarms are also raised and OSS applications can use the requestId and the requestUser to match failures with specific requests. After the deployerId is extracted from the alarm, you can use the deployerId to query a specific deployment. See the XML API SDK Sample Code Navigator for a sample request to retrieve deployment information.

Figure 15-12, Deployment alarm example shows a deployment alarm example. The following information is contained in the deployment alarm:

• the alarmClass attribute identifies the alarm class as a deployment failure

• the deployment ID is last component of the objectName attribute, in this case deployerId=771

• the additionalText attribute also contains the deployerId, the requestId, and the client user (requestUser) that made the request in the format:

  deployerId=771;requestId=AreqGenericObjectConfigureInstance-CLIENT-admin-NFM-P@198.51.100.164-15;requestUser=user name;deploymentType=3

Figure 15-12: Deployment alarm example

<?xml version="1.0" encoding="UTF-8"?>

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">

   <SOAP:Header>

      <header xmlns="xmlapi_1.0">

         <requestID>XML_API_client@n</requestID>

      </header>

   </SOAP:Header>

   <SOAP:Body>

      <fm.FaultManager.findFaultsResponse xmlns="xmlapi_1.0">

         <result>

            <fm.AlarmInfo>

               <severity>minor</severity>

               <previousSeverity>indeterminate</previousSeverity>

               <originalSeverity>minor</originalSeverity>

               <highestSeverity>minor</highestSeverity>

               <probableCause>11</probableCause>

               <alarmName>13</alarmName>

               <type>5</type>

               <affectedObjectFullName>network:10.1.202.93:shelf-1:cardSlot-1:card:daughterCardSlot-1:daughterCard:port-5</affectedObjectFullName>

               <affectedObjectClassName>equipment.PhysicalPort</affectedObjectClassName>

               <isAcknowledged>false</isAcknowledged>

               <wasAcknowledged>false</wasAcknowledged>

               <acknowldegedBy>N/A</acknowldegedBy>

               <firstTimeDetected>1128369209032</firstTimeDetected>

               <lastTimeDetected>1128369209032</lastTimeDetected>

               <lastTimeSeverityChanged>0</lastTimeSeverityChanged>

               <lastTimeCleared>0</lastTimeCleared>

               <lastTimePromoted>0</lastTimePromoted>

               <lastTimeDemoted>0</lastTimeDemoted>

               <lastTimeEscalated>0</lastTimeEscalated>

               <lastTimeDeEscalated>0</lastTimeDeEscalated>

               <lastTimeAcknowledged>0</lastTimeAcknowledged>

               <frequency>0</frequency>

               <occurences>N/A</occurences>

               <numberOfOccurences>2</numberOfOccurences>

               <numberOfOccurencesSinceClear>2</numberOfOccurencesSinceClear>

               <numberOfOccurencesSinceAck>0</numberOfOccurencesSinceAck>

               <isServiceAffecting>false</isServiceAffecting>

               <additionalText>deployerId=771;requestId=AreqGenericObjectConfigureInstance-CLIENT-admin-NFM-P@13@198.51.100.164-15;requestUser=admin;deploymentType=3;</additionalText>

               <operatorAssignedUrgency>indeterminate</operatorAssignedUrgency>

               <urgencyAssignedBy>1</urgencyAssignedBy>

               <relatedObjects>

                  <null/>

               </relatedObjects>

               <affectingObjects>

                  <relationshipTreeList>

                     <relationshipTree>

                        <objectFullName>Network Queue:default</objectFullName>

                        <subtree/>

                     </relationshipTree>

                  </relationshipTreeList>

               </affectingObjects>

               <nodeId>10.1.202.93</nodeId>

               <nodeName>sim202_93</nodeName>

               <affectedObjectDisplayedName>Port 1/1/5</affectedObjectDisplayedName>

               <applicationDomain>equipment</applicationDomain>

               <displayedClass>PhysicalPort</displayedClass>

               <alarmClassTag>generic.DeploymentFailure</alarmClassTag>

               <affectedObjectClassIndex>87</affectedObjectClassIndex>

               <affectedObjectInstanceIndex>5</affectedObjectInstanceIndex>

               <deployerName>N/A</deployerName>

               <deployerId>0</deployerId>

               <requestId>N/A</requestId>

               <requestUser>N/A</requestUser>

               <objectFullName>faultManager:network@10.1.202.93@shelf-1@cardSlot-1@card@daughterCardSlot-1@daughterCard@port-5|alarm-13-5-11-deployerId=771</objectFullName>

               <objectClassName>fm.AlarmObject</objectClassName>

               <allomorphicClassName>fm.AlarmObject</allomorphicClassName>

               <objectId>-578593836</objectId>

               <displayedName>Port 1/1/5 - network@10.1.202.93@shelf-1@cardSlot-1@card@daughterCardSlot-1@daughterCard@port-5|alarm-13-5-11-deployerId=771</displayedName>

               <lifeCycleState>1</lifeCycleState>

               <deploymentState>0</deploymentState>

               <neId>10.1.202.93</neId>

            </fm.AlarmInfo>

         </result>

      </fm.FaultManager.findFaultsResponse>

   </SOAP:Body>

</SOAP:Envelope>

Deployment simulation

CAUTION Service Disruption

It is recommended that deployment never be disabled in a production network.

Since configuration errors may not always be caught by the NFM-P server before configuration changes are committed to the database, you must disable deployment simulation and test with live network equipment to validate changes prior to OSS deployment in the production network.

By default, the NFM-P server deploys configuration changes to network elements through SNMP. You can configure the XML API to save configuration changes in the NFM-P database without deploying the changes, which facilitates OSS development in the absence of real equipment or simulators.

You can use the XML API to configure a mediation.DeploymentPolicy with a mediation.DeploymentMode property set to 1, to disable deployment. The default setting is 2, SNMP.

See Chapter 18, Policy configuration management for more information about how to configure policies.

© 2023 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.