sonata-nfv / son-tests Goto Github PK

Create a job that deploy 2 VNFs in 1 PoP using openstack and test the service.

Create the jenkins job to qualify the installation script for ubuntu version 16.04

Create a job that deploy 2 VNFs in 2 PoPs and a SSM using openstack and test the service, then react when the CPU of one VNF reach 80%

Create a job that deploy 2 VNFs in 2 PoPs using openstack and test the service.

Create an integration test between IFTA and SON-EMU in order to authenticate and send a instantiation request from IFTA to SON-EMU

The goal of this tests is verify that all the components installed with the installation script are up and running. To this end we should create script to ensure the following checkpoints:

• Are All the components UP? check one-by-one. Some cases parsing docker ps command. Other cases quering the API.
• Push a package to the SP and check if it is there.
• Configure a VIM/WIM in the SP
  • Test the GUI
  • Test the BSS
  • Test the API

Implement a set of tests to translate a typical SDK workflow during the development of a service, starting by an empty workspace project up to the construction and upload of a service package to the service platform.

Stress the GK-API uploading 10 - 100 - 1000 package at once. We should determine what is the maximum simultaneous package that we can upload to the service platform and the response times.

There is an issue adding the VIM in the database. It marked as fail the job int-9-environment-deploy. It is happening after son-sp-infrabstract PR#63

ERROR: column "tenant" of relation "vim" does not exist LINE 1: ...INTO VIM (uuid, type, vendor, endpoint, username, tenant, te...^ Build step 'Execute shell' marked build as failure

Implement the integration test between SLM FLM IA when deploy a service.

This test targets the integration between the MANO framework, in particular the Service Lifecycle Management (SLM) plugin, the Function Lifecycle Management (FLM), and the Infrastructure Adaptor (IA). The purpose of this test is to trigger the SLM to deploy a new service instance. For this, a message is injected from the Jenkins Job into the service platform message bus. This triggers the SLM, which uses the message bus to publish a message to infrastructure.compute.list, in order to retrieve a list of the VIMs available to host the service, along with resource availability information, such as resource quota limits and utilisation.

The SLM uses this resource information to calculate a placement of the service, and sends a request to the IA with the list of selected PoP (VIM) where the service will be deployed, along with the list of the VM images that need to be pre-loaded on the PoPs. The VIM adaptor receives the message and connect to each VIM listed in the payload to pre-load the given VM images and to create a stack template with the basic networks and environment resource and pushes it to the OpenStack Heat endpoint. Once the deployment is over, it returns a response message to the SLM.

The SLM can then start the VNF deployment. For each VNF in the service, the SLM will trigger the FLM to deploy it, by sending it the relevant VNF descriptor (VNFD) on the mano.function.deploy topic. To request the deployment of the VNF, the FLM will publish a message on the topic "infrastructure.function.deploy" containing the VNFD, the UUID of the VIM where the function should be deployed, as calculated by the placement, and other context information. The Infrastructure Abstraction layer uses the VIM Adaptor to translate the descriptors in the VIM specific language and connects to OpenStack Heat for the deployment. The VIM Adaptor waits for the stack to be updated or for an error message from the VIM. Once the deployment is completed, the VIM Adaptor collects the relevant instance information from OpenStack, forges the response message and sends it to the FLM. The FLM builds the record associated with this running VNF, and sends it to the SLM.

Next, the SLM requests the IA the chain the deployed VNFs together into a service. This is done by sending the NSD to the IA on the infrastructure.service.chain topic. Once finished, the IA responses with an indication whether the chaining was successful. If successful, the SLM requests the IA to configure the WAN, so that traffic can start flowing through the VNFs. This is done on the infrastucture.wan.configure topic, to which the IA again replies with a status indicating the whether the WAN was configured successfully or not.

The project-Y has the following content:

project-Y1
├── dependencies
├── deployment
├── project.yml
└── sources
    ├── nsd
    │   └── sonata-demo.yml
    ├── pattern
    │   └── sample
    │       └── patterm.yml
    ├── ssm
    │   └── sample
    │       └── ssm.yml
    └── vnf
        ├── firewall
        │   └── firewall-vnfd.yml
        ├── iperf
        │   └── iperf-vnfd.yml
        └── tcpdump
            └── tcpdump-vnfd.yml

Shouldn't it have the following?

├── META-INF
│   └── MANIFEST.MF
├── README.md
├── docker_files
│   ├── firewall
│   │   └── Dockerfile
│   ├── iperf
│   │   └── Dockerfile
│   └── tcpdump
│       └── Dockerfile
├── function_descriptors
│   ├── firewall-vnfd.yml
│   ├── iperf-vnfd.yml
│   └── tcpdump-vnfd.yml
└── service_descriptors
    └── sonata-demo.yml

And have the .son extension, instead of .zip?

@srodriguezOPT I've added some errors control in the deployment script:

This section is returning an 500 error. Could you check if we are doing it well?

curl -H "Content-Type: application/json" -X POST http://sp.int3.sonata-nfv.eu:32001/requests?service_uuid=8b47d222-560a-4cad-a54a-793b1ee8849e

https://github.com/sonata-nfv/son-tests/blob/master/int-bss-gkeeper/scripts/postGatekeeperSampleRequest.sh#L6

Integration between kpi module, gtkapi and monitoring system

Define integration test between the components of user management (External and/or internal component, gtk-usr (Adapter), Keycloak).

• Register a user
• Register a component
• Remove a user
• Remove a component
• Login a user
• Login a component
• Logout a user

Stress the monitoring system. Try to get numbers about how many metrics per second can support. Metrics lost, response time.

Stress the mano framework injecting message through the broker and try to measure the response time and the messages lost.

Job description (tsoenen): This test starts by deploying a test plugin (as docker container), which couples to the message broker. This test plugin will make service deploy calls that will appear to the MANO framework as originating from the Gatekeeper. The test plugin will run different set, it will only make one service deploy request, and measure the time between the call and the response that indicates that the deployment succeeded. In the second set, two service deploy requests will be made at the same time, and for both the test plugin will measure the time between the call and the response. We will run a total of 10 sets, where set X makes X service deploy requests.

The test plugin will measure and output the following things:

• Average deployment time for each set
• Percentage of satisfied deployment requests

Implement the integration test between SSM and FSM

This test targets the integration of the MANO framework plugins including the Service Lifecycle Manager (SLM), the Function Lifecycle Manager (FLM), the Specific Manager Registry (SMR), the Service Specific Manager (SSM) and the Function Specific Manager (FSM) for the purpose of FSM/SSM onboarding and instantiation. To start the test, a message is injected from the Jenkins Job into the service platform message bus on the service.instance.create topic. This message triggers the SLM to start the 'service deploy' workflow. The descriptors included in the message should describe a service and a VNF that require the use of an SSM and an FSM. This will trigger the SLM to instruct the SMR to onboard the needed SSMs, by sending a message on the specific.manager.registry.ssm.on-board topic. The request message is sent to SMR along with the service descriptor (NSD) of the service. This message triggers the SMR to obtain the SSM registry URI from the NSD and to on-board the SSM. The result of this action will be sent back to SLM.

In the next step, the SLM sends an SSM instantiation request to the SMR using the message bus. This triggers the instantiation function of the SMR which starts the SSM as a docker container. Once the SSM is up and running, it sends a registration message to the SMR. The SMR receives the message, registers the SSM, and sends the result to the SSM. The SMR also notifies the SLM about the result of the SSM instantiation.

After this, the SLM will perform some tasks that are listed in the 'service deploy' workflow, which are not relevant to this task. After these processes are completed, the SLM will instruct the FLM to deploy the VNFs of the service. Once the FLM receives such a request, which includes the VNF descriptor (VNFD), a similar process as the one described above takes place. The FLM requests the SMR to onboard, and then instantiate the FSM associated with the VNF.

We should publish all containers to dockerhub with the devtag in order to provide the last version of SONATA everyday.

Create the jenkins job to qualify the installation script for Centos version 7

If Integration test 5 is run directly after integration test 4, the start state of the platform for integration test 5 is corrupted. There are no plugins registered with the plugin manager, while at least the SMR, SLM and IA should be registered. This causes integration test 5 to fail.

If we run integration test 5 on a clean environment, the test succeeds. As temporarily fix, we changed the chain of integration tests, so that integration test 5 is run on a clean environment.

In the long run, we should fix the issue itself. It should not be possible that the platform reaches the corrupted state it has at the end of integration test 4 (this state is not necessarily caused by int-4, it can be caused by an earlier test as well). Therefor, we should investigate how we reached this state and prevent it from happening again.

Additional suggestion by Jose: Add to the test script, so that the test starts from a known state of the platform, no matter what the previous tests did to the platform. This should be done in addition to investigating/fixing the issue described above.

Hi!

@srodriguezOPT Could you use docker cp intead create a volume in the remote host and then connect by ssh to get the files?

It would be:
docker cp son-bss:/usr/local/yeoman/SonataBSS/E2E_tests/reports/reports.html .

The goal of this tests is verify that the certificate generated for GUI and BSS are valid and placed in the right way

int-gtkpkg-sp-catalogue/tests5.sh already includes the integration test for receiving a son-package file from the SP.
This tests is currently disabled while Gatekeeper API is not ready.

Define a test to extract monitoring data from a VNF using the SDK through websockets

Create a job that deploy 1 VNF in 1 PoP using openstack and test the service.

Stress the gkapi requesting information from each service. Service, functions, packages. Try to get the maximum number of requests that the gtkapi can support simultaneously

{"error":{"code":500,"message":"#<NameError: undefined local variable or method file_content' for Validator:Class>"}}`

Stress the catalogues and repos inserting, updating and deleting entries using the API. Try to get numbers about how many request per second can support

Stress the IFTA deploying simultaneous NS, try to identify the maximum of simultaneous deployments that the IFTA can perform.

Authenticate the IFTA against keystone version 3