Hi folks, https://bugs.launchpad.net/starlingx/+bug/1854869 exposed an issue we have with some of our stx-built images. Certain images are referenced statically in platform-installed charts or files that use the master-centos-stable-latest tag, which is updated every time CENGN builds images, whereas the managed applications are able to use the specific image versions from build information. To address this, I'd like to propose a tag management system to complement the image build setup. Workflow: We decide we want to use new functionality introduced in recent build of image Y: * Create a Launchpad to update the image being used * Determine an appropriate version tag to use for the image. For example, if the main project of the image is based on an upstream repo, check the version associated with the SHA used for building the image. If the upstream commit is tagged as v2.2, the image tag to use could be stx.4.0-v2.2. Include this info in the Launchpad. * Update tag management config file, with Partial-Bug: XXXXXX referencing Launchpad. o Include reference to source build tag from loadbuild, using the versioned tag, such as master-centos-stable-20191203T153530Z.0 o Include reference to upstream commit, if appropriate o Include new requested tag * Once tag management config file update is reviewed and merged, tag management utility can be run - as part of CENGN loadbuild, maybe, or perhaps a separate CENGN job that can be triggered by the merge * Once the new tag has been pushed to the docker hub, a follow-up commit can be posted to update the chart or other reference to move to the new image tag, with Closes-Bug in commit message The only cases where we should see charts/manifests or other references to master-centos-stable-latest tag would be files that are inputs to the application build that would be replacing those tags with the specific versioned tags from the loadbuild and are therefore outside the scope of this procedure. This ensures a load is locked down to a specific version of such images, rather than floating to use latest, avoiding compatibility issues that may arise (as in the case of LP 1854869). Example tag management yaml file for stx-4.0: images: - name: docker.io/starlingx/k8s-cni-sriov src_build_tag: master-centos-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/dac417bd31ed36d455e94db4aabe59163... # Tag determined based on release tag associated with upstream commit tag: stx.4.0-v2.2 - name: docker.io/starlingx/k8s-plugins-sriov-network-device src_build_tag: master-centos-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/dac417bd31ed36d455e94db4aabe59163... # Tag determined based on release tag associated with upstream commit tag: stx.4.0-v3.1 - name: docker.io/starlingx/intel-fpga-admissionwebhook src_build_tag: master-distroless-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/5f72ddb26a38d41fef919060585daaafa... # Version determined by running 'git describe --tags' in clone of upstream repo tag: stx.4.0-v0.11.0-103-g4f28657 - name: docker.io/starlingx/intel-fpga-initcontainer src_build_tag: master-distroless-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/5f72ddb26a38d41fef919060585daaafa... # Version determined by running 'git describe --tags' in clone of upstream repo tag: stx.4.0-v0.11.0-103-g4f28657 - name: docker.io/starlingx/intel-fpga-plugin src_build_tag: master-distroless-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/5f72ddb26a38d41fef919060585daaafa... # Version determined by running 'git describe --tags' in clone of upstream repo tag: stx.4.0-v0.11.0-103-g4f28657 - name: docker.io/starlingx/intel-gpu-plugin src_build_tag: master-distroless-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/5f72ddb26a38d41fef919060585daaafa... # Version determined by running 'git describe --tags' in clone of upstream repo tag: stx.4.0-v0.11.0-103-g4f28657 - name: docker.io/starlingx/intel-qat-plugin src_build_tag: master-distroless-stable-20191203T153530Z.0 src_ref: https://opendev.org/starlingx/integ/commit/d9d92a6997f939cb1ec41813dbf2d72d0... # Version determined by running 'git describe --tags' in clone of upstream repo tag: stx.4.0-v0.11.0-109-gc48c502 The image retagging utility checks to see if the new tag already exists in the docker repo. If not, it will pull the image using the src_build_tag, retag it with the new tag, and push it. As noted above, this utility can be called by CENGN to handle the retagging - or called manually by a member of the build team with appropriate access permissions. Feedback is welcome. Please let me know if you have any comments or questions. Thanks, Don. Don Penney, Developer, Wind River