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 so there is an ongoing discussion on it.
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:
- Will result in un-unified modifications (oom charts will pull from docker, but integration will continue to pull from nexus).
- 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
Do we actually need all those tags. 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?
| Project | Status | Tracked by |
|---|---|---|
| ci-management | The patches that add the global templates are merged. Only calls to these templates will be needed from now on for each project | CIMAN-217 |
| policy | Base and common images are now multiarch. The patches for the rest of the images are in review. | POLICY-1997 |
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):
- RELENG + ONAP + MULTIARCH: Schedule a call to plan the migration → 1 hr
- 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)
- ONAP + RELENG: Add global-jjb jobs in project yaml files. → 20 mins
- ONAP + RELENG + MULTIARCH: Test jobs and address any issues → Best case scenario 2 hr
- Verify that the right artifacts were produced and pushed into DockerHub -> 1 hr
- Attempt to run multi-architecture pulls and make sure DockerHub calls the right manifest -> 1 hr
- Functional tests? Scope and ETA need to be defined by tech team.
- ONAP: Confirm dependencies and needed images appear in Docker Hub. → 20 min
- 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.