-
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
Add PA condition InitiallyActive #8354
Add PA condition InitiallyActive #8354
Conversation
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.
@taragu: 0 warnings.
In response to this:
/lint
Part 5 of #7682
Proposed Changes
- This PR adds (and sets) a new condition on PA:
InitiallyActive
. This condition is set to true when a PA becomes active, and never set back to false. We need this condition to be able to tell if a PA has reached its initial scale before in its existence.Release Note
NONE
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.
@@ -170,6 +170,16 @@ func (pas *PodAutoscalerStatus) IsInactive() bool { | |||
return pas.GetCondition(PodAutoscalerConditionActive).IsFalse() | |||
} | |||
|
|||
// IsInitiallyActive returns true if the pod autoscaler has reached its initial scale. | |||
func (pas *PodAutoscalerStatus) IsInitiallyActive() bool { |
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.
could be worth bike-shedding on this a little. Maybe HasBeenActive
or HasActivatedOnce
? IsInitiallyActive
seems to imply it's currently in its first activation, which isn't quite right
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.
looks good to me apart from wanting to bike-shed a bit on the name, @vagababov @markusthoemmes wdyt?
@@ -1143,3 +1143,14 @@ func TestScaleToZeroPodRetention(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestInitiallyActive(t *testing.T) { | |||
p := &PodAutoscaler{} |
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.
p := &PodAutoscaler{} | |
p := PodAutoscaler{} |
will probably work :)
// PodAutoscalerConditionInitiallyActive is set when PodAutoscaler has first reached its initial scale. | ||
PodAutoscalerConditionInitiallyActive apis.ConditionType = "InitiallyActive" |
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.
Is this an informational status? If so we should comment to that. If not — it'd be interesting to know why.
Also should it be a status, or perhaps this is a good thing to put in the status.Annotations
?
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.
My 2c is this is informational. As a user the behaviour will be different before/after first activation, so knowing if the revision successfully passed its first activation is a reasonable thing for a user to want to see in conditions.
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 this is informational for the users. We can put this into status.Annotations
.
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.
(not that I’m super bothered personally, an annotations works too)
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 guess we can always expose it as a condition later if we want to 🤷♂️
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.
That's a good question, I think I was mostly rumbling as these changes are kinda out of scope. Maybe it makes sense to think through them before adding new conditions though.
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.
SO what's the consensus? Informational status for now and long overdue refactoring later?
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 think on slack we landed on a true/false status for now, so long as you agree too :)
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.
Sure, but true/false can be mandatory (i.e. included in happy computation) or informational :)
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.
Eh, status.Annotation :) Sure.
@@ -170,6 +172,22 @@ func (pas *PodAutoscalerStatus) IsInactive() bool { | |||
return pas.GetCondition(PodAutoscalerConditionActive).IsFalse() | |||
} | |||
|
|||
// HasBeenActive returns true if the pod autoscaler has reached its initial scale. | |||
func (pas *PodAutoscalerStatus) HasBeenActive() bool { | |||
if val, ok := pas.Annotations[initiallyActiveAnnotation]; !ok || val != "true" { |
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.
would you rather care for the time when it happened? Might be useful in future and it'll be harder to change later.
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.
Hmm if we want to know how long it’s been “initially active”, making this a condition is probably better. Also if we write a time stamp here for the annotation, table tests will be difficult.
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.
🤷 we can keep true. May be we don't need when.
I am fine with status as well. But I think it should be informational, rather than gating.
921b749
to
55a031d
Compare
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
needs merge |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: taragu, vagababov 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 |
55a031d
to
66e8a3a
Compare
The following is the coverage report on the affected files.
|
/lgtm |
/lint
Part 5 of #7682
Proposed Changes
InitiallyActive
. This condition is set to true when a PA becomes active, and never set back to false. We need this condition to be able to tell if a PA has reached its initial scale before in its existence because InitialScale only applies during the first activation, so we need this condition to know when this activation is the first one.Release Note
/cc @julz @vagababov @markusthoemmes @dprotaso @mattmoor