POLICY-2899 - Getting issue details... STATUS


Summary:

Develop a solution for storing information when policies are deployed or undeployed through the PAP deploy APIs.

What will this be used for?

For checking when policies were deployed or undeployed - mostly for this action as it deletes the policy - and these changes are not tracked anywhere.


Endpoints used for deploy/undeploy:


Ongoing proposal:

models:

Have a new entity/table for storing the policy (name and version), pdp group and type, action (DEPLOYMENT/UNDEPLOYMENT) and timestamp of action.

  • User is also added on this for future reference when policy can have more users to access the services.

Have dao methods for creating and retrieving row(s) from aforementioned table.



models-pap

/policy-models-pap/src/main/java/org/onap/policy/models/pap/concepts/PolicyAudit.java - concept

/policy-models-pap/src/main/java/org/onap/policy/models/pap/persistence/concepts/JpaPolicyAudit.java - persistence entity

/policy-models-pap/src/main/java/org/onap/policy/models/pap/persistence/provider/PolicyAuditProvider.java - dao actions


tests and a persistence.xml file would be added to src/test


policy-pap:

have the endpoints for deploy/undeploy updated with the call for storing the process for tracking.

Possibly have methods for creating a track object for each deploy/undeploy on /pap-main/src/main/java/org/onap/policy/pap/main/rest/SessionData.java

  • there are two methods - trackDeploy and trackUndeploy - where the call for new method(s) would be added
  • have a map list of audit (similar to create/update groups)
  • the new method(s) would create a track object and add to an auditList for when the updateDb method is called

have a new endpoint to get the audit on policy (need to confirm which fields would be used for filter - assuming pdp group or policy name/version, and begin/end times)


Questions:


  • How many records could this return? may want to force a limit on the record count and maximum time window. may want to require starting timestamp
    • limit set on API: 10
    • limit set on models provider: 50 (there's a validation to check if number is over models limit) - should we keep this and this range (10-50)
  • Does the table need to be cleaned up at times?
  • what sort of filters should be allowed? 
    • none
    • pdpGroup
    • policy (name and version)
    • group and policy (name and version)
  • Should still use timestamp on filter?
  • Should we filter by actions? (i.e. want to see only deployments)
  • Failure (result of a DEPLOY) is to be tracked as well?



  • No labels

4 Comments

  1. Jim Hahn

    Oh, you mean that we need to modify the existing methods so that they'll store the audit information in the DB.  Got it, thanks.

  2. Jim Hahn

    "PdpPolicyDeploymentAudit" works, even if it is a bit lengthy.

    The approach for policy-pap makes sense.  Don't remember the details, but it's possible might also need to update the code that detects failures in PDP responses that cause a policy to be automatically undeployed - not sure, the updates to SessionData may capture this case, too.

    1. Adheli Tavares

      Yeah, I saw there's a collection DB update, so I might have to have two different flows from when there's a deploy (check if it was succesfull after notification) and one for undeploy (when the policies are marked for deletion).

  3. Ram Krishna Verma

    Created the swagger file for PAP API changes - PAP REST API changes for Istanbul release