istioctl kube-inject defaults to short SHA from gcr.io/istio-testing should be long sha (or we should push short shas)

[andraxylia]

Tried to deploy manually bookinfo as before:
kubectl apply -f <(istioctl kube-inject --hub gcr.io/istio-testing -f samples/apps/bookinfo/bookinfo.yaml)

Pods do not start:
19s 2s 2 kubelet, gke-cluster-1-default-pool-c0105838-mr9c spec.initContainers{istio-init} Warning Failed Failed to pull image "gcr.io/istio-testing/proxy_init:fb947d4": rpc error: code = 2 desc = Error: Status 405 trying to pull repository istio-testing/proxy_init: "v1 Registry API is disabled. If you are not explicitly using the v1 Registry API, it is possible your v2 image could not be found. Verify that your image is available, or retry with dockerd --disable-legacy-registry. See https://cloud.google.com/container-registry/docs/support/deprecation-notices"

The workaround is to use the full sha and specify in kube-inject params:
kubectl apply -f <(istioctl kube-inject --hub gcr.io/istio-testing --tag fb947d4c6d0902a841e0e82ffa3bee16786be0df -f samples/apps/bookinfo/bookinfo.yaml)

[ldemailly]

updated subject as it's unrelated to bookinfo. full workaround is

source istio.VERSION
istioctl kube-inject --hub $PILOT_HUB --tag $PILOT_TAG

ps: should be in pilot as pilot is where istioctl is built

[ayj]

Here are two options for fixing the issue in istioctl:

1. update presubmit hooks to publish images with short SHA.

2. change the default version used by kube-inject to be the full SHA

diff --git a/bin/get_workspace_status b/bin/get_workspace_status
index 451b75e..64bb91d 100755
--- a/bin/get_workspace_status
+++ b/bin/get_workspace_status
@@ -30,7 +30,7 @@ function get_branch() {
     fi
 }
 
-BUILD_GIT_REVISION=$(git rev-parse --short HEAD 2> /dev/null)
+BUILD_GIT_REVISION=$(git rev-parse HEAD 2> /dev/null)
 if [[  $? == 0 ]]; then
     BRANCH="$(get_branch)"
     git diff-index --quiet HEAD

Option (2) is probably easier since it doesn't require modifying multiple repos?

[andraxylia]

@sebastienvas @yutongz Can option 1 be done?

Option 2 is easier to implement, but it will result in long and ugly injected container, also used by initializer, affecting Istio long term.

BTW, this is only for temporary images in gcr.io. A third option is to leave with the workaround.

[sebastienvas]

There are currently a lot of tools that assume the full SHA. @chxchx. I think jason solution is simple enough.

[ldemailly]

I think long sha is best as this doesn't apply to releases

[ldemailly]

this is actually not quite fixed because it still uses docker.io (are we pushing to both ?)

    image: docker.io/istio/proxy_debug:330dd286541d1b84c5ac1f4fc504556796c070af

[andraxylia]

We only push releases to docker.io, intermediate images are pushed to gcr.io

[sebastienvas]

I think the default should be to use docker.io as this is for the release, for testing people need to use --hub gcr.io/istio-testing.

[ldemailly]

we should be able to bake gcr.io along the long SHAs vs docker.io and releases

[sebastienvas]

I am not understanding what there is left to do. Can we close this ?

[ldemailly]

what is left is that it's not working yet because it tries to fetch #672 (comment)
which does not exist...

[linsun]

is this still an issue? I have been using transparent proxy injection myself.

[andraxylia]

It's still an issue. Will move it to 0.3.