Configuration should be at NSR level and not at NSD

rajdeepwalia commented 7 years ago

Hi,

Currently the configurations are treated at the NSD level meaning that if multiple instances of same NSD are created then the configuration are all mixed up and it is not possible to specify different configuration for different NSR.

I have done some code changes (quick fixes) for fixing this but it is not fully done with the changes. I will be working further on it to make a more complete solution.

Best regards, Rajdeep Ahluwalia

gc4rella commented 7 years ago

Hi, you can change configuration parameters while deploying a NSD. This feature is provided via REST APIs, and obviously also via Dashboard. I'm not sure, what you mean with mixed up.

rajdeepwalia commented 7 years ago

Hi, I tried to deploy multiple instances of OpenIMS NSD. The VNFD for Bind9 VNF contains 'realm' parameter and during the launch via Dashboard I specified a different value for the same 'realm' parameter. After the deployment was complete I observed:

the realm used for Bind9 was still the one defined in the VNFD while the realm used for dependencies was the one specified in configuration parameter GUI during launch.
If I delete the NSR and re-launch another one then all the configuration parameters/values that were specified during the previous NSR (the one already deleted) are also present. So, the parameters and values from the deleted NSR are never removed.
If there are configuration parameter present in the VNFD and I include a configuration parameter with the same name in the GUI during launch two configuration parameters are present in the configuration parameter list. this is kind of related to first point.
The configuration name specified during the lauch of most recent NSR replaces any previous NSR launch. It seems to me that there is no separation of configuration at NSR level or may be I am missing something.

I tried to look in to the code to find out why this is happening in the checkConfigParameters () function. The function checks if there exists any existing configuration for the NSD and

if it is there then it adds the configuration from the body (GUI during launch)
if it is not there then a new empty configurations are created for the NSD and adds configuration from the body (GUI during launch)

As a remedy what we did was to change this function and compare the parameter already present in NSD and parameter received in body and if there is an overlap then we put the new value received in body.

I know that this is not the complete solution but just an quick fix which was sufficient for our specific case. If this is a shortcoming then I will like to work on it and propose a more complete solution.

Best regards, Rajdeep Ahluwalia

rajdeepwalia commented 7 years ago

Sorry I forgot to mention that I looked in checkConfigParameters () function in https://github.com/openbaton/NFVO/blob/master/core/core-impl/src/main/java/org/openbaton/nfvo/core/api/NetworkServiceRecordManagement.java file.

gc4rella commented 7 years ago

Which version of Open Baton are you currently using?

rajdeepwalia commented 7 years ago

I took version 3.2.0, I hope that is the latest one.

gc4rella commented 7 years ago

yes, it is the latest version. However, those issues may be fixed in latest develop branches...to be checked..

gc4rella commented 7 years ago

what's the current status of this?

lorenzotomasini commented 7 years ago

@radoslavvlaskovski should have tested this 26 days ago.. Any update?

radoslavvlaskovski commented 7 years ago

The issues concerning multiple configuration parameters with the same name were fixed on the develop branch. Concerning the issue of saving the configurations added from the GUI to the NSD checkConfigParameters () function in https://github.com/openbaton/NFVO/blob/master/core/core-impl/src/main/java/org/openbaton/nfvo/core/api/NetworkServiceRecordManagement.java needs to be fixed, because there the configuration parameters are saved to the NSD, but I have still not found the problem.

lorenzotomasini commented 7 years ago

Concerning the issue of saving the configurations added from the GUI to the NSD checkConfigParameters () function in https://github.com/openbaton/NFVO/blob/master/core/core-impl/src/main/java/org/openbaton/nfvo/core/api/NetworkServiceRecordManagement.java needs to be fixed, because there the configuration parameters are saved to the NSD, but I have still not found the problem.

with @mpauls we discussed this, it is a bit more complex, need further discussions

gc4rella commented 6 years ago

@radoslavvlaskovski could you please confirm that such case is not happening anymore with master branch?

openbaton / NFVO

Configuration should be at NSR level and not at NSD #147