search

sonata-nfv / tng-tests

5GTANGO Integration tests repository
Apache License 2.0
6 stars 29 forks source link

**test_sp02_test_service_reconfiguration_(OS)** #209

Open tsoenen opened 5 years ago

tsoenen commented 5 years ago

Short description: Ensure that a service reconfiguration is triggered and executed correctly based on custom metrics from Openstack. Tool: monitoring engine, MANO, Policy Manager Collected metric: test execution time, test instantiation time, test scale time Priority: high Complexity: medium Responsible: PANOS K (SYN), Eleni (UBI), Thomas (IMEC)

tsoenen commented 5 years ago 
We need to ensure that a service reconfiguration is triggered based on custom metrics from VIM (OS)
    * define SP platform (pre-int)
    * clean our specific package
    * upload our specific package (vnf based - year 1 demo)
    * create a policy descriptor that defines a scaling event when a threshold for a generic metric is crossed
    * define the policy as default for this specific package / ns
    * deploy the network service
    * wait until the service is deployed
    * check if the serivce is deployed correctly
    * fake the custom metric crossing the threshold by placing it on the pushgateway
    * check if the metric is available from prometheus, associated to the service
    * wait for the policy manager to request a MANO scaling action, and for the MANO to execute this action
    * evaluate the outcome of the MANO action
    * terminate the service
    * deactivate policy
    * delete the policy
    * delete the package
tsoenen commented 5 years ago

@efotopoulou Hi Eleni, how is it going with this? Do you have an idea when you would have a correctly functioning robot testfile?

efotopoulou commented 5 years ago

hi @tsoenen and @pkarkazis,

just commited a new version of the current integration test. ns-squid-haproxy is succesfully packaged and deployed/undeployed with an elasticity policy enforced within the current integration test. I have some issues we could tackle together:

1) the service instantiation is done without a friendly name (it is optional to change this at the tnglib) 2) i was not able to stress the haproxy with some traffic input because the external IP was not accessible. (maybe @tsoenen you can help on this)

The remaining steps are the following: A. Check monitoring rules (almost done) @pkarkazis i added the relevant function at monitor.py B. Trigger one Monitoring rule @pkarkazis how can we push a fake metric at this step? Alternatively since the "haproxy_vnf_vdu01_haproxy_backend_sespsrv_less30_19ca692b" rule is already active i can also adapt the policy so as to demand a scale out action a while after the NS deployment. This is also an option that is more simple and reaches the test purposes. But if you prefer to do it by a fake metric value no problem! Screenshot_20190718_173019 C. Check that scaling action has been triggered by the policy manager i will impement this by checking the actions generated by the policy manager. D. Evaluate the outcome of the MANO action here i plan to check the number of VDUs. if they are 3 (one haproxy and two squids then the scaling action is done) @tsoenen if you want to check this step by an other way, again you are more than welcome!

Tomorrow i have a day-off, so i will continue with the test implementation from monday.

pkarkazis commented 5 years ago

@efotopoulou The scope of the test is to check the scaling action. So, I agree with the usage of the already defined rule.

efotopoulou commented 5 years ago

@tsoenen i am trying to finish the test_sp02_test_servicereconfiguration(OS) #209 i have a problem at scaling out the squid vnf. Graylogs servicelifecyclemanagement container give me the message: Service None Response on scaling request: {'error': "Missing 'service_instance_id' in request", 'status': 'ERROR', 'scaling_type': None} the NS created by the test is placed here https://int-sp-ath.5gtango.eu/service-management/network-services/services/fea733a3-0176-4b41-bf9b-444698d44635 if you instantiate it ... in a while the scaling out will be requested from the MANO? what goes wrong with scaling? thanks a lot for your time!

efotopoulou commented 5 years ago

@tsoenen i have a problem when trying to terminate the NS. i get the following error message from the servicelifecyclemanagement container

Error in subscription thread: '0e3563e7-3eaf-45a9-907b-414efbbff04d' File "/usr/local/lib/python3.4/site-packages/sonmanobase-0.9-py3.4.egg/sonmanobase/messaging.py", line 173, in _wrapper_cbf cbf(ch, method, properties, body) File "/plugins/son-mano-service-lifecycle-management/son_mano_slm/slm.py", line 512, in service_instance_kill orig='GK') File "/plugins/son-mano-service-lifecycle-management/son_mano_slm/slm.py", line 1141, in terminate_workflow return self.services[serv_id]['schedule']