Open Shadowssong opened 1 month ago
Hi @Shadowssong , if the emissary-apiext deployment is not installed in the emissary-system namespace (or has a different name for whatever reason), users will be able to configure this accordingly and there are a few fields within waitForApiext.enabled for users:
waitForApiext:
enabled: false
deploymentName: emissary-apiext
deploymentNamespace: emissary-system
securityContext:
runAsUser: 8888
createRoles: true
Note: if users are installing the emissary-apiext from our CRDs, it will default to emissary-apiext.emissary-system.
So it seems in this case things are technically working but the shell script message "/bin/sh: 14: [[: not found" is causing confusion?
hey @cindymullins-dw Yea sorry if my original message was unclear, the override for the namespace worked fine I just included it incase that was potentially related. Mainly it's the shell syntax error that I noticed.
FWIW - I'm seeing a different hang:
checking if deployment/emissary-apiext in namespace: emissary-system exists. emissary-apiext.emissary-system does not exist yet. Waiting...
I've checked that the emissary-apiext.emissary-system replicas do exist and that the emissary-ingress service account can view their status.
In my case, I suspect that linkerd's initContainer was creating a deadlock.
Resolved by setting waitForApiext.enabled=false
Describe the bug
While attempting to upgrade to v8.9.1 of the emissary-ingress helm chart I noticed an error regarding the shell script syntax on the newly added init container. I verified this with multiple restarts of the emissary-ingress pods
Side note: I did have to add
to my helm values as emissary-apiext is deployed to our ingress-system namespace instead of the emissary-system namespace.
This behavior was introduced here: https://github.com/emissary-ingress/emissary/pull/5241/files#diff-b89fbcdd0118bbc0f11053f2b0afb3725ab8b1830b39025303097249567c1f20R138
I am not sure if this is affecting the evaluation of the results of the query and whether or not the script proceeds, it seems to report things are healthy (which they were), but just wanted to bring this to the teams attention.
Here is the entire init container configuration pulled from the pod directly:
To Reproduce Steps to reproduce the behavior:
Expected behavior
There should be no shell script errors from the script run by the init container
Versions (please complete the following information):
Additional context
cc @AliceProxy @tenshinhigashi