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
Whatever happened here, we should always respect the timeoutSeconds which defaults to 10 minutes. After 10 minutes this should transition from New to Failed since there was no progress. It would be interesting to know why this got stuck, I assume it failed to create the deployer pod because of quota(?) or some other non-transient error. Maybe we should print the last condition here to see where it got stuck.
Automatic merge from submit-queue (batch tested with PRs 17020, 17026, 17000, 17010).
apps: deployment config stuck in the new state should respect timeoutSeconds
Fixes: #16962
With this patch the deployment config controller will set the deployment as failed (timeout) after it reaches timeoutSeconds and the status of the deployment is 'new'. This generally happens when the deployment is not able to create the deployer pod (quota). We should not wait infinitely to have the quota.
Unusual deployment, in "new" for 2 days on a 3.7 cluster:
This deployment should be failed or complete, not New.
@openshift/sig-master
The text was updated successfully, but these errors were encountered: