Enea Edge Automation is an open-source product, with the following directory structure: ansible.cfg automation_framework CHANGELOG environment_variables.sh modules setup_env_requirements.txt setup_env.sh test_harness unit_tests VERSION Each file/directory is described in more details in the following sections.

The setup_env.sh, setup_env_requirements.txt and environment_variables.sh files are used to create the testing virtual environment, using the following prerequisites: The environment variable Python packages Ansible package(s) The environment_variables.sh script sets the environment variables, the setup_env_requirements.txt file contains the mapping between the package name and its version, and the setup_env.sh script creates a testing virtual environment. The setup_env.sh does the following: Checks if the Python 3 and pip packages are installed on the host. If at least one package is not installed on the host, then an error is displayed and the script stops. Creates and activates the testHarness-venv virtual environment. Upgrades the pip package to the newest version. Installs the packages defined in setup_env_requirements.txt on the virtual environment. Sets the environment variables defined in environment_variables.sh on the virtual environment.

The VERSION and CHANGELOG files contain information about the version, build number, and all the notable changes added in the Enea Edge Automation.

The modules/enea directory contains the following: config - contains the configuration files that need to be updated in order to successfully run the Enea Edge Automation. For more details, see . scenario - contains the test scenarios. The test scenarios include custom script examples, service chaining VNF examples and so on. VNF_images - contains the VNF images that are used in test scenarios.

The automation_framework directory includes all the Python scripts used by the Automation Framework. Each Python script implements a class that defines a functionality of the Enea Edge Management application. The Python scripts can be split into the following: The ManagementHTTPClientRestAPIv2.py script, where the ManagementClient class is defined. This class communicates with the Enea Edge Management application via REST API. The uCPEMgrHTTPClientRestAPIv2.py script is where the uCPEMgrHTTPClient class is defined. The uCPEMgrHTTPClient class is a wrapper of the ManagementClient class. This script is deprecated and will be removed starting with the next major release. Other Python scripts, where the classes for the Enea Edge Management module are defined. Each class inherits the ManagementClient class and uses its methods to communicate with the Enea Edge Management application via the REST API. Each class corresponds to an Enea Edge Management module. Example: the OfflineConfigHandler.py script, where the OfflineConfigHandler class is defined. Inside this class, the methods for offline configuration functionality are implemented: addOfflineConfigStore, deleteOfflineConfigStore, uploadConfigToDevice and so on.

The unit_test directory contains: JSON files for complex scenarios with multiple operations. The Python unit-test class. Loader scripts for generating specific test cases for the available Python script. The generated test cases are injected into the Python unit-test suite class to run using the Python unit-test framework.

The ansible.cfg file represents the configuration file for Test Harness. The Ansible configurations have default values delivered in the archive, but they can be changed. Example: for a more extended output, change the output from selective to debug. The test_harness directory contains all the implemented playbooks. This directory is structured in multiple subdirectories, each subdirectory represents a functionality of the Enea Edge Management application. Each implemented playbook from this directory runs a method from a Python class from the automation_framework directory. Each playbook is an atomic operation, a basic operation that need to be tested. These playbooks are used in complex test scenarios.

The log directory is added in the directory structure by the setup_env.sh script. The setup_env.sh script stores the output logs in the setup_env.log file. The Ansible playbooks store the logs in the ansible.log file. The Python scripts store the logs in the debug.log file.

The configuration files must be updated before using Enea Edge Automation. They are stored in the modules/enea/config directory. The configuration files are split according to the component that is used in the testing process: The Enea Edge Management application uCPE Devices VNFs

In order to create a connection with the Enea Edge Management application, the following parameters have to be specified: Enea Edge Management username Enea Edge Management password Enea Edge Management IP address or FQDN Updating the configuration file Open modules/enea/config/Management/management01.json { "ucpe_usr":"admin", "ucpe_pass":"admin", "ucpe_host":"172.24.3.92" } Update the username, password and IP address or FQDN. The modules/enea/config/uCPEManager/ucpem01.json file is a symbolic link to the modules/enea/config/Management/management01.json file. It is deprecated, and it will be removed starting with the next major release. It is possible to use another JSON file for the connection with the Enea Edge Management application. Changing the path for the Enea Edge Management JSON file Open the automation_framework/ManagementHTTPClientRestAPIv2.py file. Go to the create_json_file method from the ManagementConfig class. Change the path of the Enea Edge Management JSON file in the self.ucpe_json_file variable.

The modules/enea/config/uCPEDevices directory contains the following: Examples of the configuration files for different uCPE Devices: inteld1521-16,inteld1521-17, and so on. The scripts for generating all configuration files in scripts folder. The following scripts are implemented to generate the configuration files: generate_device_config.py - generates the JSON configuration file for the uCPE Device. generate_bridges_config_files.py - generates configuration files for all possible OVS bridges created on the uCPE Device. generate_nics_config_files.py - generates the configuration files for all possible NICs created on the uCPE Device.

Before running the script, check the following: The available NICs on the target. The device ID. The IP address of the uCPE Device. Generating the device config Make sure the management interface, the one that ensures the connection between the uCPE Device and the Enea Edge Management application, is not used when generating the JSON configuration files. Run generate_device_config.py: python generate_device_config.py Device name: test Device ID: test_id Device groupings tags [ ]: test_id uCPE Device version [2.5.0]: 2.5.0 Device IP address [No]: 10.0.0.1 Call home [false]: Mgmt network interface - it must not be the management interface [No]: eth0 WAN network interface - it must not be the management interface [No]: eth1 LAN network interface - it must not be the management interface [No]: eth2 WAP network interface - it must not be the management interface [No]: wlan0 The following JSON config file was successfully created (uCPE Device config file): test.json The following JSON config file was successfully created (config store file): store.json Check the configuration files in the modules/enea/config/uCPEDevices/test directory: test.json file - contains all the input parameters for the test device: { "deviceId": "test_id", "deviceGroupingTags": "test_id", "name": "test", "version": "2.5.0", "callHome": "false", "address": "10.0.0.1", "certificate": null, "description": "test", "maintMode": "false", "passphrase": null, "password": "", "port": "830", "username": "root", "interfaces": { "mgmt": "eth0", "wan": "eth1", "lan": "eth2", "wap": "wlan0" } } store.json file - contains the input parameters used for creating an offline config for the uCPE Device: { "version": "2.5.0", "deviceId": "test_id", "deviceGroupingTags": "test_id", "description": "Config file for test" } The generate_device_config.py script can be executed in a non-interactive way using the --non-interactive option, as follows: python generate_device_config.py --non-interactive --device_name=test --device_id=test_id --device_grouping_tags=test_id --version 2.5.0 --device_ip_addr=10.0.0.1 --call_home=false --mgmt_nic=eth0 --wan_nic=eth1 --lan_nic=eth2 --wap_nic=wlan0 The names of the interfaces (mgmt_*, wan_*, lan_* and wap_*) are used to generate the config file for NIC and OVS bridges. Their values depend on the input scenario. When the script is interactively run, the parameter's value between the square brackets is the default one. It can be omitted when the script is non-interactively run.

Generating NIC config files Run generate_nics_config_files.py: python generate_nics_config_files.py Device name: test Check 'test' directory for JSON configuration files Check the configuration files for all interface types in the modules/enea/config/uCPEDevices/test directory. The interface name is defined in the test.json file. The NIC config files have the following structure: <interface_name>_<interface_type>_nic.json. For the eth2 lan interface, the following JSON files are created: lan_dpdk_nic.json - contains: Interface type: DPDK; Sub-type: vfio-pci. { "name": "eth2", "dpdk_type": "vfio-pci" } lan_sriov_nic.json - contains Interface type: SR-IOV, SR-IOV; Mode: adapter-pool; Num VFS: 2. { "name": "eth2", "sriov_mode": "adapter-pool", "sriov_num_vfs": "2" } lan_wan_nic.json - contains Interface type: WAN; Address assignment: DHCP. { "name": "eth2", "address_assignment": "dhcp", "ip_address": "null", "gateway": "null", "netmask": "null" } wap_wap_nic.json - contains Interface type: WAP; Country Code: SE; Wireless band: band5GHz; Wireless Mode: 802.11 g/n; Radio Channel: 42 (80 MHz wide). { "name": "wlan0", "country_code": "SE", "wireless_band": "band5GHz", "wireless_mode": "802.11 ac/n", "radio_channel": "42 (80 MHz wide)" } The generate_nics_config_files.py script can be executed in a non-interactive way, as follows: python generate_nics_config_files.py --device_name=test Check 'test' directory for JSON configuration files The values from the JSON files depend on the input scenario.

Generating OVS config files Run generate_bridges_config_files.py: python generate_bridges_config_files.py Device name: test Check 'test' directory for JSON configuration files Check the configuration files in the modules/enea/config/uCPEDevices/test directory. The name of OVS bridges type has the following structure: <bridge_type>_br.json. The following JSON files are created: ibm_br.json - contains information about the In-band management OVS bridge: { "name": "ibm_br", "type": "inband_mgmt" } sfc_br.json - contains: Dataplane OVS bridge; Type: integration: { "name": "sfc_br", "type": "dataplane", "subType": "integration", "interfaces": [] } vnfmgmt_ipv4_br.json - contains VNF Management OVS bridge, IPv4: { "name": "vnfmgmt_ipv4_br", "type": "vnfMgmt", "vnfMgmtAddress": "10.0.0.1" } vnfmgmt_ipv6_br.json - contains VNF Management OVS bridge, IPv6: { "name": "vnfmgmt_ipv6_br", "type": "vnfMgmt", "vnfMgmtAddress": "2001:db8:0:0:0:0:0:0" } lan_br.json - contains Dataplane OVS bridge; Type: communication; Interface: eth2: lan_br.json { "name": "lan_br", "type": "dataplane", "subType": "communication", "interfaces": [ "eth2" ] } wap_br.json - contains Dataplane OVS bridge; Type: communication: { "name": "wap_br", "type": "dataplane", "subType": "communication", "interfaces": [] } The generate_bridges_config_files.py script can be executed in a non-interactive way, as follows: python generate_bridges_config_files.py --device_name=test Check 'test' directory for JSON configuration files The values from the JSON files depend on the input scenario.

The VNF directory modules/enea/config/VNF, contains subdirectories for each defined VNF: fortigateFWImage, junipervSRXImae and so on. Each VNF subdirectory contains configuration files for: cloud-init, VNF Descriptors, VNF instances. These configuration files are examples used in test scenarios from Enea Edge Automation. For more details about the test scenarios from modules/enea/scenario/, see .

The Automation Framework scripts described in the following section are located in the <Automation-installerdir>/automation_framework directory.

The ManagementClient class is implemented in the ManagementHTTPClientRestAPIv2.py script. The scope of this class is to send REST API requests to the Enea Edge Management application. The methods of the ManagementClient class represent REST API calls to the Enea Edge Management application or ways for creating the objects that are used as input for sending the request. The dictionaries used as the payload in the REST API requests are created in methods from this class. The output of these methods is used as input for the REST API request payload. Each method has a short description in the header, as follows: The scope of the method The input parameters The return value from the source code The URL for the REST API call The payload dictionary for the REST API call Other classes from the automation_framework directory inherit this class, and call its methods. The uCPEMgrHTTPClientRestAPIv2 class is a wrapper of the ManagementClient class. All the methods defined in the ManagementClient class can be used when the uCPEMgrHTTPClientRestAPIv2 object is instantiated. The uCPEMgrHTTPClientRestAPIv2 object is deprecated and will be removed starting with the next major release. It is recommended to use the ManagementClient class instead. Examples: uCPE Device functionalities are defined in the uCPEDeviceHandler class. The uCPEDeviceHandler class inherits the ManagementClient class. The uCPEDeviceHandler method calls methods from ManagementClient to send requests to the Enea Edge Management application. Methods from ManagementClient create the payload dictionary starting from the input parameters and send the REST API request. The output of the methods are parsed and analyzed by methods from the uCPEDeviceHandler class.

In Enea Edge Automation the modules of the Enea Edge Management application are represented by Python classes called Handlers. Each Python class represents a functionality of the Enea Edge Management application. These classes are implemented in the Python scripts that have a Handler string included in the name. The name of the classes is the same as the name of Python script. For the usage of any class, run the Python script with the --help option: python automation_framework/uCPEDeviceHandler.py --help Usage: uCPEDeviceHandler.py [OPTIONS] [PARAMETERS]... Options: -v, --verbose Get info about the methods and parameters -d, --device_name TEXT The uCPE Device name -m, --method TEXT The atomic operation you want to run -f, --config_file TEXT The config file for NIC or bridges (optional argument) -o, --display_output Display output of the method --help Show this message and exit. For displaying all the available Python APIs and their parameters, run the Python script with the -v/--verbose option. A few examples will be displayed in the following sections. If the parameters of the Python APIs contain = in their description that means they have a default value that is already defined in the Python script. The default value of the parameter is displayed after this symbol. To use or change the default value of one or more parameters, perform one of the following methods: Run the Python API using only the values of the parameters without specifying the parameters' names. All parameters will be given and the value will be the position of each parameter. Run the Python API using the <parameter_name>= syntax. Only specific parameters will be given and they will be specified as <parameter_name>=<parameter_value>. Run the Python API with a mix of parameters. Mandatory parameters will be given without specifying their name (their position will be used in this situation) and the optional parameters will be given, using the syntax: <parameter_name>=<parameter_value>. In the test_harness/<module name> directory, the Ansible Playbooks are implemented for running the Python scripts from Enea Edge Automation. The name of the Ansible Playbooks is the same as the name of the Python method. The Python command is between the <command> ... </command> tags from the *.yml files.

