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:

 

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