-
Notifications
You must be signed in to change notification settings - Fork 49
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
[RECOMMENDED] introduce actualReplicas & desiredReplicas #71
Conversation
cc @knative/trademark-committee |
</td> | ||
<td>int | ||
</td> | ||
<td>Reflects the number of replicas that are running this revision. |
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.
do we need to be clear about whether this is "ready" replicas vs "existing" replicas in any state?
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 don't think the word Ready
would have meaning here without more definition. That's why I left the verbiage as running this revision
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.
What was the original reason for adding these? I have a vague recollection that we added it so that we didn't rely on the Deployment's metadata to maintain Knative's desired state of the world - and then we'd reflect that down into the Deployment. So, I guess if that's all it is and there's no assumption as to state of the underlying "pods" (rather it's just implying that we're "trying" to bring up X of them), is this your thinking too?
+1 |
rebase needed |
Should the actual/desired replica count be tied to the ContainerStatus? IOW should we be extending ContainerStatus with this count or the Revision? Basically, do we need to account for mixed containers running? |
/lgtm |
Discussed why we can't do this in the ContainerStatus property in KTC and it makes sense that this change is a view into the autoscaler vs a view into the pod-level tracking of containers, so will lgtm |
/LGTM |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: dprotaso, omerbensaadon 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 |
requirement levels for these are RECOMMENDED it allows for distributions to signal some additional status regarding the scale of their revisions
9234a0c
to
fe0eea8
Compare
/lgtm |
requirement levels for these are RECOMMENDED
it allows for distributions to signal some additional status regarding
the scale of their revisions