Uploaded image for project: 'Logging analytics'
  1. Logging analytics
  2. LOG-985

pomba data-router image ambiguity procedure for Dublin MR manifest sync

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Won't Do
    • Icon: Medium Medium
    • None
    • None

      see https://wiki.onap.org/display/DW/TSC+2019-02-21

      Discuss docker-manifest.csv and oom values.yaml sync procedures

      1) shared docker images - conflict/ambiguity - is a 1:m relationship not a 1:1

      example: onap/data-router,1.3.3

      https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n39

      There may be a case like there was for the 3.0.0-ONAP tag where AAI and POMBA vary - AAI took 1.3.2, pomba stayed with 1.3.1 because of issues deploying 1.3.3

      The current manifest does not always account for 2 projects using different versions of common images

      Result:

      integration is running with 1.3.3 across both projects before both projects themselves have upgraded.

      If you apply the manifest - it will overwrite both of these versions - but we may want a variance.

      we get

      aai:
      image: onap/data-router:1.3.3
      pomba:
      image: onap/data-router:1.3.3
      we may want

      aai:
      image: onap/data-router:1.3.3
      pomba:
      image: onap/data-router:1.3.2

      2) docker version responsibility

      PTLs should be responsible for their docker image versions in OOM - however since the manifest drives the version truth some images are updated at the last minute during the manifest/oom sync - these should be better coordinated/tested with the team

      Yesterday there was a last minute change to sync POMBA with AAI because the manifest lists the common data-router version as 1.3.3. Regression testing may have been done for POMBA under 1.3.3 but the POMBA team was not aware of the new version - Ideally the project team themselves test new docker versions to be sure it works. Changing the image tag at the last minute before 3.0.1-ONAP is tagged is problematic - as I am kind of doing this blind without a fully vFW post audit (HC and CD deploy were ok) - this has happened twice so far.

      3.0.0 = 1.3.1 reverted from 1.3.2 auto-up-rev for LOG-932

      LOG-932 - pomba-data-router pod does not come up in Casablanca MR CLOSED
      https://git.onap.org/oom/tree/kubernetes/pomba/charts/pomba-data-router/values.yaml?h=3.0.0-ONAP#n30

      3.0.1 = 1.3.3

      dup

      INT-901 - Bring OOM image version in sync with docker-manifest.csv for Casablanca MR IN PROGRESS
      submitted 20190220:2000EST for CMR

      LOG-982 - Align POMBA data-router from 1.3.1 (pre 3.0.0) with 3.0.1 aai change under 1.3.3 SUBMITTED
      https://git.onap.org/oom/tree/kubernetes/pomba/charts/pomba-data-router/values.yaml?h=casablanca#n30

      example

      I recommend we work out the details of MRs before we do the DMR.

      Fix #2

      Another option would be to duplicate/label common images so they can vary independently - but this would defeat the offline installer and the CIA initiative - but would follow what dmaap does for the DR

            yong_chen yong_chen
            michaelobrien michaelobrien
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: