Sounds reasonable to me.
Only question on tag convention, would we prefix with ‘stx.<rel#>.’ Or just ‘stx.’,
since, I am guessing that the container image may not require re-building from one stx release to another ?
Greg.
From: "Penney, Don" <Don.Penney@windriver.com>
Date: Wednesday, January 29, 2020 at 4:18 PM
To: "'starlingx-discuss@lists.starlingx.io' (starlingx-discuss@lists.starlingx.io)" <starlingx-discuss@lists.starlingx.io>
Subject: [Starlingx-discuss] Proposal: Tag management for statically referenced container images (LP: 1854869)
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:
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/dac417bd31ed36d455e94db4aabe5916367654d4
# 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/dac417bd31ed36d455e94db4aabe5916367654d4
# 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/5f72ddb26a38d41fef919060585daaafae677433
# 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/5f72ddb26a38d41fef919060585daaafae677433
# 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/5f72ddb26a38d41fef919060585daaafae677433
# 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/5f72ddb26a38d41fef919060585daaafae677433
# 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/d9d92a6997f939cb1ec41813dbf2d72d0b80d79c
# 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