User Guide 17/1553-AXM10104/1 Uen V

VNF Life Cycle Management
Virtual Multimedia Resource Function

Contents


1 Introduction

This document contains information for system administration tasks performed in the VNF Lifecycle Manager (VNF-LCM). VNF-LCM provides a workflow execution environment and a web-based application for managing VNF life cycle procedures.

VNF life cycle procedures are realized by executing ordered sequences of steps, called workflows. Each workflow must be provided with VNF-specific input parameters during execution.

The workflows can be managed and monitored using the following interfaces:

  • Full Stack Scenario

    • The VNF-LCM GUI when using the ENM (EM-triggered mode)

    • The EO GUI when using the EO (NFVO-triggered mode)

  • Small Stack Scenario

The following applies for life cycle operations for EO through the Or-Vnfm interface:

  • EO is the only supported NFVO.

  • The only supported workflows are instantiation and termination.

  • The supported VIM is OpenStack.

2 Prerequisites

This section provides information on the tools and conditions that apply to the procedures in this document.

Before performing any VNF-LCM procedure, ensure that the following conditions are met:

  • The software delivery package including vIMS workflows, VNF-specific Heat Orchestration Template (HOT) files, example environment files, and the VNF-LCM scripts is available.

  • VNF-LCM is available using either Operations Support System, Radio and Core (OSS-RC) or Ericsson Network Manager (ENM).

  • EO is available.

  • In EO, the VIM zone, VDC, and SRT are configured, the external VNFM is registered. For more information on configuring EO, see System Administration Guide, Reference [1].

  • The workflow bundle RPM is installed as described in the relevant network management system documentation. For more information, see VNF-Lifecycle Manager System Administration Guide, Reference [1].

  • The following minimum version requirements are met:

    • Virtual Infrastructure Managers (VIMs):

      • CEE: R6 or newer

      • OpenStack: Mitaka or newer

    • vIMS workflows: 1.16.0

    • VNF-LCM: 18.18 or higher (minimum SW media version: 4.10.14)

    • EO: 18.0

  • The VIM is configured in VNF-LCM.

    Note: The VIM configuration in VNF-LCM can be checked with the vnflcm vim list command.

    For more information on configuration and the command, see VNF-Lifecycle Manager System Administration Guide, Reference [2].

  • The cloud environment is prepared for the deployment of the VNF, that is, the following activities are performed:

    • Cloud hardware and software preparation and configuration

    • Flavor creation

    • Network topology creation

    • Subnet creation

    For detailed instructions, see the relevant deployment instructions.

3 Prepare VNF Deployment Parameters

The VNF-LCM uses the parameters of the env.yaml file as input for VNF instantiation, therefore they must be defined to match your network environment.

The mrf_config parameter of the env.yaml file contains the VNF configuration either from a backup of an older VNF, or prepared by Ericsson, to be used for instantiation. This procedure describes how to prepare VNF deployment parameters with detailed instructions on providing the value for the mrf_config parameter.

Note: The yaml files included in the examples folder of the software delivery package serve as examples for a possible network configuration. They can be modified to match your network environment.

Steps

  1. Extract the node_configuration/is.xml file from the compressed configuration file.
    Note: The compressed configuration file can either be a tar or a zip file.
  2. Pack the is.xml file to the mrsv-config.tar.gz file using the vmrs_config_update.py script from the software delivery package:
    ./vmrs_config_update.py -c mrsv-config.tar.gz -sxf is.xml
    Note: The mrsv-config.tar.gz file must exist before using this command; running vmrs_config_update.py does not create the tar.gz file. If there is no previous backup file available, use the example configuration file (example_config.tar.gz) from the software delivery package.

    For more information on the example configuration file, see Initial Configuration Guide.

  3. Generate a Base64-encoded value of the VNF configuration for the mrf_config parameter using the following command:
    base64 -w 0 <file_path_of_mrsv-config.tar.gz> > <file_for_Base64_encoded_string>
  4. Add the Base64-encoded string from the <file_for_Base64_encoded_string> file as a value of the mrf_config parameter to the following file:

    • In the case of small stack setup, to the env.yaml file

    • In the case of full stack setup, to the VNFD_Wrapper.json file

  5. Ensure that all deployment HOT file parameters are assigned a correct value:

    • In the case of small stack setup: parameters specified in /vnflcm-ext/current/vnf_package_repo/<vnfdId_as_directory_name>/configurations/<example_configuration_1>/env.yaml

    • In the case of full stack setup: parameters specified under instantiateVnfOpConfig of /vnflcm-ext/current/vnf_package_repo/<vnfdId_as_directory_name>/Resources/VnfdWrapperFiles/VNFD_Wrapper.json

  6. Ensure that all deployment HOT file parameters specified in the /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/configurations/example_configuration_1/env.yaml folder are assigned a correct value.
  7. Add any missing deployment parameters and their default values to the env.yaml file.

4 Onboarding

This section gives information on onboarding options, and contains procedures on onboarding the Virtual Deployment Package on EO and VNF-LCM.

Small stack scenario  

In this case, the HOT and environment yaml files of the software delivery package are onboarded on VNF-LCM, and the cloud environment is prepared for the deployment of the VNF (that is, image upload, flavor and network topology creation are handled in the cloud environment). In this scenario, no orchestrator is involved during onboarding procedure. For more information on the small stack onboarding procedure, see Onboard the Virtual Deployment Package on VNF-LCM.
Full stack scenario  

In this case, besides VNF-LCM and the cloud environment, an orchestrator (namely, the EO) is involved in the onboarding procedure. The cloud environment preparation is the same as in the small stack scenario, while onboarding on VNF-LCM differs slightly from the small stack setup. For more information on the full stack onboarding procedure, see Onboard the Virtual Deployment Package on EO and Onboard the Virtual Deployment Package on VNF-LCM.

4.1 Small Stack Scenario

4.1.1 Onboard the Virtual Deployment Package on VNF-LCM

This section describes how to prepare for workflow-based VNF operations using VNF-LCM. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

Steps

  1. Copy the release-specific zip file provided in the software delivery to the /vnflcm-ext/current/vnf_package_repo/ folder.
    cp <release-specific_zip_file_path> /vnflcm-ext/current/vnf_package_repo/
  2. In /vnflcm-ext/current/vnf_package_repo/, unzip the release-specific zip file to the identically named release-specific folder.
    cd /vnflcm-ext/current/vnf_package_repo/ && unzip <release-specific_zip_file_name> -d <vnfdId>
    Note: Make sure that the <vnfdId> in the unzip command option is the same as the zip file name. Having a different folder name can break the procedure.

    Example

    In case the release-specific zip file is vMRF-1.8.0-6b3f69a8-openstack.zip, the release-specific folder (<vnfdId>) must be vMRF-1.8.0-6b3f69a8-openstack.

    `--vnflcm-ext
    |--current
       |--vnf_package_repo
           |-- vMRF-1.8.0-6b3f69a8-openstack
               |-- configurations
               |   |-- example_config_1
               |   |   `-- env.yaml
               |   `-- example_config_2
               |       `-- env.yaml
               |-- Resources
               |   |-- EnvironmentFiles/
               |   |-- HotFiles/
               |   |-- LcmScripts/
               |   `-- VnfdWrapperFiles/
               `-- vmrf.yaml

    Result: The directory Resources and the vmrf.yaml file are created in /vnflcm-ext/current/vnf_package_repo/<vnfdId>.

  3. In /vnflcm-ext/current/vnf_package_repo/<vnfdId>, create a configurations subdirectory with write permission for the jboss_user, and a child directory for each VNF configuration. This allows for storing multiple VNF configurations.
    Note: Each directory in configurations shall contain a VNF-specific env.yaml environment file. Each env.yaml file can be used for a different VNF instantiation, depending on, for example, network needs.
  4. Transfer ownership of the onboarded directory to the jboss_user using the following command:
    sudo chown -R jboss_user /vnflcm-ext/current/vnf_package_repo/<vnfdId>
  5. If missing, add the private SSH key to the /vnflcm-ext/backups/private_keys/workflows/default/.ssh folder, and the corresponding public SSH key in the admin_authorized_key parameter of the env.yaml file of each configuration stored.

    The public key can be obtained by using the following command:

    sudo -u jboss_user cat /vnflcm-ext/backups/workflows/private_keys/default/.ssh/id_rsa.pub

    If the SSH key or the .SSH folder is not available, create them using the following command, as jboss_user:

    sudo -u jboss_user bash -c 'cd /vnflcm-ext/backups/workflows/private_keys/default && mkdir .ssh && chmod 0700 .ssh && ssh-keygen -P "" -t rsa -f .ssh/id_rsa'

4.2 Full Stack Scenario

4.2.1 Onboard the Virtual Deployment Package on EO

This section describes how to prepare for workflow-based VNF operations using EO. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

  • You are logged in to EO.

Steps

  1. In EO, click Resources > Packages.
  2. On the opening Upload VNF Package screen, in New Package File, add the zip file matching the deployment scenario from the software delivery package.
  3. In New Configuration File, upload the Resources/VnfdWrapperFiles/VNFD_Wrapper.json file.

    After this step, the content of VNFD_Wrapper.json is displayed in the New Configuration File Content field.

  4. Copy the value of parameter vnfdId from the configuration file to the New Package Name field.
  5. Fill in the following mandatory fields:

    • Package Version

    • Package Vendor

    • Software Version

    • Package Category

    • Description

  6. In the Managers field, select the VNF-LCM used.
  7. Click Start.

Results

After clicking Start, the onboarded package is visible in EO under Resources > Packages.

4.2.2 Onboard the Virtual Deployment Package on VNF-LCM

This section describes how to prepare for workflow-based VNF operations using VNF-LCM. Performing this procedure is a prerequisite for life cycle operations.

Prerequisites

Steps

  1. Copy the deployment-specific zip file uploaded to EO into the /vnflcm-ext/current/vnf_package_repo/ folder.
    cp <deployment-specific_zip_file_path> /vnflcm-ext/current/vnf_package_repo/
  2. In /vnflcm-ext/current/vnf_package_repo/, unzip the deployment-specific zip file to the identically named deployment-specific folder.
    cd /vnflcm-ext/current/vnf_package_repo/ && unzip <deployment-specific_zip_file_name> -d <vnfdId>
    Note: Make sure that the <vnfdId> in the unzip command option is the same as the zip file name. Having a different folder name can break the procedure.

    Example

    In case the deployment-specific zip file is vMRF-1.8.0-6b3f69a8-openstack.zip, the deployment-specific folder (<vnfdId>) must be vMRF-1.8.0-6b3f69a8-openstack.

    `--vnflcm-ext
    |--current
       |--vnf_package_repo
           |-- vMRF-1.8.0-6b3f69a8-openstack
               |-- configurations
               |   |-- example_config_1
               |   |   `-- env.yaml
               |   `-- example_config_2
               |       `-- env.yaml
               |-- Resources
               |   |-- EnvironmentFiles/
               |   |-- HotFiles/
               |   |-- LcmScripts/
               |   `-- VnfdWrapperFiles/
               `-- vmrf.yaml

    Result: The directory Resources and the vmrf.yaml file are created in /vnflcm-ext/current/vnf_package_repo/<vnfdId>.

  3. Transfer ownership of the onboarded directory to the jboss_user using the following command:
    sudo chown -R jboss_user /vnflcm-ext/current/vnf_package_repo/<vnfdId>

5 Procedures

The following sections describe how to perform LCM operations.

VNF-LCM procedures utilize workflow instances. Figure 1 shows an example of a workflow instance, where workflow progress can be tracked in the Workflow Diagram view. The Workflow Diagram only represents stages of the various procedures, operations are performed in the Task view.

It is not recommended to execute a workflow instance on a VNF while another one is in progress, as it can lead to unexpected behavior. If a new workflow procedure is needed, the ongoing one must be terminated before starting a new one.

Figure 1   Workflow Instance Overview

5.1 Instantiate VNF

This section describes how to instantiate a VNF using VNF-LCM.
Note: When instantiating a VNF on a VIM running on BSP, make sure there are no active Capture Jobs on BSP, or the instantiation fails.

Prerequisites

  • The virtual deployment package is onboarded in EO.

    Note: The EM-triggered instantiation workflow is only supported in the ECM tenant (the default tenant in EO).

    This prerequisite must only be fulfilled for the EM-triggered mode in the full stack onboarding scenario.

  • The VNF configuration file is available.

Steps

  1. In the VNF-LCM Workflows screen, select Instantiate VNF, and click the Start a New Instance button.
    Figure 2   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, add VNF Name and VNF Instance Description, select VNF to instantiate, and click Submit.

    Make sure that the Add Network Element in ENM/OSS-RC check box is selected to add the new VNF in the network management application.

    Note: The VNF Name is also used as the Heat stack name. It is not recommended to add version information in this field, as the name is unchanged after VNF upgrades.

    The Select VNF descriptor Id field displays VNF releases available for instantiation in the /vnflcm-ext/current/vnf_package_repo/ directory.

    Figure 3   Instantiate VNF
  5. On the Select VIM screen, select the VIM to be used, and click Submit.
    VNF_LAF_01-inst-3-vim2_edit.png Figure 4   Select VIM
  6. On the Select Tenant screen, select the tenant to be used, and click Submit.
    VNF_LAF_01-inst-4-tenant_edit.png Figure 5   Select Tenant
  7. On the Get Instance Configuration screen, select a VNF configuration to instantiate, and click Submit.
    Note: The Select Configuration for the VNF instance field displays VNF configurations available for instantiation in the /vnflcm-ext/current/vnf_package_repo/<VNFType__VNFVersion>/configurations directory.
    Figure 6   Get Instance Configuration

If the Add Network Element in ENM/OSS-RC check box was selected in Step 4:

  1. If the ENM network management application is used, provide VNF-related parameters for ENM, and click Submit.
    Note: To fill out the Network element version supported by OSS/ENM field, check the supported VNF version with the following command:

    cmedit describe --netype <VNF_type>

    Figure 7   Get OSS or ENM Parameters

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

Results

The VNF is instantiated, it starts handling traffic after configuration data is provided. For more information on providing configuration data, see Deployment Guide for OpenStack or Deployment Guide for Cloud Execution Environment (CEE), and Initial Configuration Guide.

Related tasks

5.2 Upgrade VNF

This section describes how to upgrade a VNF using VNF-LCM.

To perform this procedure without traffic stoppage, it is required that two VNFs are available in parallel during normal operation. During the upgrade process, configuration data is exported from the VNF selected to be upgraded. The VNF then is locked and removed. A new version of the VNF is deployed with configuration data of the previously removed VNF.

Prerequisites

  • All parameters are transferred from the old VNF, except for mrf_image and mrf_flavor.

  • The configuration file (env.yaml) of the new VNF contains the parameters mrf_image and mrf_flavor with the new image version ID from OpenStack.

  • Parameters introduced in the new VNF version are set in the configuration file.

    Note: Other parameters in the target configuration file are overwritten by the exported ones.

  • The virtual deployment package is onboarded in EO.

    Note: The EM-triggered upgrade workflow is only supported in the ECM tenant (the default tenant in EO).

    This prerequisite must only be fulfilled for the EM-triggered mode in the full stack onboarding scenario.

  • The VNF configuration file is available.

Steps

To use the optional customer security layer between LM and NeLS in the new VNF, perform the following step before starting the upgrade VNF-LCM operation:

  1. Back up the following files from the /storage/system/config/lm-apr9010503/certs folder:

    • The Certificate Authority (CA) file

    • The Client Certificate file

    • The Client Private Key file

    • certificate_config.xml

  2. In the VNF-LCM Workflows screen, select NR-Upgrade VNF, and click the Start a New Instance button.
    Figure 8   Select Workflow
  3. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  4. Select the newly created workflow from the Instance Activity panel.
  5. On the Workflow Instance screen, select the VNF to upgrade, termination options, and set automatic rollback timer, and click Submit.
    VNF_LAF_select_VNF_to_upgrade.png Figure 9   Select VNF to Upgrade
    The following termination options are available:
    Graceful  

    The VMs in the cluster are gracefully locked, the VNF instance gradually stops processing traffic. The VNF is terminated after the expiration of the graceful termination period.
    Forceful  

    The VNF is terminated immediately, all ongoing traffic is lost. This option must be confirmed on the next screen, as it stops all traffic.
    Graceful termination timeout (sec)  

    The graceful termination timeout value defines after how many seconds the VNF is terminated when graceful termination has been applied but there is still ongoing traffic. Default value: -1, meaning that there is no graceful termination period, that is, the VNF is terminated only after all VMs stopped processing traffic.
  6. On the Set VNF and target VNF version screen, add new VNF name, description, and version descriptor ID.
    Figure 10   Set VNF and Target VNF Version
  7. On the Select Target Instance Configuration Data screen, select configuration data for the new VNF.

If the Add Network Element in ENM/OSS-RC check box was selected during VNF instantiation:

  1. If the ENM network management application is used, provide VNF-related parameters for ENM, and click Submit.
    Note: To fill out the Network element version supported by OSS/ENM field, check the supported VNF version with the following command:

    cmedit describe --netype <VNF_type>

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

After this step, the old VNF is terminated according to the termination method chosen in Step 5, and the new version is instantiated with the configuration data selected in Step 7.

If the new VNF fails to instantiate, it is automatically terminated and the old VNF is recreated.

If the new VNF is instantiated successfully, the Confirm upgrade screen is displayed, and the automatic rollback timer set in Step 5 is started.

  1. Check that traffic processing in the new VNF version is working properly.

    • If the operation of the new version is considered acceptable, select Confirm and click Submit.

    • If there are problems with the new version that cannot be solved and that are considered unacceptable, select Rollback and click Submit. The rollback procedure terminates the VNF and recreates the old VNF.

    Figure 11   Confirm Upgrade or Rollback

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

    Note: If neither option is chosen before the automatic rollback timer expires, the new VNF is removed and the old one is instantiated automatically.

If the optional customer security layer between LM and NeLS is to be used in the new VNF, perform the following step:

  1. Copy the following certificate files to /storage/system/config/lm-apr9010503/certs in the new version:

    • The Certificate Authority (CA) file

    • The Client Certificate file

    • The Client Private Key file

    • certificate_config.xml

Results

After the upgrade procedure is confirmed, the new version VNF continues accepting new incoming traffic.

Related tasks

5.3 Scale VNF

This section describes how to scale a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be scaled was instantiated using the VNF-LCM.

Steps

  1. In the VNF-LCM click Start a Workflow, select Scale VNF, and click the Start a New Instance button.
    Figure 12   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, specify the following details and click Submit:

    • VNF instance to be removed

    • Scaling type

    • Number of VMs to be added or removed

    Figure 13   VNF Scaling Details
  5. If Scale In was selected, specify the needed parameters, on the Collect extra parameters screen. Otherwise, the scaling procedure is completed.
    Note: This step is optional, leave the fields blank if none of these parameters are needed.
    Figure 14   Scale-in VNF Instance
    The following optional scale-in parameters are available:

    • UUIDs of specific VMs to be scaled-in

      Note: If the number of UUIDs specified is lower than the number of VMs given in the previous step, the workflow automatically scales-in the remaining VMs.

    • VM locking method, that is, graceful or forceful

    • If VMs are locked gracefully, a timer for graceful lock

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

5.4 Heal VNF

This section describes how to heal a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be healed was instantiated using the VNF-LCM.

Note: This workflow is only supported in OpenStack and CEE deployments.

Steps

  1. In the VNF-LCM Workflows screen, select Heal VNF, and click the Start a New Instance button.
    Figure 15   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, select the VNF to be healed, and click Submit.
    VNF_LAF_Heal_collect_mandatory.JPG Figure 16   Heal VNF
  5. On the Input additional parameters for workflow screen, specify VMs to be removed from the cluster, and click Submit.
    VNF_LAF_Heal_collect_uuid.JPG Figure 17  

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

Results

