Uploaded image for project: 'Service Orchestrator'
  1. Service Orchestrator
  2. SO-3432

SO does not update ipv4-oam-address in AAI

XMLWordPrintable

      Our automation scenario fails because ipv4-oam-address is not being patched in aai.

       

      From my understanding this fails because UpdateVnfIpv4OamAddress step in CreafeVfModuleBB flow is either not being executed, or the value oamManagementV4Address is null. I spend quite some time comparing what is happening in Frankfurt and Guilin, and am not able to track this down. I compared openstack-adapter logs, bpmn logs, I took a peek at the CreateVfModule flow using comunda modeler in both Frankfurt and Guiling version, I was also trying to find any difference using so-monitoring tool. I am not able to spot why this happens.

       

      I see no difference or extra exceptions (apart from already fixed SO-3402 - thanks) before the issue happens - provisioning flow eventually fails for me because of the vnf ip is missing, but apart from that the only difference I see is that PATCH request similar to the one below, but with ipv4-oam-address - is present on Frankfurt, it is missing on Guilin. Aforementioned IP address is present in openstack-adapter logs for both Frankfurt and Guilin.

       

      I am new to SO, can you please help me solve this by either pointing out that something has changed, or maybe some hints on how to track this and where I can check this?

       

      2020-12-17T08:57:00.866Z|2020-12-17T08:57:01.076+0000|1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a||qtp257608605-32|aai-resources|/aai/v21/network/generic-vnfs|UNKNOWN|||||DEBUG||10.42.1.50|435|aai-resources|||||||||co=UNKNOWN:{"transactionId":"1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a","status":"200","rqstDate":"201217-08:57:00:425","respDate":"201217-08:57:01:076","sourceId":"UNKNOWN:1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a","resourceId":"https://aai.onap:8443/aai/v21/network/generic-vnfs/generic-vnf/72010acd-cc3c-4c8a-a94c-578a1feaf482","resourceType":"PATCH","rqstBuf":"{\"ID\":\"0-aai-resources-201217-08:57:00:425-46236\",\"Http-Method\":\"POST\",\"Content-Type\":\"application/merge-patch+json\",\"Headers\":\"{X-RequestID=[1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a], X-AAI-SSL-Client-C=[], X-AAI-SSL=[1], X-AAI-SSL-Issuer=[], User-Agent=[Apache-CXF/3.3.3], X-AAI-SSL-Client-ST=[], X-AAI-SSL-Client-OU=[], Authorization=[Basic YWFpQGFhaS5vbmFwLm9yZzpkZW1vMTIzNDU2IQ==], X-AAI-SSL-Client-CN=[], X-InvocationID=[c55d99c3-5ed7-4a5c-a615-7bdbd3866443], X-ECOMP-RequestID=[1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a], Content-Length=[84], Content-Type=[application/merge-patch+json], X-AAI-SSL-Client-NotBefore=[], X-FromAppId=[MSO], Accept=[application/json], X-AAI-SSL-Client-Verify=[0], X-Forwarded-Proto=[https, https], Connection=[close], Host=[aai.onap:8443], Pragma=[no-cache], X-Forwarded-Port=[52406], X-AAI-SSL-Client-DN=[], X-ONAP-PartnerName=[UNKNOWN], X-HTTP-Method-Override=[PATCH], Cache-Control=[no-cache], X-AAI-SSL-Client-NotAfter=[], X-Forwarded-For=[10.42.3.45], X-TransactionId=[,1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a], X-AAI-SSL-ClientCert-Base64=[], X-ONAP-RequestID=[1b56d685-a2d0-43e7-a0e9-b7a5f8b4404a], X-AAI-SSL-Client-O=[], X-AAI-SSL-Client-L=[]}\",\"Payload\":\"{\\\"vnf-id\\\":\\\"72010acd-cc3c-4c8a-a94c-578a1feaf482\\\",\\\"orchestration-status\\\":\\\"Configure\\\"}\"}","respBuf":"{\"ID\":\"0-aai-resources-201217-08:57:00:425-46236\",\"Content-Type\":null,\"Response-Code\":200,\"Headers\":\"{vertex-id=[282656], Content-Type=[application/json], X-AAI-TXID=[0-aai-resources-201217-08:57:00:425-46236]}\",\"Entity\":\"\"}"}
      
      

       

            sharankr2018 sharankr2018
            mszalus mszalus
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: