Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
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 this ModifyConfig action. The inputs that we envision are VNF ID, Port number and credentials for authentication. As a part of this service-instance-id, generic-vnf-id (so that CDS is able to resolve the IP address of the vPKG at VNF level for the vFW usecase), payload (from CLAMP). The authentication will be defined as a DSL in the CBA.
Since, the latest vPKG support RESTCONF interface, the package designer will define the ModifyConfig action in a data-dictionary by providing golden templates (XML Netconf templateleveraging the source-rest endpoint and providing payload (JSON restconf payload) along with a mapping file defining what values to resolve and a python script to resolve the configlet and apply it using NETCONF.
Note:
- Optionally, one could also use NETCONF instead of RESTCONF to push the payload to the device. 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
- Access CDS recording to help build the CBA at: Presentation#ONSNA2019
Resolving VNF configuration using CDS
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 using RESTCONF/NETCONF (as defined in the CBA) 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 CDS to execute ModifyConfig action against a specific VNF. APPC CDS 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 to build the payload and push it to the target during closed loop execution . This is how the automated scale out use case is designed for Casablancaeither using RESTCONF/NETCONF as defined in the CBA.
Migration to APPC LCM API (Future)
We want Mark to also deprecate the old API for ModifyConfig and use APPC's LCM API interface if possible.
Note: The architecture subcommittee is discussing the common controller API, and we will need to replace the current ModifyConfig APPC action with the common controller API
Other possible option: We can instead 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, Huawei
Artifacts
CDS CSAR artifacts
vLB CSAR Service with CDS Package
vFW CSAR Service with CDS Package
vFW Clamp and CDS integration use case.pptx
CDS blueprint artifacts
CBA: vFW_CDS_CBAenhanced-cba.zip
Data dictionary : dd UPDATES IN cds ui with processor-db.jsonfor updating active-streams: update-active-streams.json
Postman collection for validation of CBA: vFW CDS and Policy Integration Postman collection.postman_collection.json
Documentation for testing: Yuriy Malakov Abdelmuhaimen Seaudi user-4e793 FYI -->
Payload to CDS from Policy (rest), gRPC will entail same parameters (Needs discussion)
Code Block | ||||
---|---|---|---|---|
| ||||
{ "commonHeader": { "originatorId": "Policy", "requestId": "1234", # From the Onset event "subRequestId": "1234-12234" 5678" # From the ControlLoopOperation object }, "actionIdentifiers": { "blueprintName": "test", # Embedded into operational policy YAML payload "blueprintVersion": "1.0.0", # Embedded into operational policy YAML payload "actionName": "modify-config-deploy", # -->Embedded Mustinto alsooperational bepolicy sentYAML aspayload an input to policy. "mode": "syncasync" }, "payload": { "modify-config-deploy-request": { request":{ # Key generation pattern: $actionName-request "resolution-key":"UUID", "modify-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{ # Key generation pattern: $actionName-properties "$aai.params":"$aai.params", # Enriched AAI attributes in node.attribute format .... "$data":{ "mapInfo":{ "key":"val" }, "arrayInfo":[ "one", "two" ], "paramInfo":"val" } # Free form JSON string from CLAMP embedded into operational policy YAML payload. JSON object if a valid JSON string is provided, else a string. } } } } |
Sample matching operational policy YAML (Frankfurt): To be aligned with changes per Control Loop Policy Type Design Proposal #1: Simple upgrade of legacy policy types to TOSCA and TOSCA Compliant Policy Types)
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
tosca_definitions_version: tosca_simple_yaml_1_0_0 topology_template: policies: - operational.modifyconfig: type: onap.policies.controlloop.Operational version: 1.0.0 metadata: policy-id: operational.modifyconfig properties: controlLoop: version: 2.0.0 controlLoopName: ControlLoop-vFirewall-__ResourceID__ trigger_policy: unique-policy-id-1-modifyConfig timeout: 1200 abatement: false policies: - id: unique-policy-id-1-modifyConfig name: modify_packet_gen_config description: actor: CDS # Choice of CDS as the actor recipe: modify-config # Blueprint action-name target: resourceID: __ResourceID__ type: VNF payload: artifact_name: vfw-cds # Blueprint name artifact_version: 1.0.0 # Blueprint version "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? mode: async # Blueprint mode type data: '{"mapInfo":{"key":"val"},"arrayInfo":["one","two"],"paramInfo":"val"}' # Free-form json string supplied by CLAMP retry: 0 timeout: 300 success: final_success failure: final_failure } failure_timeout: final_failure_timeout } } }failure_retries: final_failure_retries failure_exception: final_failure_exception failure_guard: final_failure_guard |
TODO items:
- VfModule target type support: In order for CDS to take action at VfModule level it requires another user supplied input called: "template-prefix" which is a list object inside the "$actionName-properties" child-node above. (Will be dealt with in future)
- Verify CLAMP capabilities for configuring the Operational policy configuration to use CDS as an actor when testing end-to-end integration for the vFW usecase. Abdelmuhaimen Seaudi
Documentation for closeloop onboarding process and API calls to set up the integration tests: https://gerrit.onap.org/r/#/c/policy/parent/+/99448/ Yuriy Malakovto provide feedbackCds_Policy_Integration.htmlDocument image names for testing CDS-Policy + dependencies of other ONAP components undefined undefined DONEDocument testing procedure: simulating Control loop event from DCAE and policy API to configure the operational policy undefined undefined DONECDS CBA updates undefined undefinedDONE
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)
Others
CDS and CLAMP integration:
CLAMP rendering possible actions supported by CDS + rendering of the input fields from CBA. Below options available from CDS (Yuriy to add more details)
- Open API generated from the protobuf.
- Ingest the TOSCA yaml from CDS
Follow-up from Controlloop subcommittee item "Discussion on the type of spec CDS needs to create for CLAMP to use: OPEN-API or grpc specification": 2019-09-04 Control Loop Sub Committee Weekly Meeting
- @Yuriy to add the CBA CSAR to the wiki: DONE
- CDS team @Yuriy to think of the notion of classification in CDS to identify the level at which the action/resolution must be acted upon. We do have this representation in Policy.
- What is the standard way to to expose actor capabilities via CLAMP? @Martial to get back with feedback for @Yuriy about the preferred way of their choice of spec to ingest the CDS models: Open-API/gRPC. Investigate expressing the model in TOSCA (SDC CSAR).
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 wayfrom CLAMP to pass it along to CDSso 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 betakentaken → driven by CDS action and target-type in Operational Policy modelMapping between CLAMP --> Operational Model --> CDS input params
- Deprecating
Mark old APPC LCM API for deprecation.We can leverageLeveraging 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 - Integration tests, Testsuite update as a stretch goal (Abdelmuhaimen Seaudi )