lorenzotomasini
commented
6 years ago Hi,
You are perfectly right. At the beginning we implemented the ETSI NFV specification trying to translate the specs as they were. And we recognised that there was no field for minimum number of VNFComponents. I think this issue should be translated to a new issue in the NFVO in order to update the model of a VNF and change the scale_in_out parameter to become a range.
then the ASE can check the minimum easily. Should i proceed?
wittling
If I put 2 connection points in my VDU Components, and launch the descriptor, it should be assumed that the MINIMUM number of instances i want to go out with initially is 2.
If I apply Elasticity with a set of SCALE_OUT and SCALE_IN parameters, what is happening right now is that SCALE_IN will knock the instances down to a single instance. This is because in the class DecisionTask.java, the code has a ">1", which ensures that not all of the instances are killed off and that a single instance will always be remaining.
I went in and attempted to change the code (DecisionTask.java) such that instead of using a hard-coded 1 value, I would use the number of initial connection points. What I realized is that the getConnection_points call returns is a dynamic value of the at-runtime number of connection points; not the number we went out with and deployed initially.
After poking around and realizing that we really don't seem to save off that initial number of connection points in the descriptor, so that we can use it as a floor on the SCALE_IN policy, I decided to write it up for discussion.