Page Comparison

Overall status and progress

The first images have been made multiarch and migrated to dockerhub (e.g https://hub.docker.com/u/onap/policy-base-alpine).

However now all the snapshot and staging images are in the same place as the release images. Decided in the PTL meeting from 22 Oct 2019 to go forth with solution #3

Solutions considered:

1. Put the images produced during development in a different dockerhub repository (e.g. https://hub.docker.com/u/onap-dev) than the release ones (https://hub.docker.com/u/onap/). This option implies:

• keep https://hub.docker.com/u/onap/ for releases only
• create another account (e.g. https://hub.docker.com/u/onap-dev) to store all the images used in development
• proxy the images stored in dockerhub onap-dev to nexus3 docker.snapshot repo ( in order to be consumed by integration tests )
• proxy the images stored in dockerhub onap to nexus3 docker.release
• oom helm charts will be updated to pull from dockerhub
• csit tests will be updated to pull from dockerhub

After further discussing the proposal to create a separate docker repo name for the development images, the feedback is that by creating a new docker user, we're basically renaming the images and this will create a new level of complexity that:

1. Will result in un-unified modifications (oom charts will pull from docker, but integration will continue to pull from nexus).
2. Will be difficult to track in the future

I also got the feedback from Morgan that there shouldn’t be any issue that the future release tag is in the docker repository.

2. Keep one single onap repo name and document which tag is the released one

We can do that by adding description to each image. Docker has an overview section for each repo, so we can use that as a way to officially clarify what is the latest stable tag (e.g. https://hub.docker.com/_/centos)

3. Stop pushing the release tag during development cycle

Full description of the proposal described in https://lists.onap.org/g/onap-discuss/topic/dockerhub_migration_and/34447632?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,34447632

Having for example policy-common-alpine:2.0.0-STAGING-latest or policy-common-alpine: 2.0.0-20190925094447  tags is self-explanatory and would not be confused for the released version; only policy-common-alpine:2.0.0 might create confusion. So besides documenting these images, do we still need to push this tag during development cycle, or can we simply remove it?

Input from the PTL meeting 3 Oct 2019:

• only the release jobs should produce the release tag
• discussion if this will impact the oom charts in any way: oom charts always point to the release tag, but is it the last finalized release or the future (in development) release?

Input from the PTL meeting 22 Oct 2019:

• the feedback from the community was that it would be OK to stop building the release tag in the daily jobs, and generate that tag only for through the release job
• cristinapauna will look into implementing this for the policy project

Proposed migration plan and stakeholders

Activities happening or that can happen right now:

• Docker templates:
• RELENG: Templates for Maven-Docker projects → COMPLETED
• RELENG: Templates for Docker only projects → COMPLETED
• ONAP: Define component dependency chart → PENDING (1 hr, maybe a PTL meeting task June 17?) By examining jenkins jobs logs We could make preliminary list here Docker images dependency list

Order of activities that will happen after TSC approval and after Nexus2 migration (starting July 22):

1. RELENG + ONAP + MULTIARCH: Schedule a call to plan the migration → 1 hr
2. ONAP + MULTIARCH: Modify any docker registries mentions in the code and any changes to the code to make it multi-ach friendly. → (2 hr mini avarage, Time depends on # of components per project)
3. ONAP + RELENG: Add global-jjb jobs in project yaml files. → 20 mins
4. ONAP + RELENG + MULTIARCH: Test jobs and address any issues → Best case scenario 2 hr
1. Verify that the right artifacts were produced and pushed into DockerHub -> 1 hr
2. Attempt to run multi-architecture pulls and make sure DockerHub calls the right manifest -> 1 hr
3. Functional tests? Scope and ETA need to be defined by tech team.
5. ONAP: Confirm dependencies and needed images appear in Docker Hub. → 20 min
6. ONAP + RELENG: Remove deprecated Nexus3 jobs → 20 min

Notice these are best case scenario situations. If any ONAP component requires an upgrade on the global-jjb jobs, such upgrade will need to be evaluated and developed by RELENG.

At all times (until #6 is executed), Nexus3 jobs could be running in parallel as long as the Nexus3 registries are still used.