Graduating GRPCRoute to GA #2919
Conversation
k8s-ci-robot
added
release-note
k8s-ci-robot
added
approved
|
/cc @gnossen |
|
@robscott: GitHub didn't allow me to request PR reviews from the following users: gnossen. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
| @@ -0,0 +1,618 @@ | |||
| /* | |||
There was a problem hiding this comment.
For the record, I used git mv here to try to maintain git history. That appears to have worked everywhere but the GitHub UI.
|
This is a big PR, adding a hold until we've got multiple LGTMs or approvals. /hold |
k8s-ci-robot
added
the
do-not-merge/hold
robscott
added
the
tide/merge-method-rebase
|
Looks good here! |
|
@shaneutt: GitHub didn't allow me to request PR reviews from the following users: gnossen. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
k8s-ci-robot
added
the
lgtm
How does not serving v1alpha2 in standard channel help migrations? |
Yeah that's unnecessarily confusing. In my head I was comparing it to not including v1alpha2 at all. Including but not serving v1alpha2 has the affect of enabling the v1.1 GRPCRoute standard channel CRD to be installed in clusters that previously had the experimental channel GRPCRoute CRD (any version). It does also mean that in that upgrade scenario, users would also need to upgrade their manifests to v1 for any future updates to GRPCRoute config. I feel pretty strongly that standard channel CRDs should never support reads or writes to alpha API versions. If we were to expose alpha API versions in standard channel, we'd either have to deal with version deprecations in standard channel or never remove alpha, neither of which seem great. |
k8s-ci-robot
added
the
needs-rebase
|
🤬 My (now-deleted) comment above really should've been on #2912, in fact, sorry about that. Taking that discussion over there and deleting the comment that shouldn't ever have been posted here. 🤦♂️ |
|
/lgtm |
k8s-ci-robot
removed
the
lgtm
k8s-ci-robot
removed
the
needs-rebase
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kflynn, robscott, shaneutt 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 |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm 🙂 |
k8s-ci-robot
added
the
lgtm
In kubernetes-sigs#2919 the version of GRPCRoutes in conformance tests was updated from v1alpha2 to v1. However, two GRPCRoutes were not updated. This commits fixes the version in those omitted two GRPCRoutes.
In #2919 the version of GRPCRoutes in conformance tests was updated from v1alpha2 to v1. However, two GRPCRoutes were not updated. This commits fixes the version in those omitted two GRPCRoutes.
What type of PR is this?
/kind documentation
/kind feature
What this PR does / why we need it:
This PR graduates GRPCRoute to GA. This means the following:
v1API version that is identical tov1alpha2v1in both standard and experimental channel - note that this makes it impossible to roll back to v1.0 CRDs, but since this is otherwise a no-op change, I think that's acceptablev1alpha2is served in experimental channel but is not served in standard channel. This is primarily to ease the migration for anyone upgrading from earlier usage of GRPCRoute while also avoiding any usage of alpha APIs in standard channel.Does this PR introduce a user-facing change?: