This page will capture the design of thePolicy Update Notifications on Dmaap notifications of policy updates. This work is related to the functional requirements from Control Loop subcommittee: Policy Update Notifications.

POLICY-1840 - Getting issue details... STATUS 



   deployed-policies:
    - 
     policy-type: onap.policies.monitoring.cdap.tca.hi.lo.app
     policy-type-version: 1.0.0
     policy-id: onap.scaleout.tca
	 policy-version: 2.0.0
     success-count: 3
     failure-count: 0
   undeployed-policies:
    - 
     policy-type: onap.policies.firewall
     policy-type-version: 1.0.0
	 policy-id: onap.firewall.tca
	 policy-version: 6.0.0
     success-count: 3
     failure-count: 0



  1. policy-id was initial approach
  2. matchable filters was introduced later


  - per team meeting: 

  • For Policy Update - need to add complexity of multiple PDP groups. How does the client know which group?
    • Agree to just get the first cut done and address this later. Perhaps in G Release.


Options for Decision API calls:


{
  "ONAPName": "DCAE",
  "ONAPComponent": "PolicyHandler",
  "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
  "action": "configure",
  "resource": {
     "policy-type": "onap.policies.monitoring.cdap.tca.hi.lo.app"
  }
}


{
  "ONAPName": "DCAE",
  "ONAPComponent": "PolicyHandler",
  "ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
  "action": "configure",
  "resource": {
      "policy-id": [
        "onap.scaleout.tca",
        "onap.restart.tca"
        ]
  }
}


Can also use abbrev=true to get abbreviated results:

/policy/pdpx/v1/decision?abbrev=true




  • No labels

9 Comments

  1. Jim Hahn

    The current proposal is to add PDP/policy records to the DB.  Each record would have a state, perhaps having one of the following values:

    • ADDING - the policy is currently being pushed to the PDP
    • ADDED - the policy has been successfully pushed to the PDP
    • ADD-FAILED - failed to push to policy to the PDP
    • DELETING - the policy is currently being undeployed from the PDP
    • DELETED - the policy has been deleted from the PDP (this may not be a real state, as it will likely be indicated by simply deleting the record)
    • DELETE-FAILED - failed to undeploy the policy from the PDP

    When CLAMP deploys (or undeploys) a policy, once all the records for all of the PDPs have been updated (whether success or failure), a notification will be generated.  The notification will contain:

    • Policy id & version
    • action: "deployed" or "undeployed"
    • status:
      • SUCCESS - action succeeded on all PDPs
      • FAILURE - action failed on all PDPs
      • PARTIAL - action succeeded on some PDPs, but failed on others

    Queries can be performed at any time and will return:

    • inProgress: number of PDPs for which the action is still in progress
    • status: same as for the "notification" message, though it only applies to the PDPs that are not still in progress

    Queries may be supported for an individual policy, for a PDP Group/Subgroup pair, for an entire PDP Group, or across all PDP groups.  Initially, we may only support one of these options.

  2. Jim Hahn

    Pushed up a review with the following notification structure:

    added-policies:
-
  policy-type:
    name: onap.policies.monitoring.cdap.tca.hi.lo.app
    version: 1.0.0
  policy-id:
    name: onap.scaleout.tca
    version: 2.0.0
  success-count: 3
  failure-count: 0
  incomplete-count: 0
deleted-policies:
-
  policy-type:
    name: onap.policies.monitoring.cdap.tca.hi.lo.app
    version: 1.0.0
  policy-id:
    name: onap.scaleout.tca
    version: 1.0.0
  success-count: 3
  failure-count: 0
  incomplete-count: 0

  3. Jim Hahn

    The DMaaP topic name on which the notifications will be published is: POLICY-NOTIFICATION

  4. Vijay Venkatesh Kumar

    Based on discussion, today policy_type should be added in the notification structure. Also matchable criteria will be useful for DCAE PolicyHandler. From earlier discussion, Pam agreed to support this on the notification as well.


    1. Pamela Dragosh

      We will have to discuss the matchable criteria, as I don't think we have any of those details anywhere. This is a general solution for all our clients so the PAP is the only component that knows when policies are deployed/undeployed. It has no knowledge of "matchable". Please remind me of what/where this detail is.

  5. Jim Hahn

    Latest proposed notification structure:

    added-policies:
-
  policy-type: onap.policies.monitoring.cdap.tca.hi.lo.app
  policy-type-version: 1.0.0
  policy-id: onap.scaleout.tca
  policy-version: 2.0.0
  success-count: 3
  failure-count: 0
  incomplete-count: 0
deleted-policies:
-
  policy-type: onap.policies.monitoring.cdap.tca.hi.lo.app
  policy-type-version: 1.0.0
  policy-id: onap.scaleout.tca
  policy-version: 1.0.0
  success-count: 3
  failure-count: 0
  incomplete-count: 0

    1. Alex Shatov

      Thank you for making the definition of policy-id consistent between the notification API and decision API of PDP

      ---

      From what I understand, the policy-version is a number that is auto-incremented by PAP/PDP, rather than a semver string and not even a stringified number. 

      policy-version: 2

      That is in contrast to policy-type-version: 1.0.0 that is a semver string and is provided to PAP/PDP by its client. 

      1. Jim Hahn

        A couple of clarifications:

        • PAP accepts either form of policy-version, 2 or 2.0.0.  However, in the notification, it will always be the fully specified form, 2.0.0.
        • PAP does not auto-increment the policy-version; it pushes, to the PDPs, whatever version was specified by CLAMP.  If no version is specified, then PAP pushes the policy with the maximum version.

  6. Jim Hahn

    The structure now matches what is shown at the top of this page.