-
Notifications
You must be signed in to change notification settings - Fork 468
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 GatewayConditionAccepted and GatewayReasonAccepted #1447
add GatewayConditionAccepted and GatewayReasonAccepted #1447
Conversation
deprecate GatewayConditionScheduled and GatewayReasonScheduled
12916c3
to
990299c
Compare
apis/v1alpha2/gateway_types.go
Outdated
// true. | ||
// True. This reason is deprecated and GatewayReasonAccepted should be used | ||
// with GatewayConditionAccepted instead. | ||
// TODO: is there a need/way to add a kubebuilder annotation here? |
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 am only aware of the kubebuilder:deprecatedversion
tag as per the kubebuilder CRD generation documentation, which does not apply here because it marks the entire version as deprecated. I am not aware of any way to call a specific field deprecated. I think we can just use the godoc
you've already provided explaining that it's deprecated for now, maybe we can open/find an upstream issue to add something that automates this for us in kubebuilder 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.
Something similar was proposed but ended up getting turned down: kubernetes/enhancements#3340.
Removed TODOs and switched deprecation warnings from passive to active voice, think this should be ready to go now. |
Thanks! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mikemorris, robscott 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 |
Give v0.6.0 is not a new API version, what is the expected behavior of implementors here? Must set both? |
What type of PR is this?
/kind cleanup
/kind documentation
/kind api-change
/kind deprecation
What this PR does / why we need it:
Implements the recommendation in GEP-1364 to replace
GatewayConditionScheduled
withGatewayConditionAccepted
Which issue(s) this PR fixes:
Refs #1111, #1364
Does this PR introduce a user-facing change?:
This status condition does not appear to be currently checked in conformance tests, which mostly rely on the
Ready
condition instead. We could either add checks for this condition now, or in a subsequent pull request.