-
Notifications
You must be signed in to change notification settings - Fork 460
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
Providing more detailed upgrade notes for v1.1 #3084
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
This is better than what we had before, although we can probably iterate on this forever... 😐 /lgtm |
### v1.1 Upgrade Notes | ||
If you are already using previous versions of GRPCRoute or BackendTLSPolicy | ||
experimental channel CRDs from previous Gateway API releases, you'll need to be | ||
careful with this upgrade. If you haven't installed Gateway API before, or have |
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.
you
here is the user, but most users today dont install Gateway API CRDs, they rely on implementations to install Gateway API CRDs and in some cases like GKE where the cloud provider installs it
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.
Do you have any examples of implementations bundling CRDs? So far we've recommended that CRD management is owned by users or cluster providers (https://gateway-api.sigs.k8s.io/guides/crd-management/#who-should-manage-crds).
GRPCRoute excludes v1alpha2. All implementations of GRPCRoute built before the | ||
v1.1 release of Gateway API would have exclusively relied on v1alpha2 and will | ||
need to be updated to support GRPCRoute v1. Until implementations have been | ||
updated to support v1, you can safely upgrade to the experimental channel | ||
version of GRPCRoute included in v1.1 that exposes both v1 and v1alpha2. |
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 basically means that the upgrade path we recommend is to first upgrade the GWAPI CRD to v1.1, and then update the specific implementation, right?
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.
Good point, pushed a more detailed set of recommended steps that should make this clearer. PTAL.
c85ff29
to
aa99321
Compare
This is a great change, nice work @robscott /lgtm |
1. Install *experimental* v1.1 GRPCRoute CRD | ||
2. Update all your manifests to use `v1` instead of `v1alpha2` | ||
3. Upgrade to an implementation that supports GRPCRoute `v1` API Version | ||
4. Install *standard* channel v1.1 GRPCRoute CRD |
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.
Should we mention as point 5 to re-apply all the manifests that were updated in step 2?
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.
Do we need a step to clean up CRDs that are not included in the standard channel?
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.
Good questions, re-applying isn't necessary in this case because although the standard channel version of GRPCRoute does not expose v1alpha2 for reads or writes, it does include the schema so it can auto-convert as needed.
I also don't think we need to cover cleaning up old experimental CRDs since this is entirely focused on GRPCRoute, and the experimental version would be cleaned up when upgrading to standard channel. I think it's still valid to have other resources like BackendTLSPolicy that are only in standard channel, though we admittedly have not been very clear about our policy of mixing and matching resources from different channels...
Open to follow ups on either front, but I think this PR is overall a good enough improvement to get in now and then just iterate as needed from 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.
/lgtm
Thanks for all the great feedback everyone! /hold cancel |
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Provides upgrade notes to help address common pain points for users upgrading to v1.1.
Does this PR introduce a user-facing change?: