Uploaded image for project: 'Policy Framework'
  1. Policy Framework
  2. POLICY-1918

PDP-D[vFWCL] JsonPath-based filtering not enforcing existance of fields in messages

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Medium Medium
    • El Alto Release
    • Dublin Release, El Alto Release
    • None
    • longevity lab

      Jayway JsonPath filtering introduced in Dublin release does not enforce existence of json fields.   Unwanted traffic is then inserted into the drools working session for event processing.   

      This behavior has been observed in the longevity lab in the context of vFWCL testing.   The issue is that APP-CL requests as looped by DMaaP pass the accept filter declared as:

      dmaap.source.topics.APPC-CL.events.org.onap.policy.appc.Response.filter=[?($.CommonHeader =~ /.*/ && $.Status =~ /.*/)]

      Note that the Status field is non-existent in the Request, nevertheless, filter processing accepts the DMaaP looped message as a "response" wrongly.

      {
        "CommonHeader": {
          "TimeStamp": 1563299804505,
          "APIver": "1.01",
          "RequestID": "8dfc8efd-817c-4a8e-ab19-7adee701275f",
          "SubRequestID": "1",
          "RequestTrack": [],
          "Flags": []
        },
        "Action": "ModifyConfig",
        "Payload": {
          "streams": {
            "active-streams": 5.0
          },
          "generic-vnf.vnf-id": "5179c359-f4f4-4fe9-a8db-24cfa4593926"
        }
      }
      
      

      This causes the message to abort the control loop.

          {
            "actor": "APPC",
            "operation": "ModifyConfig",
            "target": "Target [type=VNF, resourceId=9938b9c2-d784-473b-a7d9-c693745c3d33]",
            "start": 1563299804505,
            "end": 1563299805229,
            "subRequestId": "1",
            "outcome": "Failure_Exception",
            "message": "Policy was unable to parse APP-C response status code field."
          }
      
      

      The transaction is declared from policy as a FINAL failure in a notification.   Nevertheless, the APPC operations seemed to be performed successfully, since the request is being sent out, so from a black box perspective, vFW sunny days scenarios where APPC honors the ModifyConfig request would work as expected and not noticed, unless looking at the PDP-CL-MGT notification channel

       

      // code placeholder
      [2019-07-16T17:56:45.701+00:00|DMAAP-source-APPC-CL][IN|DMAAP|APPC-CL] {"Status":{"Value":"ACCEPTED","Code":"100"},"CommonHeader":{"OriginatorID":null,"SubRequestID":"1","RequestID":"8dfc8efd-817c-4a8e-ab19-7adee701275f","APIver":"1.01","TimeStamp":"1563299804505"},"Payload":{"streams":"{\\\"streams\\\": {\\\"active-streams\\\": 5}}","generic-vnf.vnf-id":"5179c359-f4f4-4fe9-a8db-24cfa4593926"}} 
      [2019-07-16T17:56:46.216+00:00|DMAAP-source-APPC-CL][IN|DMAAP|APPC-CL] {"Status":{"Value":"SUCCESS","Code":"400"},"CommonHeader":{"OriginatorID":null,"SubRequestID":"1","RequestID":"8dfc8efd-817c-4a8e-ab19-7adee701275f","APIver":"1.01","TimeStamp":"1563299804505"},"Payload":{"streams":"{\\\"streams\\\": {\\\"active-streams\\\": 5}}","generic-vnf.vnf-id":"5179c359-f4f4-4fe9-a8db-24cfa4593926"}}
      

       

            Unassigned Unassigned
            jhh jhh
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: