-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP-4008: CRD Validation Ratcheting #4013
KEP-4008: CRD Validation Ratcheting #4013
Conversation
65f27b7
to
4b68aa6
Compare
478bf57
to
b498311
Compare
/assign @deads2k PRR LGTM as shadow reviewer. Would you have a look? |
/lgtm |
Pick one more of these and delete the rest. | ||
--> | ||
|
||
- [ ] Metrics |
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.
this enhancement called out a performance cost allowable for this feature. what metric is actually being checked?
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.
The template for this section says it is only required when targeting beta to a release. I would expect for beta we would add a metric to capture the total time used for ratcheting, but did not think it needed to be explicitly part of the KEP yet
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.
Specifically the 5% cost metric would be against the total time for a request during a write, so apiserver_request_duration_seconds
b498311
to
56b4120
Compare
ec9cb7a
to
9a7663e
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.
PRR is OK for alpha but please change approver to me
|
||
We may consider adding a metric in a future release. | ||
|
||
In the absence of a metric, an operator may test if the feature is present by |
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.
non-blocking
The idea here is that operators want to see if their users are making using of the feature. It helps them know two things: 1) is anyone using the feature, or is it safe to turn it off; 2) if no one is using it, then it can't be (or is unlikely to be) the source of some production issue (e.g., during troubleshooting)
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.
Thank you for the clarification. We likely will add a metric to measure the total time taken for the comparison in a later release.
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.
A metric that shows when ratcheting takes place in writes would be helpful here.
9a7663e
to
e6dc719
Compare
e6dc719
to
4ee52ed
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexzielenski, johnbelamaric, jpbetz 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 |
/lgtm |
/cc @cici37 @jpbetz @deads2k