add GatewayConditionAccepted and GatewayReasonAccepted#1447
add GatewayConditionAccepted and GatewayReasonAccepted#1447k8s-ci-robot merged 2 commits intokubernetes-sigs:mainfrom
Conversation
k8s-ci-robot
added
kind/cleanup
k8s-ci-robot
added
the
size/M
deprecate GatewayConditionScheduled and GatewayReasonScheduled
mikemorris
force-pushed
the
gateway-condition-accepted
branch
from
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.
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.
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 |
k8s-ci-robot
added
the
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 DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
Give v0.6.0 is not a new API version, what is the expected behavior of implementors here? Must set both? |
5 participants
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
GatewayConditionScheduledwithGatewayConditionAcceptedWhich 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
Readycondition instead. We could either add checks for this condition now, or in a subsequent pull request.