The Enea Edge Management functionalities for the uCPE Device are implemented, as follows: automation_framework/uCPEDeviceHandler.py - uCPEDeviceHandler class with methods for adding a device, removing a device, waiting a device to be up, getting the uCPE Device status, and so on. automation_framework/Configuration.py - Configuration class with methods for configuring the uCPE Device: DPDK, external interface, and OVS bridges. The methods of the Configuration class are used in the uCPEDeviceHandler and OfflineConfigHandler classes. The uCPEDeviceHandler class inherits the Configuration class and all its methods. The functionalities for configure external interfaces, configure OVS bridges can be run using the: Configuration file located in modules/enea/config/uCPEDevices, with the -f option. Input parameters. The addDevice and removeDevice functionalities use the modules/enea/config/uCPEDevice/<device_name>/<device_name>.json config file, as the default. The other functionalities can be run using only input parameters. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/uCPEDeviceHandler.py -v Info about uCPEDeviceHandler methods ... Method: addDpdkExternalInterface Parameters: name, dpdkType ... The syntax for running addDpdkExternalInterface, using the configuration file: python automation_framework/uCPEDeviceHandler.py -d <device_name> -m addDpdkExternalInterface -f modules/enea/config/uCPEDevices/<device_name>/<interface_name>_dpdk_nic.json Example: python automation_framework/uCPEDeviceHandler.py -d vep1445-8 -m addDpdkExternalInterface -f modules/enea/config/uCPEDevices/vep1445-8/lan_dpdk_nic.json The syntax for running the addDpdkExternalInterface functionality: python automation_framework/uCPEDeviceHandler.py -d <device_name> -m addDpdkExternalInterface <interface_name> <dpdk_type> Example: python automation_framework/uCPEDeviceHandler.py -d vep1445-8 -m addDpdkExternalInterface eno4 vfio-pci

The Enea Edge Management functionalities regarding the offline configuration are implemented as follows: automation_framework/OfflineConfigHandler.py - OfflineConfigHandler class has methods for adding an offline config, removing an offline config, uploading an offline config on a uCPE Device, and so on. automation_framework/Configuration.py - Configuration class has methods for configuring the uCPE Device: DPDK, external interface, and OVS bridges. The methods of the Configuration class are used in the uCPEDeviceHandler and OfflineConfigHandler classes. The OfflineConfigHandler class inherits the Configuration class with all its methods. The functionalities for the adding offline config store, removing offline config store, configuring external interfaces, configuring OVS bridges can be run using the: Configuration file located in modules/enea/config/uCPEDevices. Input parameters. The other functionalities can be run using only input parameters. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/OfflineConfigHandler.py -v Info about OfflineConfigHandler methods ... Method: addOfflineConfigStore Parameters: version, deviceId, deviceGroupingTags, descr='' ... The syntax for running the addOfflineConfigStore using the configuration file: python automation_framework/OfflineConfigHandler.py -s <store_name> -m addOfflineConfigStore -f <path_to_store_configuration_file> Example: python automation_framework/OfflineConfigHandler.py -s testOfflineConfig -m addOfflineConfigStore -f modules/enea/config/uCPEDevices/test/store.json The syntax for running the addOfflineConfigStore functionality using input parameters: version, deviceId, deviceGroupingTags, desc: python automation_framework/OfflineConfigHandler.py -s <store_name> -m addOfflineConfigStore <version> <deviceId> <deviceGroupingTags> Example: python automation_framework/OfflineConfigHandler.py -s testStoreName -m addOfflineConfigStore 2.5.0 deviceId customerTag

