...
However now all the snapshot and staging images are in the same place as the release images so there is an ongoing discussion on separating the two in two different dockerhub repositories.
The proposed solution is
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?
| 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
...