-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release-1.13] Don't drop traffic when upgrading a deployment fails #14864
[release-1.13] Don't drop traffic when upgrading a deployment fails #14864
Conversation
When transforming the deployment status to the revision we want to bubble up the more severe condition to Ready. Since Replica failures will include a more actionable error message this condition is preferred
This isn't accurate when the Revision has failed to rollout an update to it's deployment
1. PA Reachability now depends on the status of the Deployment If we have available replicas we don't mark the revision as unreachable. This allows ongoing requests to be handled 2. Always propagate the K8s Deployment Status to the Revision. We don't need to gate this depending on whether the Revision required activation. Since the only two conditions we propagate from the Deployment is Progressing and ReplicaSetFailure=False 3. Mark Revision as Deploying if the PA's service name isn't set
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## release-1.13 #14864 +/- ##
================================================
- Coverage 85.91% 85.90% -0.02%
================================================
Files 197 197
Lines 14991 15000 +9
================================================
+ Hits 12879 12885 +6
- Misses 1798 1800 +2
- Partials 314 315 +1 ☔ View full report in Codecov by Sentry. |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, knative-prow-robot The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…native#14864) (#655) * Surface Replica failures over Progressing failures When transforming the deployment status to the revision we want to bubble up the more severe condition to Ready. Since Replica failures will include a more actionable error message this condition is preferred * Stop always marking the revision healthy when the PA is Ready This isn't accurate when the Revision has failed to rollout an update to it's deployment * Various updates to the revision reconciler 1. PA Reachability now depends on the status of the Deployment If we have available replicas we don't mark the revision as unreachable. This allows ongoing requests to be handled 2. Always propagate the K8s Deployment Status to the Revision. We don't need to gate this depending on whether the Revision required activation. Since the only two conditions we propagate from the Deployment is Progressing and ReplicaSetFailure=False 3. Mark Revision as Deploying if the PA's service name isn't set * test deployment failures don't drop traffic on upgrade * fix boilerplate check --------- Co-authored-by: Knative Prow Robot <[email protected]> Co-authored-by: dprotaso <[email protected]> Co-authored-by: John Doe <johndoe@localhost>
…native#14864) (knative#655) * Surface Replica failures over Progressing failures When transforming the deployment status to the revision we want to bubble up the more severe condition to Ready. Since Replica failures will include a more actionable error message this condition is preferred * Stop always marking the revision healthy when the PA is Ready This isn't accurate when the Revision has failed to rollout an update to it's deployment * Various updates to the revision reconciler 1. PA Reachability now depends on the status of the Deployment If we have available replicas we don't mark the revision as unreachable. This allows ongoing requests to be handled 2. Always propagate the K8s Deployment Status to the Revision. We don't need to gate this depending on whether the Revision required activation. Since the only two conditions we propagate from the Deployment is Progressing and ReplicaSetFailure=False 3. Mark Revision as Deploying if the PA's service name isn't set * test deployment failures don't drop traffic on upgrade * fix boilerplate check --------- Co-authored-by: Knative Prow Robot <[email protected]> Co-authored-by: dprotaso <[email protected]> Co-authored-by: John Doe <johndoe@localhost>
…native#14864) (#655) (#675) * Surface Replica failures over Progressing failures When transforming the deployment status to the revision we want to bubble up the more severe condition to Ready. Since Replica failures will include a more actionable error message this condition is preferred * Stop always marking the revision healthy when the PA is Ready This isn't accurate when the Revision has failed to rollout an update to it's deployment * Various updates to the revision reconciler 1. PA Reachability now depends on the status of the Deployment If we have available replicas we don't mark the revision as unreachable. This allows ongoing requests to be handled 2. Always propagate the K8s Deployment Status to the Revision. We don't need to gate this depending on whether the Revision required activation. Since the only two conditions we propagate from the Deployment is Progressing and ReplicaSetFailure=False 3. Mark Revision as Deploying if the PA's service name isn't set * test deployment failures don't drop traffic on upgrade * fix boilerplate check --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Knative Prow Robot <[email protected]> Co-authored-by: dprotaso <[email protected]> Co-authored-by: John Doe <johndoe@localhost>
This is an automated cherry-pick of #14840
Part of #14795
Depends on 1.12 point release with the following fix - #14840