All the Enea Edge Management functionalities regarding the custom scripts are implemented in the CustomScriptsHandler.py script. The CustomScriptsHandler class is implemented in CustomScriptsHandler.py script. Examples of custom scripts are in the modules/enea/config/customScripts/ directory. They can be used when running a Python method from the CustomScriptsHandler class. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/CustomScriptsHandler.py -v Info about CustomScriptHandler methods ... Method: uploadCustomScript Parameters: customScript, phase ... The syntax for running the uploadCustomScript functionality starting from the input parameters: python automation_framework/CustomScriptsHandler.py -m uploadCustomScript <customScript> <phase> Example: python automation_framework/CustomScriptsHandler.py -m uploadCustomScript modules/enea/config/customScripts/test_fail_after_once once-after-startup All the other methods run in a similar way.

The Enea Edge Management functionalities regarding the uCPE Device upgrade are implemented in the DeviceUpgradeHandler.py script. The DeviceUpgradeHandler class is implemented in the DeviceUpgradeHandler.py script. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/DeviceUpgradeHandler.py -v Info about DeviceUpgradeHandler methods ... Method: uploadImage Parameters: imagePath, type, module='VcpeAgent' ... The syntax for running the uploadImage functionality starting from the input parameters: python automation_framework/DeviceUpgradeHandler.py -m uploadImage <imagePath> <type> The default value for the module is VcepAgent, cannot be changed and it is omitted. Example: python automation_framework/DeviceUpgradeHandler.py -m uploadImage /tmp/enea-edge-runtime-xeon-d.tar.gz xeon-d All the other methods run in a similar way.

The Enea Edge Management functionalities regarding the VNF are implemented in the VNFHandler.py script. The VNFHandler class is implemented in the VNFHandler.py script. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/VNFHandler.py -v Info about VNFHandler methods ... Method: getVNFDescriptorByName Parameters: vnfDescriptorName ... The syntax for running the getVNFDescriptorByName functionality starting from the input parameters: python automation_framework/VNFHandler.py -m getVNFDescriptorByName <vnfDescriptorName> -o Example: python automation_framework/VNFHandler.py -m getVNFDescriptorByName fortigateImage -o All the other methods run in a similar way.

The functionalities regarding the Enea Edge Management configuration are implemented in the ManagementHandler.py script. The ManagementHandler class is implemented in the ManagementHandler.py script. To list the implemented methods (functionalities), run the script with the -v/--verbose option: python automation_framework/ManagementHandler.py -v Info about ManagementHandler methods ... Method: getManagementVersion Parameters(not needed): -- ... The syntax for running the getManagementVersion functionality is: python automation_framework/ManagementHandler.py -m getManagementVersion -o All the other methods run in a similar way. The functionalities relating to the Enea Edge Management application configuration are also implemented in the uCPEManagerHandler.py script where the uCPEManagerHandler class is defined. The uCPEManagerHandler class is a wrapper of the ManagementHandler class. The uCPEManagerHandler.py file is deprecated and will be removed starting with the next major release. It is recommended to use the ManagementHandler.py script instead.

The Configuration class is implemented in the Configuration.py script. The Configuration class cannot be independently used. The uCPEDeviceHandler and OfflineConfigHandler classes inherit the Configuration class. The methods should be implemented for both functionalities: uCPE Device and Offline config.

The Logger class is implemented in the Logger.py script. It is inherited in all the classes defined in automation_framework. This class defines a logger for displaying the logs from Python scripts, in console log and file log. For console log, the logger has: Default severity: INFO Format of the logs: [datetime] [severity] message For file log, the logger has: Logs path: log/debug.log Default severity: DEBUG Format of the logs: [severity] [name_of_Python_script] message

The Test Harness sources are in the <Automation-installerdir>/test_harness directory.

The Ansible based Test Harness represents an example of structuring the files needed for creating automated test cases using the Enea Edge Automation, and provides a way to implement them. The ansible.cfg file contains an example of the Ansible default configuration. The default value for stdout_callback is set to selective, to print only certain tasks. It is recommended to switch to debug when a test fails. By setting the parameter any_errors_fatal to True, task failures are considered fatal errors and the play execution stops. All the Playbooks that execute Automation Framework Python modules run on localhost. New entries have to be created for direct communication over SSH with the boards. The setup_env.sh script sets up the testHarness test environment by creating the testHarness-venv Python virtual environment, executing requests needed by Automation Framework Python modules, and installing Ansible. The Ansible package version is 2.9.6. The test_harness directory contains all the implemented Ansible Playbooks. This directory contains the check_error.yml Playbook and many subdirectories, each subdirectory representing an Enea Edge Management module. The check_errors.yml Playbook checks the Python output and returns success or fail results. This file is imported in all playbooks from the test_harness directory and it cannot be run standalone. According to their functionality, the Ansible Playbooks that refer to offline configuration are in the OfflineConfig directory, the ones that refers to CustomScript are in the CustomScripts, and so on. Each Ansible Playbook has a help menu for: Returning the syntax, and examples for running the Playbook. Warning if the input parameters are wrong or not enough. The input parameters are called extra-vars in Ansible playbooks. The help menu is activated when the Playbook is run without any parameters. Example: Display the help menu for addDataPlaneOvsBridge.yml: ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml This playbook runs 'addDataPlaneOvsBridge' method from uCPEDeviceHandler module The Python module will be run as: Usage: uCPEDeviceHandler.py [OPTIONS] [PARAMETERS]... Options: -v, --verbose Get info about the methods and parameters -d, --device_name TEXT The uCPE Device name -m, --method TEXT The atomic operation you want to run -f, --config_file TEXT The config file for NIC or bridges (optional argument) -o, --display_output Display output of the method --help Show this message and exit. Usage: ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=<device_name> bridge_config_file=<bridge_config_file>" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=<device_name> bridge_name=<bridge_name> bridge_type=integration" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=<device_name> bridge_name=<bridge_name> bridge_type=communication" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=<device_name> bridge_name=<bridge_name> bridge_type=communication interfaces=<interfaces>" Run the addDataPlaneOvsBridge.yml playbook: ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_config_file=sfc_br.json" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_config_file=lan_br.json" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_name=sfc_br bridge_type=integration" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_name=wap_br bridge_type=communication" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_name=lan_br bridge_type=communication interfaces=eno4" ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e "device=inteld1521-17 bridge_name=lan_br bridge_type=communication interfaces=eno4,eno5" Each Ansible Playbook from the test_harness directory represents an atomic operation, a basic functionality that is performed on the Enea Edge Management application at a specific period of the time. They can be sequentially run or they can be imported into other playbooks for creating complex scenarios. Example: To instantiate a VNF, the following operations have to be performed: connect to the uCPE Device, bind NICs, create an OVS bridge, create a VNF descriptor, and instantiate the VNF on the device. All these operations can be run Playbook after Playbook using the *.yml files from the test_harness directory.

All the individual Playbooks can be used as imported Playbooks in complex test scenarios. The complex scenarios are defined in: modules/enea/scenario. The test scenarios are split into the following: Functionalities to be tested and used: the CustomScripts, OfflineConfig, ovsTests directories. Service Creation and Lifecycle: the chainedVNFsService directory. VNF Deployment and Lifecycle: the fortigateFWService directory. For each test scenario, the README file contains: Preconditions: The configuration files to be updated The VNF images to be copied The license file needed from the provider and added to a specific path, etc. Running procedures: The ansible-playbook commands for setup the configuration Testing the configuration Cleaning up the configuration The test scenarios have the variable.yml file that contains the input parameters for the Playbooks. These variables can be reused when the same setup is run on another device. Example: For the fortigateFWService scenario, the variable.yml file has the following content: vnf_image_path: "modules/enea/VNF_images/fortios.qcow2" vnfd_config_file: "modules/enea/config/VNF/fortigateImage/fortigateImage.json" vnfd_name: "fortigateImage" vnfi_config_file: "modules/enea/config/VNF/fortigateImage/fortigateFWInstance.json" vnfi_name: "fortigateFWInstance"

The unit-test suite is implemented in the unit_tests directory. The unit-test suite contains the unit-test class defined in unittestSuite.py, and examples of JSON configuration files that can be used for the execution of AF Python classes from the automation_framework directory. The Python unit-test class defined in the unittestSuite.py script provides a way to automate the execution of specific test cases for each supported Python script. This class requires a test suite configuration JSON file that contains a dictionary list of the Python scripts to be processed. Each dictionary contains the path of the Python script to be loaded and the path to the file describing the test cases to be performed against the designated script. Python unit-test suite examples are in the unit_tests/scenario directory. Each scenario has 3 parts: README - explains the prerequisites needed before running the Python unit-test suite. config - contains a JSON file for each functionality that is used in the specified scenario. The JSON files have two keys: name: The description of the functionality. args: The arguments of the Python module. JSON - used for running the scenario. Each JSON file contains the calls to the JSON files from the config directory, and has two keys: config: The JSON file from the config directory that is used. module: The Python module that is run. Steps for running the Python unit-test suite on the Enea Edge Management application are provided in the README file from scenario in use.