Skip to content
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

Merged

Conversation

taragu
Copy link
Contributor

@taragu taragu commented Jun 17, 2020

/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 because InitialScale only applies during the first activation, so we need this condition to know when this activation is the first one.

Release Note

NONE

/cc @julz @vagababov @markusthoemmes @dprotaso @mattmoor

@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label Jun 17, 2020
@knative-prow-robot knative-prow-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. area/API API objects and controllers area/autoscale labels Jun 17, 2020
Copy link
Contributor

@knative-prow-robot knative-prow-robot left a 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

/cc @julz @vagababov @markusthoemmes @dprotaso @mattmoor

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 {
Copy link
Member

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

Copy link
Member

@julz julz left a 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{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
p := &PodAutoscaler{}
p := PodAutoscaler{}

will probably work :)

Comment on lines 117 to 118
// PodAutoscalerConditionInitiallyActive is set when PodAutoscaler has first reached its initial scale.
PodAutoscalerConditionInitiallyActive apis.ConditionType = "InitiallyActive"
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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)

Copy link
Member

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 🤷‍♂️

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Member

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 :)

Copy link
Contributor

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 :)

Copy link
Contributor

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" {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@taragu taragu force-pushed the tara-init-scale-0-PA-condition branch from 921b749 to 55a031d Compare June 18, 2020 16:41
Copy link
Member

@julz julz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 18, 2020
@vagababov
Copy link
Contributor

needs merge

@knative-prow-robot knative-prow-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 18, 2020
@vagababov
Copy link
Contributor

/approve

@knative-prow-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 18, 2020
@taragu taragu force-pushed the tara-init-scale-0-PA-condition branch from 55a031d to 66e8a3a Compare June 18, 2020 19:37
@knative-prow-robot knative-prow-robot removed the lgtm Indicates that a PR is ready to be merged. label Jun 18, 2020
@knative-prow-robot knative-prow-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 18, 2020
@knative-metrics-robot
Copy link

The following is the coverage report on the affected files.
Say /test pull-knative-serving-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/autoscaling/kpa/kpa.go 93.5% 93.6% 0.1

@julz
Copy link
Member

julz commented Jun 18, 2020

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 18, 2020
@knative-prow-robot knative-prow-robot merged commit 7be0f43 into knative:master Jun 18, 2020
@taragu taragu deleted the tara-init-scale-0-PA-condition branch July 29, 2020 11:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/API API objects and controllers area/autoscale cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants