search

openbaton / autoscaling-engine

Respository containing the source code of the autoscaling system
Apache License 2.0
5 stars 5 forks source link

VNFR won't scale if another VNFR causes NSR to set State to SCALING #18

Closed wittling closed 5 years ago

wittling commented 7 years ago

I have an NSD with two VNFs (A & B). A has an FM Policy on it, B has an AutoScaling policy on it.

When I launch the NSD,

Then, the AutoScaling thread keeps throwing an API exception because the NSR State is not ACTIVE, as shown below: "message": "NetworkServiceDescriptor must be in ACTIVE state" } 2017-10-30 23:18:07.508 ERROR 17811 --- [TaskScheduler-9] o.o.a.core.execution.ExecutionEngine : Error while requesting VNFR 940fb838-3ed2-47f5-ba4a-bd53755033ce

org.openbaton.sdk.api.exception.SDKException: Status is 422. The reason is: { "code": "Bad Request", "message": "NetworkServiceDescriptor must be in ACTIVE state" } at org.openbaton.sdk.api.util.RestUtils.checkStatus(RestUtils.java:41) ~[sdk-4.0.1-SNAPSHOT.jar!/:na] at org.openbaton.sdk.api.util.RestRequest.requestPost(RestRequest.java:440) ~[sdk-4.0.1-SNAPSHOT.jar!/:na] at org.openbaton.sdk.api.rest.NetworkServiceRecordAgent.createVNFCInstance(NetworkServiceRecordAgent.java:301) ~[sdk-4.0.1-SNAPSHOT.jar!/:na] at org.openbaton.autoscaling.core.execution.ExecutionEngine.scaleOut(ExecutionEngine.java:109) ~[core-1.2.4-SNAPSHOT.jar!/:na] at org.openbaton.autoscaling.core.execution.task.ExecutionTask.run(ExecutionTask.java:138) [core-1.2.4-SNAPSHOT.jar!/:na] at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) [spring-context-4.3.11.RELEASE.jar!/:4.3.11.RELEASE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_131] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_131] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_131] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_131] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_131] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_131] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]

2017-10-30 23:18:07.508 DEBUG 17811 --- [TaskScheduler-9] o.o.a.core.execution.ExecutionEngine : Executed scale-out for VNFR with id: 940fb838-3ed2-47f5-ba4a-bd53755033ce 2017-10-30 23:18:07.508 INFO 17811 --- [TaskScheduler-9] o.o.a.core.execution.task.ExecutionTask : Executed scaling actions for NSR 940fb838-3ed2-47f5-ba4a-bd53755033ce

wittling commented 6 years ago

Soon I will be going back to re-test this.

mpauls commented 5 years ago

I see the point but that's the correct behaviour. If one VNF is in SCALING so the NSR is in state SCALING, no other VNFs are allowed to scale. In same cases it may makes sense to scale in parallel but VNFs may have dependencies between each other, or one VNF may cause the scale (use target VNF) another VNF.