[utils] Change kubernetes-entrypoint image repo

[joker-at-work]

The old version of kubernetes-entrypoint was based on a rotten image and not updated in years. We now switch to a new upstream and rebuild the base image for security updates regularly through our "shared-app-images" pipeline. The tag of the image contains the version and a build number.

Since PCI forces us to do staged deployments for feature changes, we track the version in the utils chart. This means we need a utils chart bump to get a new version in, which will be transported through the stages by the individual services' pipelines.

The build version, that's only incremented for base OS updates, can be updated in all regions at the same time. Therefore, we track the latest build version - and with that the one we want to deploy in a region - through a region-local values file.

The idea would be to follow up with a pipeline that updates the build version in the values file automatically every time a new image is built.

[fwiesel]

Since PCI forces us to do staged deployments for feature changes, we track the version in the utils chart.

AFAIK, PCI requires us to have an engineering policy and that one requires a staged deploy.
Reading the policy, I do not see any distinction between features and security updates (or configuration for that matter). Personally, I would advocate against making such a distinction in general (Though I see a point in this particular case, see next paragraph).

The build version, that's only incremented for base OS updates, can be updated in all regions at the same time. Therefore, we track the latest build version - and with that the one we want to deploy in a region - through a region-local values file.

While I wrote that I am not a fan of that, I have to agree that the OS updates for that particular image are very likely not causing any problems, because it is mostly the result of them choosing a large base image with binaries not being used at all.

But for that exists another solution: Build our own images from the repository with a minmal (i.e. distroless / ko build) process.

[fwiesel]

It seems I was mistaken: https://github.com/airshipit/kubernetes-entrypoint/blob/master/images/Dockerfile.ubuntu_focal#L32-L35

Some OS tools are needed after all.

[joker-at-work]

Some OS tools are integrated. I wouldn't immediately assume they are actually used. Building our own image is definitely an option. Then we would "just" switch the version to the latest specific tag from the shared-app-images to get away from the rotten old image and follow-up with creating our own image and then updating the utils chart again for that new repo/tag.

[fwiesel]

The package was added in the following commit: airshipit/kubernetes-entrypoint@f3ccc07

Looking at the code it seems it happens when you explicitly pass COMMAND=echo, which is presumably their particular use-case (ours is to pass COMMAND=true).
We could simply leave COMMAND empty and live with the warning (my preferred option), or add an empty file as /usr/bin/true.

[fwiesel]

I've created some PRs on the upstream repo, in the hope they will take them. If that is the case, it could reduce our maintenance work.

[joker-at-work]

Do they not use gerrit like the rest of opendev?

[fwiesel]

There is also a gerrit repo... but honestly, I don't know what workflow they follow. The CONTRIBUTION.md looked more like a github workflow, but it is a bit ambiguous.

[fwiesel]

They do have a gerrit project, so I moved the PRs there.