-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
make deployment status behaviour more descriptive #31226
Conversation
✔️ Deploy Preview for kubernetes-io-main-staging ready! 🔨 Explore the source changes: 8f8d2bb 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/61dc98727c750d00083e5250 😎 Browse the preview: https://deploy-preview-31226--kubernetes-io-main-staging.netlify.app |
/sig apps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some feedback from a docs style perspective. It's not blocking. I do though want to push back somewhat on introducing more Go-isms into end user docs.
* Type=Progressing | ||
* Status=True | ||
* Reason=NewReplicaSetCreated | FoundNewReplicaSet | ReplicaSetUpdated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the existing text uses this style, I'd rather not see more of it. How about switching to something like:
* Type=Progressing | |
* Status=True | |
* Reason=NewReplicaSetCreated | FoundNewReplicaSet | ReplicaSetUpdated | |
* `type: Progressing` | |
* `status: "true"` | |
* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` |
(I think) this is how they'd look in YAML, which is how we usually represent API details. JSON is also OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the Deployment controller also emit an Event? If so, maybe we can mention that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather not in this case.
- It emits scaling event. Eg.
Scaled up replica set test to 1
. But this is not reflective of a rollout / deployment and occurs in plain scaling as well. - If you create Deployment with 0 replicas there is no event emitted.
@@ -842,6 +842,13 @@ Kubernetes marks a Deployment as _progressing_ when one of the following tasks i | |||
* The Deployment is scaling down its older ReplicaSet(s). | |||
* New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)). | |||
|
|||
When the rollout becomes progressing, the Deployment controller adds a DeploymentCondition with the following |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the rollout becomes progressing, the Deployment controller adds a DeploymentCondition with the following | |
When the rollout becomes “progressing”, the Deployment controller adds a condition with | |
the following |
DeploymentCondition
isn't part of the Kubernetes API; it's an implementation detail of the Golang implementation.
In theory someone could drop in their own conformant Deployment controller and use that. We should write docs that are still relevant for that case.
* Type=Progressing | ||
* Status=True | ||
* Reason=NewReplicaSetAvailable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see previous comment - let's try to show how things would look in the API.
@@ -853,6 +860,15 @@ updates you've requested have been completed. | |||
* All of the replicas associated with the Deployment are available. | |||
* No old replicas for the Deployment are running. | |||
|
|||
When the rollout completes, the Deployment controller sets a DeploymentCondition with the following |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see previous comment - let's try to show how things would look in the API.
* Status=True | ||
* Reason=NewReplicaSetAvailable | ||
|
||
This condition will stay `True`, until a new rollout is initiated (even when availability of replicas changes, in that case see `Type=Available` condition). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This condition will stay `True`, until a new rollout is initiated (even when availability of replicas changes, in that case see `Type=Available` condition). | |
This `Progressing` condition will retain a status value of `"True"` until a new rollout | |
is initiated. The condition holds even when availability of replicas changes (which | |
does instead affect the `Available` condition). |
?
1dde5aa
to
8f8d2bb
Compare
@sftim Thank you for the review. I have hopefully fixed all the comments. I have switched the condition references to the YAML format and also applied this formatting to other places in this file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
LGTM label has been added. Git tree hash: 707d21e49d5c658bd74afeecec0327d1deb31639
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sftim, soltysh 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 |
There is sometimes a misunderstanding about the behaviour of Deployments and its
Progressing
condition [1] [2]. This PR is trying to describe in more detail behaviour and peculiarities of the current implementation.@ravisantoshgudimetla @soltysh what is your opinion on these changes?
TODO: