Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
TODO: Move to be a functional requirement for Frankfurt Page, archive the vFW usecase page
Overview
ONAP Policy will support CDS as an actor so that the controlloop usecases can make use of it to take any type of action by executing the CBA. We would like to use the vFW usecase to demonstrate the integration between Policy and CDS.
Problem statement
Current implementation using APPC ModifyConfig
Today, Policy allows the Control Loop Designer to specify the payload for APPC API calls through CLAMP. Policy copies the entire payload of the operation that APPC has to execute against the VNF during closed loop into the APPC LCM request.
Define ModifyConfig action in CDS for Post-Instantiation
Create CDS package (CBA: controller blueprint archive) that defines ModifyConfig action. The inputs that we envision are VNF ID, Port number and credentials for authentication. As a part of this package designer will define the ModifyConfig action by providing golden templates (XML Netconf template) along with a mapping file defining what values to resolve and a python script to resolve the configlet and apply it using NETCONF. An example of deploying configuration to a NETCONF server using CDS can be found here: https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Scripts/python/ConfigDeploy.py
The recording can be accessed at: Presentation#ONSNA2019
Removing ModifyConfig Parameters from the Policy Template
ModifyConfig action including the parameters and their resolution will be defined in CDS as described above. We will implement CDS API model implementation and actor implementation in policy so that we can either directly invoke CDS to push the NETCONF payload to the vPacketGen VNF or invoke APPC to execute ModifyConfig against the traffic generator VNF.
For example, as described above: a user can define ModifyConfig parameters in CDS using DD and specify the parameter resolution. During closed loop, Policy will just tell APPC to execute ModifyConfig against a specific VNF. APPC will then look at the VNF template (built with CDS) to retrieve the ModifyConfig parameters and use DD for their resolution. If DD will not be available, then ModifyConfig parameters could be defined in CLAMP and pushed to Policy during closed loop creation. Policy will then pass these parameters to APPC during closed loop execution. This is how the automated scale out use case is designed for Casablanca.
Migration to APPC LCM API (Future)
Mark to deprecate the old API for ModifyConfig and leverage CDS GRPC enabled Self Service API to enable LCM actions such as configModify and other lcm action for xNF.
Participating Companies
Bell, AT&T, Ericsson ....
Artifacts
vFW Clamp and CDS integration use case.pptx
CBA: vFW_CDS_CBA.zip
Data dictionary: dd UPDATES IN cds ui with processor-db.json
Payload to CDS from Policy (rest), gRPC will entail same parameters (Needs discussion)
Code Block | ||||
---|---|---|---|---|
| ||||
{ "commonHeader": { "originatorId": "Policy", "requestId": "1234", "subRequestId": "1234-12234" }, "actionIdentifiers": { "blueprintName": "test", "blueprintVersion": "1.0.0", "actionName": "config-deploy", --> Must also be sent as an input to policy. "mode": "sync" }, "payload": { "config-deploy-request": { "config-deploy-properties": { --> The below parameters are not static, but should be driven from the CBA, except maybe the key AAI attributes. "service-instance-id": "serviceInstanceId", "vnf-id": "genericVnfId", --> Based on the target_type in Operational Policy Model we choose whether to send service-instance-id, vnf-id, vfmodule-id "active-streams": "$activeStreams" --> How do we ensure that this content is ingested and passed along to CDS in a generic way? CLAMP rendering the CBA to expose the expected input parameters? TBD } } } } |
Another possibility to make the payload to be JSON format:
Code Block | ||||
---|---|---|---|---|
| ||||
{ "commonHeader": { "originatorId": "Policy", "requestId": "1234", "subRequestId": "1234-12234" }, "actionIdentifiers": { "blueprintName": "test", "blueprintVersion": "1.0.0", "actionName": "config-deploy", "mode": "sync" }, "payload": { "config-deploy-request": { "config-deploy-properties": { "$service-instance-id": "$serviceInstanceId", --> node.attribute format of AAI: Future "$vnf-id": "$genericVnfId", "$data": { "active-streams": { "bluh": "joe" }, "arrayInfo": [ "one", "two" ], "bla": "vla" } } } } } |
Goals
- To bring in integration of CDS into policy as another actor and demonstrate this integration using the vFirewall end-to-end closeloop usecase (design-time + runtime: instantiation and closeloop)
Contributions
[WIP]
Operational Policy Model to support CDS as an actor
CDS Blueprint archive details
Future improvements
Impacts
Project | Impact | Notes |
---|---|---|
Policy | high |
|
CLAMP | low | Provide CDS as an actor for policy |
CDS | low | Policy-CDS Self-Serve API, CBA definition |
Integration | medium | Update the testsuite repo to use the latest CBA, new operational policies and other updated artifacts |
Open Questions
Facilitate ways for policy to ingest/process a dynamic payload in a generic way so it can act as a passthrough between CLAMP and CDS for payload specific params. CLAMP to render CDS blueprint??CDS actions and the layer at which the target resolution/actions are to be taken → driven by CDS action and target-type in Operational Policy modelMapping between CLAMP --> Operational Model --> CDS input params
Mark old APPC LCM API for deprecation. Leveraging CDS GRPC enabled Self Service API to enable LCM actions such as configModify and other lcm action for xNF- CDS + CLAMP integration: new functional requirement and usecase requirement to demonstrate this integration.
Dependency on updating TOSCA Operational Policy model. To follow-up on Controlloop subcommittee - Stretch Goal: Testsuite update (Daniel Rose), parallel testsuite for vFW. Continue using current APPC workflow for vFW.