Re: [appc] questions about configuration storage
Thank you Taka and Marco.
Incremental configuration involves
- Adding new entries/records
- Deleting existing entries/records
- Modifying the parameters of existing records.
Marco has given an example (adding vDNS entries in vLB) of adding new entries. I guess ‘deletion’ is also obvious from this example.
Taka confirmed that it is possible to modify the existing record parameters.
So, I will take it that ‘ConfigModify’ is for incremental configuration from ONAP user perspective.
One of the Amar’s question is related to merging of configurations. Based on Marco’s response, APPC works with device/VNFC by sending the new additional configuration via netconf edit-config, which is used by device to merge the configuration. But, does the APPC also store merged configuration locally? I would assume so, as APPC need to send the merged configuration in case of VMs that come up in future due to scale-out. This is to ensure that all scaled-out VMs have same configuration among them. Is that right assumption? Assuming that, that assumption is correct, does APPC merges the configuration using local logic or does APPC get the merged configuration from the device/VNFC?
From: onap-discuss@... [mailto:onap-discuss@...] On Behalf Of Taka Cho
Sent: Tuesday, February 19, 2019 3:07 PM
To: PLATANIA, MARCO <platania@...>; onap-discuss@...; Addepalli, Srinivasa R <srinivasa.r.addepalli@...>; akapadia@...
Subject: Re: [onap-discuss] [appc] questions about configuration storage
Marco almost covered everything 😊
‘configureModidy’ is not for incremental configuration. It’s just to change any existing parameter.
If “incremental” means modifying existing parameter, then you said yes it’s yes. APPC sends consolidated config to each existing VM/VNF instances.
APPC does not maintain various versions of configuration.
Hope that helps
I comment on the scale out part, leaving the rest to Taka.
For scale out, the workflow that runs in SO includes a VNF reconfiguration building block that is used to reconfigure the VNF after scaling. The reconfiguration action is executed against an anchor point, which keeps some sort of VNF-level state. In the vLB/vDNS use case, the vLB is the anchor point and contains a list of active vDNS instances (each instance element is an actual GRE tunnel towards a vDNS). When we add a new vDNS as part of a scaling operation, the vLB gets reconfigured. In this use case, reconfiguration means that the list of active vDNS instances is extended so as to include the one just created.
The reconfiguration action can be executed by APPC (fully supported in Casablanca) or SDNC (experimental). Focusing on reconfiguration via APPC, we need to setup the VNF with CDT at the very beginning, specifying:
· Action: ConfigScaleOut (note, this in NOT ConfigModify)
· Protocol: NETCONF
· Device port number: typically depends on the protocol that you choose
· Device interface: an XML file that describes the interface of the device that APPC is going to talk to (in our example the vLB interface).
· Configuration parameters: a YAML file that contains the parameters that will be used by the device interface
The actual parameter values come from SO as payload, APPC extracts them and populate the XML file accordingly before running a NETCONF query against the device. In Casablanca, APPC supports NETCONF merge operation, which means that behind the scenes NETCONF is merging the new configuration coming from the XML file described above with the existing configuration already set in the device. In practical terms, the XML file contains information about the new vDNS, while the configuration in the device (vLB) contains a list of vDNS instances already spun up. The NETCONF merge operation just adds the vDNS endpoint described in the XML file to the existing list.
I think “incremental” means that the configuration of the device changes but still depends on the previous state (in the example above, a new vDNS element is added to an existing list – the state of the vLB), while ConfigModify just replaces the old configuration with the new one.
Taka can certainly add more on this.
From: <onap-discuss@...> on behalf of Srini <srinivasa.r.addepalli@...>
Thank you Amar and Taka on the email thread.
I have few further questions.
APPC has ‘Configure’ and ‘ConfigModify’ LCM commands. Based on documentation I see, if multiple ‘Configure’ commands are issued, last ‘Configure’ configuration-parameters are used as each command replaces the old configuration with the configuration of the command. ‘ConfigModify” – Is this meant for incremental configuration? If so, does APPC maintain various versions of configuration? During scale-out, when new VM is instantiated, does APPC configure the new VM instances with the consolidated configuration without any human intervention?
When incremental configuration is made (via ConfigModify), does APPC send incremental configuration to all existing VM instances?
Also, does it send only incremental configuration or does it send consolidated configuration to each of existing VM instances?
I am not sure what VNF configuration data that you are referring to. You will see APPC dependencies here: https://wiki.onap.org/display/DW/APPC+Dublin+M1+Release+Planning#APPCDublinM1ReleasePlanning-ONAPDependencies
And APPC stores artifact in APPC’s maria DB.
APPC sends LCM API payload using ansible/REST/Chef etc protocols to downstream for configuring VNF(C) /VM.
From: onap-discuss@... <onap-discuss@...>
On Behalf Of Amar Kapadia
A few quick questions on APP-C and VNF configuration data storage:
1. Does APP-C store VNF configuration data?
2. If so where? Is it in A&AI or some private APP-C datastore?
3. Is the storage populated when APP-C writes the configuration to the VNF or does APP-C poll the VNF to get configuration data?
Sign up for our Feb ONAP Bootcamp II in Berlin or Apr ONAP Bootcamp pre-ONS at aarnanetworks.com/training