-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
maistra-2.1.0
-
None
-
False
-
False
-
Undefined
-
I noticed this error in wasm-cacher pod log:
Error logging in to registry: time="2021-06-10T16:19:51Z" level=error msg="cannot find UID/GID for user 1000620000: No subuid ranges found for user \"1000620000\" in /etc/subuid - check rootless mode in man pages." time="2021-06-10T16:19:51Z" level=warning msg="using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding sub*ids" time="2021-06-10T16:19:52Z" level=warning msg="Failed to detect the owner for the current cgroup: stat /sys/fs/cgroup/systemd/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod0fba3176_ab76_46f4_b926_4dd724944ffb.slice/crio-b527e5119b4fc326014b90fe5b180740a5b04d3357cdd90a05b82c6c78696257.scope: no such file or directory" Error: error logging into "image-registry.openshift-image-registry.svc:5000": invalid username/password
Because it did not login to the registry, it cannot pull images from it, making the process of ServiceMeshExtension resource not to proceed.
I'm not sure exactly why this failed.The warning "Failed to detect the owner..." can be ignored.
There's this error message: "cannot find UID/GID..." and there's also an error "invalid username/password". Not sure if the first led to the latter.
This login was triggered by a change in the token file. In theory the token file should contain the correct token, so it's unlikely that the password is incorrect.
After this, I exec'd into the pod, and manually ran the login command, exactly the same way it's executed by mec binary:
podman --storage-driver=vfs login --tls-verify=false image-registry.openshift-image-registry.svc:5000 --username=mec --password=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
And it succeeded. Again, not sure why it failed in the first time.
Maybe we should consider add a retry mechanism for when the login fails? Like, try again after 1 minute or so?
- relates to
-
-
- Closed
-