Container image tags in releases aren't static / immutable

1

I’ve been noticing that the default behavior for an Istio deployment (via Helm at least) is to use the release-1.1-latest-daily tag for its container images across the k8s Deployment resources. These tags aren’t static / immutable, so one can end up in a situation where new code is deployed unintentionally, which makes debugging a little frustrating. This also goes against the principle of least surprise, in that releases aren’t immutable.

As a motivating example, when tracking down a panic in Pilot, I noticed that a different underlying container image had been pulled from the day before. Looking on GCR I see that a new image is built from master each day, and the release-1.1-latest-daily points to the latest, as the name would suggest.

I assume this is by design (the Helm charts are configurable via the values files), but I’m wondering if anyone has opinions or context on why this is the current state, or if this decision is documented somewhere (I couldn’t find anything from a quick search).

Best practice in the container world seems to be to not use tags like “latest” due to the issue I mentioned, as well as cases where images aren’t pulled in the case that imagePullPolicy is not Always.

I’m basing this off of my experience with Istio 1.1.2, but I see that this is still the case in 1.1.3 (the latest release).

If this is better suited to an issue on the GH project, happy to move it there!

2

How did you install (helm repo, from github source, from release download)? we intend to have the tags be 1.1.1, 1.1.2, etc. We did recently have some bugs with the wrong tag being used.

3

Noticed you linked the code, how it (is supposed to) work is that when we build a release we replace the tag with the correct one. This is just used for the source

4

Ah, that’s probably it then. We’re using the GitHub tags to check out the code and “vendor” it (we have some light modifications to the Helm chart we apply), rather than downloading the release artifact. Thanks for clearing that up.

I’m used to the Maven workflow where the tag lines up with the version number in the published artifacts. Might I suggest some tweaks to the workflow where the released artifacts have identical code in them as the code in Git at the same tag / revision?