**test_sp02_test_service_reconfiguration_(OS)**

[sonata-nfv]

**test_sp02_test_service_reconfiguration_(OS)**

[tsoenen]

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]

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

[efotopoulou]

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!

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]

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

[efotopoulou]

@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]

@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']