CDS actor support in Policy

1. Overview of CDS Actor support in Policy

ONAP Policy Framework now enables Controller Design Studio (CDS) as one of the supported actors. This allows the users to configure Operational Policy to use CDS as an actor to remedy a situation.

Behind the scene, when an incoming event is received and validated against rules, Policy uses gRPC to trigger the CBA (Controller Blueprint Archive: CDS artifact) as configured in the operational policy and providing CDS with all the input parameters that is required to execute the chosen CBA.

2. Objective

The goal of the user guide is to clarify the contract between Policy and CDS so that a CBA developer can respect this input contract towards CDS when implementing the CBA.

3. Contract between Policy and CDS

Policy upon receiving an incoming event from DCAE fires the rules and decides which actor to trigger. If the CDS actor is the chosen, Policy triggers the CBA execution using gRPC.

The parameters required for the execution of a CBA are internally handled by Policy. It makes uses of the incoming event, the operational policy configured and AAI lookup to build the CDS request payload.

3.1 CDS Blueprint Execution Payload format as invoked by Policy

Below are the details of the contract established between Policy and CDS to enable the automation of a remediation action within the scope of a closed loop usecase in ONAP.

The format of the input payload for CDS follows the below guidelines, hence a CBA developer must consider this when implementing the CBA logic. For the sake of simplicity a JSON payload is used instead of a gRPC payload and each attribute of the child-nodes is documented.

3.1.1 CommonHeader

The “commonHeader” field in the CBA execute payload is built by policy.

“commonHeader” field name

type

Description

subRequestId

string

Generated by Policy. Is a UUID and used internally by policy.

requestId

string

Inserted by Policy. Maps to the UUID sent by DCAE i.e. the ID used throughout the closed loop lifecycle to identify a request.

originatorId

string

Generated by Policy and fixed to “POLICY”

3.1.2 ActionIdentifiers

The “actionIdentifiers” field uniquely identifies the CBA and the workflow to execute.

“actionIdentifiers” field name

type

Description

mode

string

Inserted by Policy and fixed to “sync” presently.

blueprintName

string

Inserted by Policy. Maps to the attribute that holds the blueprint-name in the operational policy configuration.

blueprintVersion

string

Inserted by Policy. Maps to the attribute that holds the blueprint-version in the operational policy configuration.

actionName

string

Inserted by Policy. Maps to the attribute that holds the action-name in the operational policy configuration.

3.1.3 Payload

The “payload” JSON node is generated by Policy for the action-name specified in the “actionIdentifiers” field which is eventually supplied through the operational policy configuration as indicated above.

3.1.3.1 Action request object

The “$actionName-request” object is generated by CDS for the action-name specified in the “actionIdentifiers” field.

The “$actionName-request” object contains:

  • a field called “resolution-key” which CDS uses to store the resolved parameters into the CDS context

  • a child node object called “$actionName-properties” which holds a map of all the parameters that serve as inputs to the CBA. It presently holds the below information:

    • all the AAI enriched attributes

    • additional parameters embedded in the Control Loop Event format which is sent by DCAE (analytics application).

    • any static information supplied through operational policy configuration which is not specific to an event but applies across all the events.

The data description for the action request object fields is as below:

  • Resolution-key

“$actionName-request” field name

type

Description

resolution-key

string

Generated by Policy. Is a UUID, generated each time CBA execute request is invoked.

  • Action properties object

“$actionName-properties” field name

type

Description

[$aai_node_type.$aai_attribute]

map

Inserted by Policy after performing AAI enrichment. Is a map that contains AAI parameters for the target and conforms to the notation: $aai_node_type.$aai_attribute. E.g. for PNF the map looks like below.

{
  "pnf.equip-vendor":"Vendor-A",
  "pnf.ipaddress-v4-oam":"10.10.10.10",
  "pnf.in-maint":false,
  "pnf.pnf-ipv4-address":"3.3.3.3",
  "pnf.resource-version":"1570746989505",
  "pnf.nf-role":"ToR DC101",
  "pnf.equip-type":"Router",
  "pnf.equip-model":"model-123456",
  "pnf.frame-id":"3",
  "pnf.pnf-name":"demo-pnf"
}

data

json object OR string

Inserted by Policy. Maps to the static payload supplied through operational policy configuration. Used to hold any static information which applies across all the events as described above. If the value of the data field is a valid JSON string it is converted to a JSON object, else will be retained as a string.

[$additionalEventParams]

map

Inserted by Policy. Maps to the map of additionalEvent parameters embedded into the Control Loop Event message from DCAE.

3.1.4 Summing it up: CBA execute payload generation as done by Policy

Putting all the above information together below is the REST equivalent of the CDS blueprint execute gRPC request generated by Policy.

REST equivalent of the gRPC request from Policy to CDS to execute a CBA.

curl -X POST \
  'http://{{ip}}:{{port}}/api/v1/execution-service/process' \
  -H 'Authorization: Basic Y2NzZGthcHBzOmNjc2RrYXBwcw==' \
  -H 'Content-Type: application/json' \
  -H 'cache-control: no-cache' \
  -d '{
    "commonHeader":{
        "subRequestId":"{generated_by_policy}",
        "requestId":"{req_id_from_DCAE}",
        "originatorId":"POLICY"
    },
    "actionIdentifiers":{
        "mode":"sync",
        "blueprintName":"{blueprint_name_from_operational_policy_config}",
        "blueprintVersion":"{blueprint_version_from_operational_policy_config}",
        "actionName":"{blueprint_action_name_from_operational_policy_config}"
    },
    "payload":{
        "$actionName-request":{
            "resolution-key":"{generated_by_policy}",
            "$actionName-properties":{
                "$aai_node_type.$aai_attribute_1":"",
                "$aai_node_type.$aai_attribute_2":"",
                .........
                "data":"{static_payload_data_from_operational_policy_config}",
                "$additionalEventParam_1":"",
                "$additionalEventParam_2":"",
                .........
            }
        }
    }
}'

3.1.5 Examples

Sample CBA execute request generated by Policy for PNF target type when “data” field is a string:

curl -X POST \
  'http://{{ip}}:{{port}}/api/v1/execution-service/process' \
  -H 'Authorization: Basic Y2NzZGthcHBzOmNjc2RrYXBwcw==' \
  -H 'Content-Type: application/json' \
  -H 'cache-control: no-cache' \
  -d '{
    "commonHeader":{
        "subRequestId":"14384b21-8224-4055-bb9b-0469397db801",
        "requestId":"d57709fb-bbec-491d-a2a6-8a25c8097ee8",
        "originatorId":"POLICY"
    },
    "actionIdentifiers":{
        "mode":"sync",
        "blueprintName":"PNF-demo",
        "blueprintVersion":"1.0.0",
        "actionName":"reconfigure-pnf"
    },
    "payload":{
        "reconfigure-pnf-request":{
            "resolution-key":"8338b828-51ad-4e7c-ac8b-08d6978892e2",
            "reconfigure-pnf-properties":{
                "pnf.equip-vendor":"Vendor-A",
                "pnf.ipaddress-v4-oam":"10.10.10.10",
                "pnf.in-maint":false,
                "pnf.pnf-ipv4-address":"3.3.3.3",
                "pnf.resource-version":"1570746989505",
                "pnf.nf-role":"ToR DC101",
                "pnf.equip-type":"Router",
                "pnf.equip-model":"model-123456",
                "pnf.frame-id":"3",
                "pnf.pnf-name":"demo-pnf",
                "data": "peer-as=64577",
                "peer-group":"demo-peer-group",
                "neighbor-address":"4.4.4.4"
            }
        }
    }
}'

Sample CBA execute request generated by Policy for VNF target type when “data” field is a valid JSON string:

curl -X POST \
  'http://{{ip}}:{{port}}/api/v1/execution-service/process' \
  -H 'Authorization: Basic Y2NzZGthcHBzOmNjc2RrYXBwcw==' \
  -H 'Content-Type: application/json' \
  -H 'cache-control: no-cache' \
  -d '{
    "commonHeader":{
        "subRequestId":"14384b21-8224-4055-bb9b-0469397db801",
        "requestId":"d57709fb-bbec-491d-a2a6-8a25c8097ee8",
        "originatorId":"POLICY"
    },
    "actionIdentifiers":{
        "mode":"sync",
        "blueprintName":"vFW-CDS",
        "blueprintVersion":"1.0.0",
        "actionName":"config-deploy"
    },
    "payload":{
        "config-deploy-request":{
            "resolution-key":"6128eb53-0eac-4c79-855c-ff56a7b81141",
            "config-deploy-properties":{
                "service-instance.service-instance-id":"40004db6-c51f-45b0-abab-ea4156bae422",
                "generic-vnf.vnf-id":"8d09e3bd-ae1d-4765-b26e-4a45f568a092",
                "data":{
                    "active-streams":"7"
                }
            }
        }
    }
}'

4. Operational Policy configuration to use CDS as an actor

4.1 TOSCA compliant Control Loop Operational Policy to support CDS actor

A common base TOSCA policy type for defining an operational policy is documented below:

APEX PDP specific operational policy is derived from the common operational TOSCA policy type as defined in the link below: * https://gerrit.onap.org/r/gitweb?p=policy/models.git;a=blob;f=models-examples/src/main/resources/policytypes/onap.policies.controlloop.operational.common.Apex.yaml;h=54b69c2d8a78ab7fd8d41d3f7c05632c4d7e433d;hb=HEAD

Drools PDP specific operational policy is also derived from the common operational TOSCA policy type and is defined in the link below: * https://gerrit.onap.org/r/gitweb?p=policy/models.git;a=blob;f=models-examples/src/main/resources/policytypes/onap.policies.controlloop.operational.common.Drools.yaml;h=69d73db5827cb6743172f9e0b1930eca8ba4ec0c;hb=HEAD

For integration testing CLAMP UI can be used to configure the Operational Policy.

E.g. Sample Operational Policy definition for vFW usecase to use CDS as an actor:

tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
    policies:
    -   operational.modifyconfig.cds:
            type: onap.policies.controlloop.operational.common.Drools
            type_version: 1.0.0
            version: 1.0.0
            metadata:
                policy-id: operational.modifyconfig.cds
            properties:
                id: ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a
                timeout: 1200
                abatement: false
                trigger: unique-policy-id-1-modifyConfig
                operations:
                -   id: unique-policy-id-1-modifyConfig
                    description: Modify the packet generator
                    operation:
                        actor: CDS
                        operation: ModifyConfig
                        target:
                            targetType: VNF
                            entityId:
                                resourceID: bbb3cefd-01c8-413c-9bdd-2b92f9ca3d38
                        payload:
                            artifact_name: vfw-cds
                            artifact_version: 1.0.0
                            mode: async
                            data: '{"active-streams":"7"}'
                    timeout: 300
                    retries: 0
                    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
                controllerName: usecases

4.2 API to configure the Control Loop Operational policy

4.2.1 Policy creation

Policy API endpoint is used to create policy i.e. an instance of the TOSCA compliant Operational policy type. E.g. For vFW usecase the policy-type is “onap.policies.controlloop.operational.common.Drools”.

In the below rest endpoint, the hostname points to K8S service “policy-api” and internal port 6969.

curl POST 'https://{$POLICY_API_URL}:{$POLICY_API_SERVICE_PORT}/policy/api/v1/policytypes/onap.policies.controlloop.operational.common.Drools/versions/1.0.0/policies/operational.modifyconfig/versions/1.0.0' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: Basic aGVhbHRoY2hlY2s6ZmlyZWFudHNfZGV2QHBvbGljeSE=' \
-d '{$vfw-tosca-policy}

Note: In order to create an operational policy when using APEX PDP use the policy-type: “onap.policies.controlloop.operational.common.Apex”.

4.2.2 Policy deployment to PDP

Policy PAP endpoint is used in order to deploy the policy to the appropriate PDP instance. In the rest endpoint URI, the hostname points to the service “policy-pap” and internal port 6969.

curl POST 'https://{$POLICY_PAP_URL}:{$POLICY_PAP_SERVICE_PORT}/policy/pap/v1/pdps/deployments/batch' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Basic {$auth}' \
-d '{
    "groups": [
        {
            "name": "defaultGroup",
            "deploymentSubgroups": [
                {
                    "pdpType": "drools",
                    "action": "POST",
                    "policies": [{
                            "name": "operational.modifyconfig.cds",
                            "version": "1.0.0"
                        }]
                }
            ]
        }
    ]
}'

To view the configured policies use the below REST API.

curl GET 'https://{$POLICY_API_URL}:{$POLICY_API_SERVICE_PORT}/policy/api/v1/policytypes/onap.policies.controlloop.operational.common.Drools/versions/1.0.0/policies/operational.modifyconfig/versions/1.0.0' \
-H 'Accept: application/json' \
-H 'Authorization: Basic {$auth}'
curl --location --request GET 'https://{$POLICY_PAP_URL}:{$POLICY_PAP_SERVICE_PORT}/policy/pap/v1/pdps' \
-H 'Accept: application/json' \
-H 'Authorization: Basic {$auth}'