You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Anchore is deployed into a namespace or cluster that has Istio Sidecar Injection enabled and the upgrade jobs fire, the jobs run indefinitely (stuck in 'upgrading release').
While supporting this type of configuration in the upgrade job would be implementation specific, has there been any consideration for introducing logic to the job chart(s) to handle this scenario?
The text was updated successfully, but these errors were encountered:
* add feeds workspace dir to fixPermissions init container
* bump chart version
* use sh not bash
Signed-off-by: Brady Todhunter <[email protected]>
---------
Signed-off-by: Brady Todhunter <[email protected]>
* add feeds workspace dir to fixPermissions init container
* bump chart version
* use sh not bash
---------
Signed-off-by: Brady Todhunter <[email protected]>
When Anchore is deployed into a namespace or cluster that has Istio Sidecar Injection enabled and the upgrade jobs fire, the jobs run indefinitely (stuck in 'upgrading release').
This appears to be a known issue:
Handling Istio Sidecars in Kubernetes Jobs
Jobs are Broken (they Never Complete) · Issue #11045 · istio/istio
Better support for sidecar containers in batch jobs · Issue #6324 · istio/istio
Recommendations (https://discuss.istio.io/t/best-practices-for-jobs/4968) seem to point to calling
curl -sf -XPOST http://127.0.0.1:15020/quitquitquit
after the job has completed.While supporting this type of configuration in the upgrade job would be implementation specific, has there been any consideration for introducing logic to the job chart(s) to handle this scenario?
The text was updated successfully, but these errors were encountered: