Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. vCpeResCust custom workflow: 
    1. vcperescust service failed to distribute from SDC to SO for several reasons:
      1. For the vBRG EMU allotted resource, we first designed it using "Allotted Resource" subcategory, SO did not accept it. We then re-designed it using "Tunnel XConn" subcategory, SO accepted it. But it is not clear if this will cause problem later on.
      2. Each VF in the service is assigned a customizationUUID. That ID is not changed unless the VF is removed and recreated in SDC composition. SO throws an error if a service being redistributed includes a component with the same customizationUUID. Basically it checks the DB to see if the ID already exist, if yes then reports a duplicate customizationUUID error in /var/log/ecomp/MSO/ASDC.../msodebug.log. If we need to change and redistribute a service, the workaround is to delete each component and add back in.
      3. Solutions:
        1. We recreated the mso container and db container to start with empty DB tables. Note that only recreate the DB does not work as it will lack the camunda records, which are created when the mso container is initialized.
        2. To recreate, delete the mso container, change /opt/test_lab/deploy.sh to enable "--force-recreate mariadb". Remember to turn it back off afterwards.
        3. After new mso container is created, do the following.
          1. Run cpjars to copy the updated jar and war files into the docker. This is not needed if docker is updated.
          2. Restart the container to load the above files.
          3. Run cpproperties to copy the properties in mso.bpmn.urn.properties, mso.sdnc.properties. Note that this properties got reset each time the container is restarted. This is not needed once docker is updated. But to enable debug log for specific items, some of the flags in mso.bpmn.urn.properties are still needed.
    2. SNIRO is updated to meet the needs of the Homing query. Now the data to be loaded to SNIRO is this (updated 11/7)sniro.json. Note that some of the contents needs to be updated, such as gmux uuid.
    3. To clear the sniro content: GET http://robot:8080/__admin/mappings/reset
    4. To check sniro logs: docker logs -f sniroemulator
    5. TunnelXConn flow queried AAI using the vCpeResCust service instance uuid but got nothing. This was caused by racing condition: it was too soon to query after the service flow put the same uuid in AAI. The temp solution is to let the flow sleep for 30 seconds before performing query. It worked. Note that sleeping for 5 seconds was proven to be insufficient.

...