-
Notifications
You must be signed in to change notification settings - Fork 39k
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
go1.14 fixup #92438
go1.14 fixup #92438
Conversation
/lgtm |
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.
@liggitt -- One blocking question about dependencies.yaml
And then, non-blocking: what's the signal on when/if we should make these changes in staging? Should this be part of the go bump docs?
/hold
@@ -468,7 +468,7 @@ EOF | |||
local go_version | |||
IFS=" " read -ra go_version <<< "$(go version)" | |||
local minimum_go_version | |||
minimum_go_version=go1.13.4 | |||
minimum_go_version=go1.14.4 |
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 this always be the latest go version we've bumped to?
If so, can you add an entry in build/dependencies.yaml for this path/regex?
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 should, BUT that would require the image bump to go in before the PR, FWIW
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.
Ooof. Chicken and egg! Thanks for clarifying, @BenTheElder!
/hold cancel
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.
we still have this chicken and egg either way, the question is just which repo we want to merge first 🤷♂️
/test pull-kubernetes-integration |
/hold still working through staticcheck, golang.org/x/... deps, and hack/update-vendor failures |
…enses, preserve explicit imports in modules.txt
awesome, platform-specific staticcheck differences... fixed up in https://github.com/kubernetes/kubernetes/compare/b55f384056dfd975b760fb1ae7264e8320dca287..d9bb0b8ee18fe68654ef1a68611f905859b3b7bc |
/lgtm |
/retest |
grr /retest |
/retest |
@liggitt: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. |
Why was support for 1.13 dropped? |
Kubernetes has long supported only one specific go version.
…On Sun, Jun 28, 2020, 21:34 Akihiro Suda ***@***.***> wrote:
Why was support for 1.13 dropped?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHADK2GDYFG2CUH6C7APA3RZAKU7ANCNFSM4OF6RV3A>
.
|
I suggest continuing support for Go 1.13 exceptionally. Go 1.14 introduced a breaking change that requires retrying syscall executions on receiving EINTR: https://golang.org/doc/go1.14#runtime Because of this change, a lot of runtime components including containerd, runc (<= rc90), Moby, and CNI haven't yet migrated to Go 1.14. Also, I even doubt that Kubernetes has really completed support for Go 1.14. $ git grep EINTR | grep -v ^vendor
pkg/kubelet/eviction/threshold_notifier_linux.go: if err == unix.EINTR { ( Fortunately migration to Go 1.15 would be much smoother, as Go 1.15 can handle most of the EINTR stuffs automatically: https://tip.golang.org/doc/go1.15#os ) |
Given the support window of go1.13 (it will go out of support before Kubernetes 1.19 is released), I think k8s 1.19 will stay on go1.14+ I opened #92611 as an experiment for what it could look like to isolate the bits that actually required go1.14 to let someone who wanted to build with k8s libraries build with go1.13. Since that change appears to be very small, I'd be amenable to keeping that in place until we move to go1.15. |
Downstream build pipelines should not be depending on a single host go
binary, we make no guarantees about what timeframe we will upgrade go in.
Any such pipeline may again be broken in the future.
The containerized and bazel builds both offer building using go binaries
managed by the project's build.
…On Mon, Jun 29, 2020, 10:26 Jordan Liggitt ***@***.***> wrote:
Given the support window of go1.13 (it will go out of support before
Kubernetes 1.19 is released), I think k8s 1.19 will stay on go1.14+
I opened #92611 <#92611> as
an experiment for what it could look like to isolate the bits that actually
required go1.14 to let someone who wanted to build with k8s libraries build
with go1.13. Since that change appears to be very small, I'd be amenable to
keeping that in place until we move to go1.15.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92438 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHADK7RQUOVAHYJUA3MP6LRZDFDFANCNFSM4OF6RV3A>
.
|
I'm less concerned about build pipelines building kubernetes components, and am more sympathetic to something using the published k8s libraries. |
What type of PR is this?
/kind cleanup
follow-up to #88638
/sig release