The main reason I suggested the stx.## is to avoid version conflicts between branches. Otherwise, I’d drop the stx.## altogether and just have a simple version number.
For example, an image gets updated post-release in r/stx.3.0 and rebuilt to pull in a fix, and gets tagged as v1.1. The same image gets updated in master for the fix, but also has some underlying differences in an installed package or some other behavioural change, and gets tagged as v1.1. When the second request comes along for the same tag, the tag management utility would just see this as “tag already exists, nothing to do”.
This doesn’t mean we’d have to update the image tag on every release, of course. If the stx.3.0 image is still fine in master, we could just keep using the older image and not update the tag. Or we can update the tag, but keep the same original source image.
From: Waines, Greg Sent: Thursday, January 30, 2020 8:45 AM To: Penney, Don; 'starlingx-discuss@lists.starlingx.io' (starlingx-discuss@lists.starlingx.io) Subject: Re: [Starlingx-discuss] Proposal: Tag management for statically referenced container images (LP: 1854869)
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:
* 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. * Include reference to source build tag from loadbuild, using the versioned tag, such as master-centos-stable-20191203T153530Z.0 * Include reference to upstream commit, if appropriate * 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