-
Notifications
You must be signed in to change notification settings - Fork 502
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
Draft a policy for updating Go versions across the Kubernetes codebase/infra #1139
Comments
/sig release |
FWIW, I support upgrading. It will be a bit of work, but it will mean we continue to use supported go going forward. The gofmt incompatibility is only development time, and other changes should be safe and compatible, and we've already hopefully verified scaling issues with the newer go. |
This issue was at least partially motivated by the recent Go security releases. I think in the short term we should make new patch releases of k8s 1.11 and 1.12 with go1.10.8, but we should aim to move those to go1.11.x before go1.10 goes out of support next month. |
@BenTheElder @ixdy - i'd support this new policy cc @kubernetes/sig-release |
@BenTheElder @ixdy we should get buy-in from the current patch release managers too |
cc @foxish @feiskyer @aleksandra-malinowska, @tpepper @kubernetes/product-security-team |
I'm supportive of this policy too, but it will mean more work maintaining our release branches, especially with things like rules_go/bazel. |
if we don't want to maintain compatibility with the latest bazel + rules_go (historically we've generally kept those locked), we can always override the go version. We're already doing this on release-1.11: |
+1.
This seems easier to do upgrading. But with this, will there some build issues because of override? |
Seems like we must at least trial moving our old branches forward to golang 1.11.x over the next weeks then (ie: see if scale test especially are okay). In the meantime need to release updated k8s builds with the golang patch fix release of the versions we're current using. |
There shouldn't be. |
One catch: go1.10 -> go1.11 had a lot of breaking changes (fmt and vet), which makes the update harder than just "update the version". |
/priority important-soon |
Go 1.12 is out now, which means that Kubernetes 1.11 and 1.12 are both now using an unsupported version of Go (1.10). |
bumping go versions can cut both ways. as an example, golang/go#27044 caused bottleneck issues for clients that needed to open more than a few hundred watches (aggregator, kubelet). That issue is resolved in go1.12, which could be good to pick up, but the opposite would have happened when bumping to the version of go that first included golang/go#27044. |
hm, so it sounds like go1.11 had some pretty serious regressions for Kubernetes? what should we do, then? |
if we want to do this we should it ASAP! we still have a week and half away to code freeze. we will be slammed with PRs the closer we get to code freeze. bisect(s) are going to get harder with volume if we run into regressions. |
Speaking about this in SIG Release, I have no strong opinion at present on the version of go used for previous releases. I am willing to say yes if someone wants to try landing 1.12 support in master prior to Friday, otherwise I would rather punt this to the next release. |
I originally created this issue only to discuss updating the version of Go in older Kubernetes releases (notably k8s 1.11 and 1.12). |
I'm going to put on my RelEng lead hat and say, that at least for me, we're outside of the window where we should attempt this for 1.14. I think in general we need a pipeline that encodes the criteria we would use to evaluate the correctness of a go version bump. I would like to see such tooling applied to previously released versions of Kubernetes so we test again on lower risk targets. Let's perhaps work on some concrete requirements, in collaboration with SIGs like Scalability, and see some demos of how validation could work. /cc @hoegaarden |
This is the part that concerns me the most. Is it better to set ourselves up for needing to scramble to update and validate if (when?) go security releases come out, or to get ourselves on versions that will be supported for the duration of the k8s release's support life? |
Open PR to update master to 1.12: kubernetes/kubernetes#74632 Dunno if this is a 1.14.0 thing, or if we should leave it for later.. but at least we can get CI rolling and see how it performs. |
Please note that such scrambling still goes through some maintainers right now such as @ixdy with pretty low remaining bandwidth (AFAICT anyhow...) to push the necessary build images etc. |
The kubernetes 1.12 branch is now using an unsupported version of go (1.10.8). Have we come to a consensus on what we want to do about this? (Kubernetes 1.11 is also affected, but I'm not sure if we're planning any more support of that branch given that 1.14 has been released.) |
there is a latency regression and proxy flushing regression we need to resolve before we transition any other release branches to go1.12 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
This has been fixed in the meantime - flush was fixed in 1.12.1 (or 2) IIRC, and performance regression was fixed in 1.12.5 - so we should be safe. [BTW, we're also working with golang team now to validate upcoming 1.13 release, so that we won't be surprised again (at least from performance POV)]. |
@justaugustus @wojtek-t @feiskyer @ixdy - are we there yet? :) (what's left to be done) |
@cpanato @LappleApple unfortunately I will not be able to contribute to this work. |
@sethmccombs Hey, would you like to work on this? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
@kubernetes/release-engineering is pairing on the draft here: https://docs.google.com/document/d/1npm6aXRyXIgrgL1SRbFn16GkNGkTH7zWEYy4sO5JccU/edit?usp=drivesdk Dan is point. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Kubernetes produces a new minor release every 3 months, and currently supports the 3 most recent releases. This means that a given release is supported for around 8-9 months.
Go produces a new release approximately every 6 months, and supports the 2 most recent releases. This means that a given release is supported for about a year.
The release schedules are slightly out of sync, however; the newest Go release usually occurs close to code freeze for a Kubernetes release, so we do not update until the next minor release, trailing the Go release by a few months.
This means that we often end up supporting a Kubernetes release well past the Go version it's using was supported; for example, we supported Kubernetes 1.10 through December 2018, but Go 1.9 (which it used) went out of support at the end of August 2018.
Similarly, Kubernetes 1.11 (expected to be supported through March 2019) and Kubernetes 1.12 (expected to be supported through June 2019) use Go 1.10, but this release will likely go out of support by Februrary 2019.
Historically we had some performance issues with new Go releases, which is why we generally avoided updating close to code freeze. There have also been occasional incompatible changes (particularly around gofmt), which make updates messier.
Still, we've tested the latest Go release extensively on master (and even have a release using it, Kubernetes 1.13), so we should probably update our older release branches, and perhaps make this a new policy going forward.
From @justaugustus in kubernetes/test-infra#25355:
From @BenTheElder:
From @liggitt:
The text was updated successfully, but these errors were encountered: