Propagate HasBeenActive to a terminal condition as "ScaleTargetInitialized".#8569
Conversation
It will eventually be superceding "Active" as the PA's readiness gate.
knative-prow-robot
left a comment
There was a problem hiding this comment.
@markusthoemmes: 0 warnings.
Details
In response to this:
First step of #8540
Proposed Changes
- Propagate HasBeenActive to a terminal condition.
Release Note
NONE/assign @vagababov @julz @taragu
/hold
Until after the release.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: markusthoemmes The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest Doubt it's related. |
|
The following jobs failed:
Failed non-flaky tests preventing automatic retry of pull-knative-serving-unit-tests: |
|
/test pull-knative-serving-unit-tests |
|
/lgtm |
| PodAutoscalerConditionReady = apis.ConditionReady | ||
| // PodAutoscalerConditionHasBeenActive is set when the PodAutoscaler's ScaleTargetRef was ready to | ||
| // serve traffic once. | ||
| PodAutoscalerConditionHasBeenActive apis.ConditionType = "HasBeenActive" |
There was a problem hiding this comment.
HasBeenActive sounds a bit odd to me - how about Deployed
There was a problem hiding this comment.
ScaleTargetDeployed (maybe just TargetDeployed) might be more specific
There was a problem hiding this comment.
I almost feel like we should just set Ready 😂
There was a problem hiding this comment.
Not necessarily true. With initialScale=0 — nothing will ever be deployed
There was a problem hiding this comment.
Hmm ScaleTargetDeployed might imply new calculated autoscaler scale targets. What about InitialTargetDeployed?
There was a problem hiding this comment.
Or maybe ReachedInitialScale, since that’s what actually gates the condition
There was a problem hiding this comment.
ScaleTargetInitialized would be my favorite mix from the above. I would like to keep InitialScale out of this, it doesn't necessarily gate this, for example if minScale is > initialScale.
There was a problem hiding this comment.
Hm, in my head when minScale > initialScale, initialScale is implicitly set to minScale, but I see how that could be confusing.
ScaleTargetInitialized seems alright, just a bit odd that it talks about a "Scale Target" concept that isn't really defined anywhere else, and doesn't mention the quite important fact that it's the scale target for the first scale we're talking about. I'm also not totally sure what "Initialized" means in this context.. "-Reached" seems clearer about what has to happen. Not the end of the world, though, if everyone else is happy Im happy.
There was a problem hiding this comment.
I think it works because it's part of the PodAutoscaler spec
serving/pkg/apis/autoscaling/v1alpha1/pa_types.go
Lines 98 to 100 in f431439
| pa.Status.MarkHasBeenActive() | ||
| pa.Status.MarkScaleTargetInitialized() | ||
| // SKS should already be active. | ||
| pa.Status.MarkActive() |
There was a problem hiding this comment.
Could MarkActive also set the MarkScaleTargetInitialized or do you prefer to keep the two methods separate?
There was a problem hiding this comment.
I think I prefer them to be separate. I tried that too, but it felt slightly awkward.
|
/lgtm |
|
/unhold |
|
The following is the coverage report on the affected files.
|
First step of #8540
Proposed Changes
Release Note
/assign @vagababov @julz @taragu
/hold
Until after the release.