Page History

...

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

#
# Return Output
#
 
HTTP/1.1 200 OK
Content-Type: application/json
{
    "onap.vfirewall.tca": {
        "type": "onap.policy.monitoring.cdap.tca.hi.lo.app",
        "properties": {
            "domain": "measurementsForVfScaling",...
}}}

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 policyVersionis 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

...