Srini, I don’t think APPC stores any kind on configuration internally. For scale out, the new vDNS that gets instantiated comes with its own configuration files, APPC doesn’t do anything. What APPC does is to reconfigure the vLB as I said in the previous email. I think you raise a valid point though: how to make the scaling use case more generic in order to configure multiple VNFCs, for example the vLB and the newly created vDNS. SO logic is mostly there (modulo some changes), perhaps it’s something we may think about for El Alto.
On a different note, APPC Casablanca release only supports NETCONF merge operations, which means that previous configuration is merged with new configuration. For example, for the scale out use case, the list of vDSN instances that the vLB stores can be updated incrementally at each new scale out. If you want to delete configuration elements, for example during a scale in operation (which however doesn’t exist yet in ONAP), then some changes are necessary. Generic_Configure and DownloadXMLConfig DGs, plus org.onap.appc.ccadaptor.ConfigComponentAdaptor (key = "xml-download") should be changed so as to allow to delete configuration elements with NETCONF. The “merge” operation is hardcoded in the XML block in ConfigComponentAdaptor, perhaps one could parametrize the operation in that class and the DGs in order to allow to execute different operations for different use cases. For scale out, the NETCONF operation should be “merge”, while for a future scale in it should be “none”. Hope this helps. Marco From: "Addepalli, Srinivasa R" <[email protected]> Date: Saturday, March 9, 2019 at 11:20 AM To: "[email protected]" <[email protected]>, "CHO, TAKAMUNE" <[email protected]>, "PLATANIA, MARCO (MARCO)" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [onap-discuss] [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? Thanks Srini From: [email protected] [mailto:[email protected]] On Behalf Of Taka Cho Sent: Tuesday, February 19, 2019 3:07 PM To: PLATANIA, MARCO <[email protected]>; [email protected]; Addepalli, Srinivasa R <[email protected]>; [email protected] Subject: Re: [onap-discuss] [appc] questions about configuration storage Hi, 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 Taka From: PLATANIA, MARCO Sent: Tuesday, February 19, 2019 12:43 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; CHO, TAKAMUNE <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] [appc] questions about configuration storage Srini, 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. Marco From: <[email protected]<mailto:[email protected]>> on behalf of Srini <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, February 19, 2019 at 11:51 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "CHO, TAKAMUNE" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] [appc] questions about configuration storage 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? Thanks Srini From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Taka Cho Sent: Friday, February 15, 2019 5:46 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] [appc] questions about configuration storage Hi Amar, 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_APPC-2BDublin-2BM1-2BRelease-2BPlanning-23APPCDublinM1ReleasePlanning-2DONAPDependencies&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=KgFIQiUJzSC0gUhJaQxg8eC3w16GC3sKgWIcs4iIee0&m=2mKS2Cu6ySXVusCK_k6L7ht1czzyp2BRrOO9Fy8zzLw&s=194rB30KA2BcQAIt1MkdlDEpL0MwJnMMwm5wjxk7IRk&e=> 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. Taka From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Amar Kapadia Sent: Wednesday, February 13, 2019 7:12 PM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] [appc] questions about configuration storage Hi, 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? Regards, Amar __________________________________________________________________________________________ Sign up for our Feb ONAP Bootcamp II in Berlin or Apr ONAP Bootcamp pre-ONS at aarnanetworks.com/training<https://urldefense.proofpoint.com/v2/url?u=http-3A__aarnanetworks.com_training&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=i5VHNTZ3SDPgIii87sudZA&m=Qc5x5THRQslQ4V1Qk8CsAnKHWdtFtgJioC_ouxMKF3M&s=UtH53nJOkqNdm41Evj_wOUyzRUhXMI7hUtDk6FzmVSg&e=> __________________________________________________________________________________________ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15944): https://lists.onap.org/g/onap-discuss/message/15944 Mute This Topic: https://lists.onap.org/mt/29844679/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
