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
After the initial deployment of a pod for a workload (i.e. when the related KeptnWorkloadVersion is in a completed state), we have the problem that pods related to that workload stay stuck in a pending state when restarting them.
This is because the mutating webhook always adds the the scheduling gate for the pod (see
), even though the related KeptnWorkloadVersion is already in a completed state.
In this case, also the fix in #2926 will not help, since the replica set of a pod does not change if it is restarted.
A potential solution for this is to do a lookup of a matching KeptnWorkloadVersion for a pod before adding the scheduling gate, as done in the scheduler:
After the initial deployment of a pod for a workload (i.e. when the related KeptnWorkloadVersion is in a completed state), we have the problem that pods related to that workload stay stuck in a pending state when restarting them.
This is because the mutating webhook always adds the the scheduling gate for the pod (see
lifecycle-toolkit/lifecycle-operator/webhooks/pod_mutator/pod_mutating_webhook.go
Line 94 in 9095a00
In this case, also the fix in #2926 will not help, since the replica set of a pod does not change if it is restarted.
A potential solution for this is to do a lookup of a matching KeptnWorkloadVersion for a pod before adding the scheduling gate, as done in the scheduler:
lifecycle-toolkit/scheduler/pkg/klcpermit/workflow_manager.go
Line 75 in 9095a00
The text was updated successfully, but these errors were encountered: