Page Comparison

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 separating the two in two different dockerhub repositories. The proposed solution is . 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

...