Skip to content
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

Istio (v1.17.2) and Gateway API (v0.6.2) version bump #166

Merged
merged 3 commits into from
May 8, 2023
Merged

Conversation

guicassolato
Copy link
Contributor

@guicassolato guicassolato commented Apr 17, 2023

  • Bumps the version of Istio used for local dev and testing to v1.17.2.
  • Bumps the version of Gateway API to v0.6.2

Other co-dependencies updated:

  • sigs.k8s.io/controller-runtime (v0.14.6)
  • go.uber.org/zap (v1.24.0)

Bump version of Istio used for local dev and testing to 1.17.2.
@guicassolato guicassolato self-assigned this Apr 17, 2023
@guicassolato
Copy link
Contributor Author

guicassolato commented Apr 19, 2023

This is failing because of this: istio/istio.io#12630 (comment)

I.e. the second gateway created by the integration test case at

err := k8sClient.Create(context.Background(), gateway)
Expect(err).ToNot(HaveOccurred())

won't be ready, thus failing at this check that is performed by the controller when the targetRef.Kind == "Gateway":

if meta.IsStatusConditionFalse(gw.Status.Conditions, "Ready") {
return nil, fmt.Errorf("FetchValidGateway: gateway (%v) not ready", key)
}


Update: Adding here a couple more refs:

Updates sigs.k8s.io/gateway-api to v0.6.2.

Co-dependencies updated:
- sigs.k8s.io/controller-runtime (v0.14.6)
- go.uber.org/zap (v1.24.0)
@guicassolato guicassolato changed the title Bump Istio version to 1.17.2 Istio (v1.17.2) and Gateway API (v0.6.2) version bump May 5, 2023
@guicassolato guicassolato marked this pull request as ready for review May 5, 2023 09:59
@guicassolato guicassolato requested a review from a team as a code owner May 5, 2023 09:59
@mikenairn
Copy link
Member

mikenairn commented May 8, 2023

This seems to be making the same change to the gateway-api module as #153, but with far fewer changes. I think it's because you haven't changed the api version to v1beta1 #153 (comment). DO we not want to do that?

@guicassolato
Copy link
Contributor Author

This seems to be making the same change to the gateway-api module as #153, but with far fewer changes. I think it's because you haven't changed the api version to v1beta1 #153 (comment). DO we not want to do that?

@mikenairn

Focus here started on upgrading Istio. I ended bringing GWAPI v0.6 together due to dependencies.

With many CRDs now promoted to beta, I believe we do want to upgrade them in our code base as well. Perhaps an obvious consecutive step then would be rebasing and merging #153, right after this PR? Or you'd say it better done all at once as part of the same iteration? Either way works for me.

To have in mind that having Istio up to date is also important before moving to GWAPI v0.6.2. And related to that, this PR also fixes the status check of Gateway objects – from using Ready to now Programmed.

@mikenairn
Copy link
Member

With many CRDs now promoted to beta, I believe we do want to upgrade them in our code base as well. Perhaps an obvious consecutive step then would be rebasing and merging #153, right after this PR? Or you'd say it better done all at once as part of the same iteration? Either way works for me.

Yeah, lets just merge this and I'll update my PR to just update the api version we are using.

@guicassolato
Copy link
Contributor Author

guicassolato commented May 8, 2023

I've tested the changes in this PR with a custom build of the operator, bundle and catalog images pushed to quay.io:

  1. in a local Kubernetes cluster (instructions, with step 1 replaced by make local-setup), and
  2. in an OSD cluster with OpenShift Service Mesh 2.3.3 (instructions, with Kuadrant install replaced by make deploy-catalog CATALOG_IMG=quay.io/kuadrant/kuadrant-operator-catalog:gwapi-v0.6.2)

The changes worked in both scenarios.

In OpenShift, to workaround errors in OSSM related to the GWAPI version, I had to first install an older version of GWAPI and then upgrade it to v0.6.2 after OSSM had successfully started istiod-controlplane.


Update:

OSSM install failed before due to missing GWAPI CRDs when trying to install v0.6.2 directly with from kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.6.2":

$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/referencepolicies.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/tcproutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/tlsroutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/udproutes.gateway.networking.k8s.io created

$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.6.2" | kubectl apply -f -
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io configured
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io configured
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io configured

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/dependencies Changes dependencies
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants