Adding metrics for Maxunavailable feature in StatefulSet#130951
Adding metrics for Maxunavailable feature in StatefulSet#130951k8s-ci-robot merged 14 commits intokubernetes:masterfrom
Conversation
|
/triage accepted |
|
/retest |
|
This PR may require stable metrics review. Stable metrics are guaranteed to not change. Please review the documentation for the requirements and lifecycle of stable metrics and ensure that your metrics meet these guidelines. |
|
LGTM in general after the presubmit check failure is fixed. @soltysh would you like to take a look as well? |
| return err | ||
| } | ||
| } | ||
| metrics.MaxUnavailable.WithLabelValues(set.Namespace, set.Name, podManagementPolicy).Set(float64(maxUnavailable)) |
There was a problem hiding this comment.
Given this functionality is tied to MaxUnavailableStatefulSet feature gate, I believe we should wrap this entire block in if utilfeature.DefaultFeatureGate.Enabled(features.MaxUnavailableStatefulSet) { block.
| @@ -1013,7 +1015,7 @@ func TestStatefulSetControlRollingUpdateWithMaxUnavailable(t *testing.T) { | |||
| // if pod 4 ready, start to update pod 3, even though 5 is not ready | |||
| spc.setPodRunning(set, 4) | |||
| spc.setPodRunning(set, 5) | |||
There was a problem hiding this comment.
Since you're fixing it, drop this line. You're setting pod 5 running further below, so this line is confusing.
| } | ||
| if len(pods) != totalPods { | ||
| t.Fatalf("Expected create pods 2/3, got pods %v", pods) | ||
| // In OrderedReady mode, only 5 pods exist at this point (pod 5 not created yet) |
There was a problem hiding this comment.
| // In OrderedReady mode, only 5 pods exist at this point (pod 5 not created yet) | |
| // In OrderedReady mode, only 4 pods exist at this point (pod 5 not created yet) |
| spc.setPodRunning(set, 5) | ||
| spc.setPodReady(set, 5) | ||
| originalPods, _ = spc.setPodReady(set, 3) | ||
| originalPods, _ = spc.setPodReadyCondition(set, 3, true) |
There was a problem hiding this comment.
Something is off here, the comment claims pods 3,4,5 are ready, but we're only setting 3 & 5 running, and only 3 ready, why?
There was a problem hiding this comment.
the comment is correct. The test sets the pod 4 in running state in line 1058.
There was a problem hiding this comment.
I see what you're saying, we're setting the pod running in both simpleOrderedVerificationFn and simpleParallelVerificationFn, which on one hand is somewhat misguiding. It seems like this particular test case deserves a re-write, but that's pre-existing, so definitely not part of this PR.
c2f7485 to
7630021
Compare
added metric to list of stable metrics changed when metric gets incremented addressed comments fixed stable metrics list
Co-authored-by: Filip Křepinský <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
Signed-off-by: Heba Elayoty <[email protected]>
7630021 to
b9aa7c2
Compare
|
@Edwinhr716: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
| spc.setPodRunning(set, 5) | ||
| spc.setPodReady(set, 5) | ||
| originalPods, _ = spc.setPodReady(set, 3) | ||
| originalPods, _ = spc.setPodReadyCondition(set, 3, true) |
There was a problem hiding this comment.
I see what you're saying, we're setting the pod running in both simpleOrderedVerificationFn and simpleParallelVerificationFn, which on one hand is somewhat misguiding. It seems like this particular test case deserves a re-write, but that's pre-existing, so definitely not part of this PR.
| expectedUnavailableReplicasValue int | ||
| } | ||
|
|
||
| testFn := func(test *testcase, t *testing.T) { |
There was a problem hiding this comment.
This pattern, where we define check function beforehand, even though it could easily be part of the invocation down below is confusing. But that's not blocking this particular PR.
There was a problem hiding this comment.
I don't prefer it either, but wanted to follow the same pattern in other tests in this file.
|
LGTM label has been added. DetailsGit tree hash: 9df13ab1ec357cf3f7b86497d127faaf6f4787bd |
|
/label tide/merge-method-squash |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Edwinhr716, hashim21223445, janetkuo, soltysh 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds a metric to track how many times there has been a
maxunavailableviolation, requirement for kubernetes/enhancements#961 beta graduation.Which issue(s) this PR fixes:
Part of kubernetes/enhancements#961
Special notes for your reviewer:
This is a follow up to the discussion on the KEP update PR kubernetes/enhancements#4474 (comment).
General consensus seems to be that this metric should be in tree instead of in kube-state-metrics.
Open question:
cc @atiratree @dgrisonnet @wojtek-t who were part of the original discussion.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: