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
Upgrade to Go 1.18 and to operator-sdk 1.23 (fixes #681) #694
Conversation
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've kept separate commits so far for clarity, but I will squash everything together when merging.
github.com/bombsimon/logrusr/v2 v2.0.1 | ||
github.com/cespare/xxhash/v2 v2.1.2 // indirect |
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 moved all indirect dependencies to the second require block below.
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.
While this may look prettier, sadly it's pretty futile. Next time someone runs go mod tidy
, it will mess things up. Or go get -d
.
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.
Yeah, maybe we can just clean things up manually from time to time...
) | ||
|
||
require ( | ||
github.com/apache/tinkerpop/gremlin-go v0.0.0-20220530191148-29272fa563ec |
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.
Not sure why there was a dedicated require block for this, I moved it to the first one above.
sigs.k8s.io/yaml v1.3.0 | ||
) | ||
|
||
require ( | ||
cloud.google.com/go v0.93.3 // indirect | ||
cloud.google.com/go v0.81.0 // indirect |
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.
My assumption is that indirect dependencies are managed by go mod
, not edited by us manually.
So after updating direct dependencies, I deleted all the indirect ones and re-ran go mod tidy
to restart from a clean slate.
But this results in a few lower versions like this one, I'm not sure why.
I can revisit this if this wasn't the correct approach.
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.
The go mod
commands are not "stable" in a sense that they would generate same output each time. I'm assuming they use map[] underneath for dependency graphs and resolve, in which case the iteration order is random and as such can generate different output.
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.
So do you think the discrepancy matters here? It looks like if the version is higher than what tidy
would suggest, it's not modified. I can go back to the versions from main
and re-run 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 can go back to the versions from
main
and re-run it.
If I do that I get those differences:
- cloud.google.com/go v0.81.0 // indirect
+ cloud.google.com/go v0.93.3 // indirect
- github.com/Azure/go-autorest/autorest v0.11.18 // indirect
- github.com/Azure/go-autorest/autorest/adal v0.9.13 // indirect
+ github.com/Azure/go-autorest/autorest v0.11.20 // indirect
+ github.com/Azure/go-autorest/autorest/adal v0.9.15 // indirect
- github.com/form3tech-oss/jwt-go v3.2.3+incompatible // indirect
+ github.com/golang-jwt/jwt/v4 v4.0.0 // indirect
+ github.com/golang/snappy v0.0.4 // indirect
- go.uber.org/atomic v1.7.0 // indirect
+ go.uber.org/atomic v1.9.0 // indirect
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 don't think it matters which one it picks as long as it compiles afterwards. Clearly there's two dependencies which have different version of certain module, so picking either one could break the other.
Codecov Report
@@ Coverage Diff @@
## main #694 +/- ##
==========================================
+ Coverage 52.88% 52.94% +0.06%
==========================================
Files 80 80
Lines 8228 8231 +3
==========================================
+ Hits 4351 4358 +7
+ Misses 3426 3424 -2
+ Partials 451 449 -2
|
CHANGELOG/CHANGELOG-1.2.md
Outdated
## V1.2.2 | ||
|
||
* [ENHANCEMENT] [#681](https://github.com/k8ssandra/k8ssandra-operator/issues/681) Update to Go 1.18, Kubernetes 1.24, | ||
Operator SDK 1.23, controller-gen 0.9.2, Kustomize 4.5.7, controller-runtime 0.12.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.
Nit, but lets keep these one line (instead of extra forced line changes). Helps rendering.
docs/developer/README.md
Outdated
@@ -1,5 +1,5 @@ | |||
# Requirements | |||
* Go >= 1.17 | |||
* Go >= 1.18 | |||
* kubectl >= 1.17 |
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.
These other requirements are wrong since we just updated our tools. We don't know if things work with kubectl 1.17 (well, they won't) since we're on 1.24. And same for kustomize 4.0.5, which I don't think works.
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.
Right, I didn't give this the attention it deserved (because I have more recent versions installed).
I will set:
- kubectl to 1.23 (based on the version skew policy docs)
- Kustomize to 4.5.7. Maybe older versions work, but I don't think trying them is worth the time. Also it's the current version installed by package managers (brew, etc.)
- Kind to 0.15.0, for the same reasons.
I'll also update default_kind_node_version
in setup-kind-multicluster.sh
.
controller-gen: ## Download controller-gen locally if necessary. | ||
$(call go-get-tool,$(CONTROLLER_GEN),sigs.k8s.io/controller-tools/cmd/controller-gen@v0.8.0) | ||
KUSTOMIZE_INSTALL_SCRIPT ?= "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | ||
.PHONY: kustomize |
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.
.PHONY should be in every Makefile target or none I guess. Now the behavior changes per target. I prefer every target, since we're not dealing with files (other than the $(LOCALBIN) target)
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.
Yeah this was already inconsistent before it seems.
I can do it here, or on a separate PR if we don't want to mix the changes.
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.
Separate PR is fine.
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.
@@ -38,6 +38,17 @@ IMAGE_TAG_BASE ?= k8ssandra/k8ssandra-operator | |||
# You can use it as an arg. (E.g make bundle-build BUNDLE_IMG=<some-registry>/<project-name-bundle>:<tag>) | |||
BUNDLE_IMG ?= $(IMAGE_TAG_BASE)-bundle:v$(VERSION) | |||
|
|||
# BUNDLE_GEN_FLAGS are the flags passed to the operator-sdk generate bundle command | |||
BUNDLE_GEN_FLAGS ?= -q --overwrite --version $(VERSION) $(BUNDLE_METADATA_OPTS) |
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 code isn't used anywhere.
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.
Right, I need to reference the new variable when calling generate bundle
in the bundle
target.
Btw this also needs to be done in cass-operator.
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.
Yep, though it's not high severity (k8ssandra-operator does not use bundles and cass-operator uses separate script when digests are used)
# To enable set flag to true | ||
USE_IMAGE_DIGESTS ?= false | ||
ifeq ($(USE_IMAGE_DIGESTS), true) | ||
BUNDLE_GEN_FLAGS += --use-image-digests |
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.
Same here, this code isn't used anywhere.
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.
kuttl wasn't updated, the first Go 1.18 version is 0.12.1, but 0.13.0 is maybe better.
Why did you revert kind image? Now our envtest is 1.24.2, but we run manually on 1.22? That could lead to interesting cases. |
All the e2e tests are failing with the 1.24 image. I'm going to debug locally. |
name: k8ssandra-operator-token | ||
annotations: | ||
kubernetes.io/service-account.name: "k8ssandra-operator" | ||
type: kubernetes.io/service-account-token |
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 solves the issue with Kind 1.24+ images. From the Kubernetes 1.24 upgrade notes:
- The
LegacyServiceAccountTokenNoAutoGeneration
feature gate is beta, and enabled by default. When enabled, Secret API objects containing service account tokens are no longer auto-generated for every ServiceAccount. Use the TokenRequest API to acquire service account tokens, or if a non-expiring token is required, create a Secret API object for the token controller to populate with a service account token by following this guide.
I used the second option which is functionally equivalent to what we had before. But maybe we should investigate how TokenRequest
could be used.
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.
Excellent. Yes, we should indeed move to a newer API at some point (I didn't check the version ranges - but those are always problematic in Kubernetes). If you wish to create tickets, that would be nice.
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.
Current test failures:
I'm going to re-run them. |
(from Operator SDK upgrade guide)
What this PR does:
Update to Go 1.18, Kubernetes 1.24, Operator SDK 1.23, controller-gen 0.9.2, Kustomize 4.5.7, controller-runtime 0.12.2.
Which issue(s) this PR fixes:
Fixes #681
Checklist