Folks,
A quick update, Don and I had a chat on IRC about this, I am still not sure I fully understand the issue yet. One of the questions I had was where we could also leverage PBR somehow rather than introduce a new/different versioning system.
While PBR does version on a package level, the version is available at the repo level also since it offsets from a known version followed by number of commit, so a x.y.z-<n> is available to useto help version or tag the images.
It seems that this adds additional complexity to an already complex build system.
I will continue to study this.
Sau!
On 1/29/20 1:15 PM, Penney, Don wrote:
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.
oInclude reference to source build tag from loadbuild, using the versioned tag, such as master-centos-stable-20191203T153530Z.0
oInclude reference to upstream commit, if appropriate
oInclude 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*
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss