Skip to end of metadata
Go to start of metadata

see Re: Policy Design and API Flow for Model Driven Control Loop - Draft for the PDP API changes in Dublin R4

Intentions and requirements

  1. make API on PAP/PDP to use the consistent structures on all operations
  2. simplify the usage of PAP/PDP API
  3. for transition period of about 1 year both the old and the new APIs to be maintained by PAP/PDP
  4. CLAMP to use only the new API of PAP in Dublin R4
  5. DCAE-Controller is requested to use both the new and the old APIs of PDP for the transition period to avoid breaking the existing components

PDP API change that impacts DCAE-Controller

  1. Design of the new API on PAP/PDP is in progress
  2. Only a subset of the new PAP/PDP API is designed and is in the draft status.
  3. The new API changes the following aspects (everything)
    1. url
    2. request structures are totally redesigned.  New field names, new placements, many fields are removed, no obvious mapping between the old and the new fields. 
    3. response structures are totally redesigned.  New field names, new placements, many fields are removed, no obvious mapping between the old and the new fields. 
    4. the structure of the policy config that contains the actual policy is changed to match the policy-model.

The impact to DCAE-Controller is MAJOR and the PDP API design is far from being usable

replacement of (POST /getConfig) with the new Policy Decision API - Getting Policy Decisions (POST /decision/v1/) for a single policy_id

The current version of /decision/v1/ only provides a single policy request-response for the single policy_id (= onap.vfirewall.tca):

http:{url}:{port}/decision/v1/ POST
Content-Type: application/yaml
Accepts: application/json
subject: DCAE
action: configure
    policy_id: onap.vfirewall.tca

# Return Output
HTTP/1.1 200 OK
Content-Type: application/json
    "onap.vfirewall.tca": {
        "type": "",
        "properties": {
            "domain": "measurementsForVfScaling",...

Getting multiple policies and varying number of policies with the new PDP API - is not provided

This feature is heavily used by and needed to DCAE-Controller because it has to go from multiple policies in PDP to multiple policies attached to multiple components in DCAE in as few http queries as possible

Comparison with the POST /getConfig

  1. policy_id is the new field in PDP API that was not used before.  DCAE-Controller had to introduce the policy_id term to identify the single policy regardless of its version.  No complaints here
  2. only a single string value is provided in the new PDP API for the policy_id
    1. the old PDP API had a way to use the regular expression in the policyName field to request multiple policies at a time.  
      1. This feature of the regular expression matching is heavily used by DCAE-Controller to send a single or as few requests to PDP as possible when querying for the latest policies that are attached to the components in DCAE
  3. response contains a dictionary from policy_id value to the config structure that contains the actual policy instance.  No header information is provided in the response that affects
    1. it is not obvious from looking at the response to explain what is the key and what is the value in the dictionary. 
    2. it is not clear what the response would look like if no policy is found for the policy_id. 
      1. Preferably we would need to avoid relying on the absence of data in response to identify the absence of the record since the absence might be caused by other reasons as well like database not available at all or any other error conditions, etc.
    3. no policyVersion is provided in response header for the policy_id. 
      1. The policyVersion is used by many places in DCAE-Controller to figure out
        1. whether the policy is changed in PDP
        2. whether the wave of changes has to be propagated through the DCAE-Controller,
        3. whether the policy record has to be updated in consul-kv
        4. whether the component needs to be push-notified about the update. 
      2. Not having the policyVersion in the response makes it unclear how
    4. there are no fields that were provided before that were used for matching of the policy to the policy-filter(s) optionally attached to the DCAE component.  The policy-filter currently is a copy-paste of the /getConfig request
  4. Therefore using the new PDP API as it is design at the moment will break all the behavior of DCAE-Controller and the components

High level view on the changes of the DCAE-Controller to accommodate the new API of PDP

It seems that to selectively consume both the new and the old PDP APIs by DCAE-Controller the new node types need to be introduced to the blueprint of the components.  Suggested node types could be as follows

  1. dcae.nodes.policy.v2 can be derived from the current dcae.nodes.policy
    1. having the new name with v2 of the node type will indicate to use the new PDP API to retrieve policy from the PDP.  This way DCAE-Controller can slowly migrate the components from the old PDP API to the new PDP API over time
    2. the new type will be mutually exclusive in the blueprint to avoid the confusion for having the same policy in two formats. 
      1. We have to enforce the mutual exclusiveness during the blueprint generation
      2. if blueprint would still contain the mix
        1. The suggestion is to use only the new policy structures (v2) on all the policies attached to the component as soon as at least one policy node type is of v2. 
        2. However, that would require some ugly coding and re-retrieving of policies on gathering the policies to the component...
    3. the v2 node type can contain both the policy_id and the policy_model_id since this is the new type anyway
  2. dcae.nodes.policies.v2 can be derived from the current dcae.nodes.policies
    1. it is not clear how this type should be modeled since there is no matching PDP API

It seems that all the chain of platform components (policy-handler, deployment-handler, policy-plugin, onap-dcae-dcaepolicy-lib) in DCAE-Controller will have to be heavily changed to accommodate the new node types and use the new PDP API along with the old PDP API. 

Besides, each service component will have to be changed as well to consume the new policy structures.

Open issues

  1. It is not clear on whether and how the web-socket API is changing
    1. the web-socket API contains the policyName, policyVersion, as well as the matchingConditions used for matching to the policy-filters
    2. it is not clear how the policy-update notification can be matched to the new PDP API

  • No labels


  1. Following is current entry made into consul after PH fetch (based on R3 version)

    The above is stored under consul under following folder of servicecomponent - s6fa2f68f1e7a461697901d36ab3d8ee8-dcaegen2-analytics-tca%3Apolicies/items/CLAMPvLoadBalancerMS_v1_0_vLoadBalancerMS0.Config_MS_ClosedLoop_50206ddf_20be_11e9_b789_02179bd2eee3_TCA_1d13unw

    The TCA container process specifically reads - policies.items[0].config.content.tca_policy  to extract the configuration update.

    If there is change in this content to be written out part of new flow - that's need to be specified

  2. Hi,

    I have deployed El Alto release. I have deployed dcaegen2 module. I see all of the pods are running, but one of the pod dev-dcaegen2-dcae-policy-handler-66d84cc979-7mn92 is in INIT state. When checked the logs it gives below message.

    ubuntu@rancher:~$ kubectl logs -n onap dev-dcaegen2-dcae-policy-handler-66d84cc979-7mn92 -c dcae-policy-handler-readiness
    2019-09-03 12:54:15,701 - INFO - Checking if dcae-deployment-handler is ready
    2019-09-03 12:54:16,085 - INFO - dcae-deployment-handler is not ready.
    2019-09-03 12:56:40,419 - INFO - Checking if dcae-deployment-handler is ready
    2019-09-03 12:56:40,766 - INFO - dcae-deployment-handler is ready!
    2019-09-03 12:56:40,770 - INFO - Checking if consul-server is ready
    2019-09-03 12:56:41,132 - INFO - consul-server is ready!
    2019-09-03 12:56:41,132 - INFO - consul-server is ready!
    2019-09-03 12:56:41,132 - INFO - consul-server is ready!
    2019-09-03 12:56:41,137 - INFO - Checking if pdp is ready
    2019-09-03 12:56:46,477 - INFO - Checking if pdp is ready
    2019-09-03 12:56:51,805 - INFO - Checking if pdp is ready
    2019-09-03 12:56:57,159 - INFO - Checking if pdp is ready

    ubuntu@rancher:~$ kubectl get pods -n onap | grep dcaegen2
    dev-dcaegen2-dcae-bootstrap-78f9fbdf96-nfq9c 1/1 Running 0 28h
    dev-dcaegen2-dcae-cloudify-manager-7c94d4c59-tvnxd 1/1 Running 0 28h
    dev-dcaegen2-dcae-config-binding-service-7498b55fc8-mczqc 4/4 Running 0 28h
    dev-dcaegen2-dcae-dashboard-54db568679-jzc2z 2/2 Running 0 28h
    dev-dcaegen2-dcae-dashboard-pg-0 1/1 Running 0 28h
    dev-dcaegen2-dcae-dashboard-pg-1 1/1 Running 0 28h
    dev-dcaegen2-dcae-dashboard-pgpool-77987784cd-8lcdn 1/1 Running 0 28h
    dev-dcaegen2-dcae-dashboard-pgpool-77987784cd-r8wdx 1/1 Running 0 28h
    dev-dcaegen2-dcae-db-0 1/1 Running 0 28h
    dev-dcaegen2-dcae-db-1 1/1 Running 0 27h
    dev-dcaegen2-dcae-deployment-handler-98dc55c48-ht8ms 2/2 Running 0 28h
    dev-dcaegen2-dcae-healthcheck-86dc467ff-nnw2j 1/1 Running 0 28h
    dev-dcaegen2-dcae-inv-pg-0 1/1 Running 0 28h
    dev-dcaegen2-dcae-inv-pg-1 1/1 Running 0 27h
    dev-dcaegen2-dcae-inv-pgpool-6755d89b6b-dgdk8 1/1 Running 0 28h
    dev-dcaegen2-dcae-inv-pgpool-6755d89b6b-q2w7s 1/1 Running 0 28h
    dev-dcaegen2-dcae-inventory-api-5b5959bb-pscbv 1/1 Running 0 28h
    dev-dcaegen2-dcae-pgpool-5fb4bbb6bb-5chdl 1/1 Running 0 28h
    dev-dcaegen2-dcae-pgpool-5fb4bbb6bb-shrnv 1/1 Running 0 28h
    dev-dcaegen2-dcae-policy-handler-66d84cc979-7mn92 0/2 Init:0/3 2 28h
    dev-dcaegen2-dcae-redis-0 1/1 Running 0 28h
    dev-dcaegen2-dcae-redis-1 1/1 Running 0 27h
    dev-dcaegen2-dcae-redis-2 1/1 Running 0 27h
    dev-dcaegen2-dcae-redis-3 1/1 Running 0 27h
    dev-dcaegen2-dcae-redis-4 1/1 Running 0 27h
    dev-dcaegen2-dcae-redis-5 1/1 Running 0 27h
    dev-dcaegen2-dcae-servicechange-handler-79b6969547-j282p 1/1 Running 0 28h