Clear the deployment. The XML configuration request uses the GenericObject method clearDeployer on the specified deployerName which identifies the deployment to be cleared.

Resynchronize the object that caused the deployment error. The XML configuration request to resynchronize the object using the generic.GenericObject.triggerResync method.

Note: When you use the generic.GenericObject.triggerResync method for a specific <instanceName>, you can specify whether a resynchronization on the object is performed by setting the <resyncSelf> flag to true, or whether the resync is performed on its children by setting the <resyncChildren> flag to true.

The NFM-P does not notify XML API clients when objects are resynchronized.

Perform one of the following steps, depending on your XML API client implementation.

1. Set the object back to the previous setting. To reset the previous object setting, resynchronize the object by using the generic.GenericObject.triggerResync method described in Stage 2 .

   See Deployment failure recovery procedures in Deployments for more information about the different request types that you must consider when you set an object back to the previous setting.

   For example, if a request to create an object with children objects successfully creates the parent object, but creates only some of the children objects, you would create a request to delete the partially created objects.

   For partial failures on a request to modify a port mode, the OSS client should create a request to change the port mode to return it to the original setting.

   For failed deletion requests, performing Stage 2 resynchronizes the NFM-P with the network. Depending on the state the deleted object or objects in the NFM-P, the XML API client should create a request to re-create the deleted objects to restore the NFM-P and the network back to their original state before the failed deployment.

   Subsequent requests to set objects back to their previous settings may fail. After an unsuccessful attempt to set objects back to their previous setting, Nokia recommends that the OSS client not retry.

   The NFM-P continues to try and deploy the change, even after the failure, according to the deployment policies configured for the router. If an automatic recovery mechanism is implemented by the OSS application, the OSS application should use a recovery mechanism that is consistent with the configured deployment policies. For example, if the policy defines that deployments should redeploy after a failure, the OSS application should use a timer mechanism to wait until the deployment is retried before attempting another recovery method

2. Raise an alarm for the administrator to investigate the deployment failure.

   In many cases, such as a loss of connectivity, deployments that fail will continue to fail if retried. If an OSS client continues to retry deployments after a failure, NFM-P resources will be consumed that will be ineffective, ultimately until all deployment resources are consumed. Nokia recommends that you do not continue to retry failed deployment requests. Instead, the OSS client can raise an alarm to alert the administrator that there is a deployment problem.