The faulty VM is deleted, but its external storage and network resources remain intact.The ResourceGroup of the VM is marked unhealthy through the HEAT API. An empty stack update is issued, which causes the re-creation of the missing VM with the storage and network resources of the original VM re-attached to the new one.

5.4.1 Configure Auto-Healing

This procedure describes how to activate the autostart file that enables running a healing workflow on a VNF that raises the COM SA, CLM Cluster Node Unavailable alarm and sends notification to the ENM. The autostart file is a VM-level, not a VNF-level ruleset.
Note: The use of Auto-Healing is optional.

Prerequisites

Steps

  1. Extract the autostart xml file.
    tar xzfv vMRF-<version_number>.tar.gz --wildcards '*healing-autostart-rule.xml'
  2. Create an autostart rule file for the specified vMRF, where <Instance_Name> is the name of the instantiated vMRF VNF:
    cd workflows && sed "s/ExampleInstanceName/<Instance_Name>/g" vmrf-node-unavailable-healing-autostart-rule.xml > vmrf-node-unavailable-healing-<Instance_Name>-autostart-rule.xml
  3. Copy the autostart rule file to the /vnflcm-ext/current/workflows/auto-start-rules folder in VNF-LCM.
    sudo cp ./workflows/vmrf-node-unavailable-healing-<Instance_Name>-autostart-rule.xml /vnflcm-ext/current/workflows/auto-start-rules

Results

The autostart file is activated, the VNF runs the automatic alarm-triggered healing workflow according to the rules set out in the autostart file.

5.5 Terminate VNF

This section describes how to terminate a VNF using VNF-LCM.

Continue with this procedure only if the VNF to be terminated was instantiated using the VNF-LCM.

Steps

  1. In the VNF-LCM Workflows screen select Terminate VNF, and click the Start a New Instance button.
    Figure 18   Select Workflow
  2. On the Start a Workflow screen, fill out the Instance Name field, and click Submit.
  3. Select the newly created workflow from the Instance Activity panel.
  4. On the Workflow Instance screen, select the VNF to terminate, termination options, and click Submit.
    Figure 19   Terminate VNF
    The following termination options are available:
    Graceful  

    The VMs in the cluster are gracefully locked, the VNF instance gradually stops processing traffic. The VNF is terminated after the expiration of the graceful termination period.
    Forceful  

    The VNF is terminated immediately, all ongoing traffic is lost. This option must be confirmed on the next screen, as it stops all traffic.
    Graceful termination timeout (sec)  

    The graceful termination timeout value defines after how many seconds the VNF is terminated when graceful termination has been applied but there is still ongoing traffic. Default value: -1, meaning that there is no graceful termination period, that is, the VNF is terminated only after all VMs stopped processing traffic.

    The workflow can be canceled after providing all required input. For more information, see Cancel LCM Workflow.

Results

The VMs in the cluster are terminated with the method selected in Step 4, the VNF instance stops processing traffic, and is terminated.

6 Cancel LCM Workflow

After providing all input to a workflow operation and clicking Submit, a Task is displayed to the right of the Workflow Diagram view that can be used to cancel the current workflow operation

Figure 20   Workflow Cancellation

Cancellation of the workflow can be requested in the following cases:

  • Incorrect input was provided during the workflow preparation.

  • The workflow is running for an unexpectedly long time without completion.
    Note: Repeatedly refresh the LCM GUI to track the workflow progress and to ensure that it is not stuck.

  • VNF-LCM keeps repeating replies.

    For more information on possible repeating replies signifying stuck workflows, see the following examples:

    • Waiting for cluster to be ready. and Waiting for VMs to be bound. can signify incorrectly functioning VMs in the cluster at the end of a workflow.

    • Waiting for LOCKED state. is repeated until all calls are released from the VM.

Steps

  1. Select the cancellation type.
    Note: Currently, there is no difference between graceful and forceful cancellation.

Results

The cancellation takes less than a minute to complete. The workflow instance is canceled, and the workflow fails.

Canceled Workflow Log

Reference List

[1]

System Administration Guide, 1543-CNH 160 9180

[2]

VNF-Lifecycle Manager System Administration Guide, 1543-APR 901 0578
Legal |© Ericsson AB 2017–2019