-
Notifications
You must be signed in to change notification settings - Fork 30
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
⬆️ Bump Gateway API to v0.5.0-rc1 #311
Conversation
@carlisia: The label(s) 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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: carlisia 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 |
c/c @nak3 @evankanderson |
Codecov Report
@@ Coverage Diff @@
## main #311 +/- ##
=======================================
Coverage 12.91% 12.91%
=======================================
Files 20 20
Lines 2958 2958
=======================================
Hits 382 382
Misses 2554 2554
Partials 22 22 Continue to review full report at Codecov.
|
As we are focusing on tackling Contour first, I wonder if I could comment out the Istio tests that are failing so we could lean in on CI and automation to run the Contour tests, for now? |
go.mod
Outdated
k8s.io/apimachinery v0.24.1 => k8s.io/apimachinery v0.23.8 | ||
k8s.io/client-go v0.24.1 => k8s.io/client-go v0.23.8 | ||
k8s.io/code-generator v0.24.1 => k8s.io/code-generator v0.23.8 | ||
sigs.k8s.io/gateway-api v0.5.0-rc1 => sigs.k8s.io/gateway-api v0.4.0 |
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 think we should not close #306 yet (or track it by another issue) if we keep using v0.4.0.
One quick Q, as commented #311 (comment), this PR bumps CRD files from 0.4.0's to 0.5.0-rc1 but does not bump the libs yet. Will you update the deps in this PR or the follow up PR? |
I assume that "the failing Istio tests" means this issue in KinD conformance test. If so, I think we should add it to the skip test or just ignore it. I tracked the issue #185 but no progress yet. Actually for Contour, it looks like stable than Istio, but Contour just skips the tests (or you can see the doc). |
Ah great that there's an issue for that. I'll skip it then.
Yes. There is a "Create tracking issues for knative conformance tests that are failing" in the Gateway API Roadmap. After this upgrade gets merged I'll be commenting out those tests and creating issues for the ones that fail. But glad you pointed that out. |
There is an issue (#307) to track upgrading to the actual I wanted to upgrade the deps on this PR. But due to the deps on
Update on 6/25: I found what I was doing wrong (not just inverting the |
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 wonder if it would be simpler to review as "bump to Go 1.17" and "use gateway-api 0.5.0-rc1". I think the first would be trivial to review, but I'm not sure we have the second quite right yet.
@@ -94,7 +94,7 @@ source ./hack/test-env.sh | |||
#### Install Gateway API CRDs | |||
|
|||
``` | |||
kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd?ref=${GATEWAY_API_VERSION}" | |||
kubectl apply -f config/100-gateway-api.yaml |
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.
It feels strange to be copying the definitions into our repo, rather than referencing some upstream artifact (even if it's a raw or nightly reference rather than a release).
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.
It feels practical to me rather than strange. If I'm using artifacts to change/test the code, I'd rather have it sitting on my machine rather than going over the network. And in this case I can control/change the version I want by changing the version variable the codegen uses. Fetch once/run locally with the same copy. Is this an anti-pattern?
go.mod
Outdated
k8s.io/api v0.24.1 => k8s.io/api v0.23.8 | ||
k8s.io/apimachinery v0.24.1 => k8s.io/apimachinery v0.23.8 | ||
k8s.io/client-go v0.24.1 => k8s.io/client-go v0.23.8 | ||
k8s.io/code-generator v0.24.1 => k8s.io/code-generator v0.23.8 | ||
sigs.k8s.io/gateway-api v0.5.0-rc1 => sigs.k8s.io/gateway-api v0.4.0 |
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.
Aren't these replace
lines backwards? (As evidenced by lack of changes to go.mod
)
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.
Likely. I did it both ways just to be sure to attain the most suffering, ended up picking the wrong one evidently. Will fix, thanks for pointing it out.
@@ -18,3 +27,78 @@ require ( | |||
sigs.k8s.io/gateway-api v0.4.0 | |||
sigs.k8s.io/yaml v1.3.0 | |||
) | |||
|
|||
require ( |
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.
What added all these indirect definitions? The switch to Go 1.16?
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.
Yes. Nit correction: switch to Go 1.17 (I know that's what you meant).
echo "# Generated with \"kubectl kustomize https://github.com/kubernetes-sigs/gateway-api/config/crd?ref=${GATEWAY_API_VERSION}\"" > ${REPO_ROOT_DIR}/config/100-gateway-api.yaml | ||
kubectl kustomize "https://github.com/kubernetes-sigs/gateway-api/config/crd?ref=${GATEWAY_API_VERSION}" >> ${REPO_ROOT_DIR}/config/100-gateway-api.yaml | ||
echo "# Generated with \"kubectl kustomize github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=${GATEWAY_API_VERSION}" > "${REPO_ROOT_DIR}/config/100-gateway-api.yaml" | ||
kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=${GATEWAY_API_VERSION}" >> "${REPO_ROOT_DIR}/config/100-gateway-api.yaml" |
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.
It looks like the 100-gateway-api.yaml
is usually auto-created. Maybe we should .gitignore
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.
I guess i want to roll back and understand what this file is intended for. Would like to get a read from @nak3, since he paved the way here and might have some thoughts.
To recap:
What is in main
now:
- this file is generated by codegen but not being used anywhere as far as I can tell. I assumed it was serving as a local example of what this component is working with for any given release of the Gateway API that we use.
What changes in this PR:
- codegen is updated to generate a new set of CRDs based on the upcoming
v0.5.0
version (changes a bit). - since this file was there anyway, I changed whatever was pointing at the the upstream (DEVELOPMENT.md and the Istio conformance test) to point at the local file instead. Might be my beginner roots speaking from the era when network was sparse and expensive to nonexisting (and the dinosaurs roamed the earth!) but I still think it's more practical for development.
If pointing to upstream to get a copy of these resources has an advantage over pointing at a local copy (which can be refreshed, to be sure) that I'm not seeing, I can change those references to point upstream.
If this file ends up having no solid purpose for our use at the moment, I would say maybe not even keep maintaining this code generation and the overhead in time that it adds to running that script?
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'm concerned that having this file checked in to config
(vs third_party
or somewhere else) will cause it to be collected and bundled into the release.
I can understand wanting to vendor this somewhere rather than fetch it from the Internet; my primary concern is putting it next to the configs we release with ko resolve -f $DIR
.
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.
Sorry yes we should not add the gateway-api CRD into config
directory but should add it into third_party
as Evan mentioned.
The reason why I added it into config
(actually release net-gateway-api.yaml
) was that we must install the GatewayAPI CRD before the net-gateway-api controller and Istio/Contour. So, I struggled to modify the ytt
& kapp
in serving repo and in the end, I added it into the head of net-gateway-api.yaml
but I am sure that is not ideal.
Probably you have knowledge for the two vmware CLI tools, so I would like you to move the file into third_party
and modify the test script in serving repo.
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.
That makes sense. And yes, I can tackle the ytt stuff. Will move the file and add an issue for this. Thanks for the clarification.
I usually waited for the k8s libs in pkg repo was updated to the gateway-api repo's version like: knative/pkg#1881 Do you need v0.5.0-rc1 urgently? If not urgent, I think we just wait that knative/pkg updates to the k8s lib to 0.24.1+. |
@carlisia: The following tests failed, say
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. I understand the commands that are listed here. |
PS: I haven't updated the code (tests) to point to the new changes in the Gateway API spec yet, want to resolve the above issue first. |
This worked for me - make sure you run diff --git a/hack/update-codegen.sh b/hack/update-codegen.sh
index e1fa3cbd..ae365d94 100755
--- a/hack/update-codegen.sh
+++ b/hack/update-codegen.sh
@@ -29,7 +29,7 @@ group "Gateway API Codegen"
# Gateway API
${CODEGEN_PKG}/generate-groups.sh "client,informer,lister" \
knative.dev/net-gateway-api/pkg/client/gatewayapi sigs.k8s.io/gateway-api \
- "apis:v1alpha2" \
+ "apis:v1alpha2 apis:v1beta1" \
--go-header-file ${REPO_ROOT_DIR}/hack/boilerplate/boilerplate.go.txt
## Gateway API |
Thanks for all the feedback so far. Closing this in favor of braking this into smaller PRs. First one: |
This is work in preparation for upgrading to v0.5.0, so we can start running and fixing/adding tests.
Tackling Contour first. Istio would be next.
Changes
/kind
Fixes #
#306
Release Note
Docs