View file name Onap multiarch.pdf height 250
Overall status and progress
...
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.. 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:
...
3. Stop pushing the release tag during development cycleDo we actually need all those tags.
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?
...
- 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
| 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 |
...