Providing more detailed upgrade notes for v1.1 #3084
Conversation
k8s-ci-robot
added
release-note-none
|
[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 |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
the
size/M
|
This is better than what we had before, although we can probably iterate on this forever... 😐 /lgtm |
k8s-ci-robot
added
the
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.
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.
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.
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.
Good point, pushed a more detailed set of recommended steps that should make this clearer. PTAL.
robscott
force-pushed
the
v1.1-upgrade-docs
branch
from
c85ff29
to
aa99321
Compare
k8s-ci-robot
removed
the
lgtm
|
This is a great change, nice work @robscott /lgtm |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
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.
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.
Do we need a step to clean up CRDs that are not included in the standard channel?
There was a problem hiding this comment.
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.
|
Thanks for all the great feedback everyone! /hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
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?: