versions: Bump golang from 1.8.3 to 1.9.7

[jodh-intel]

golang version 1.8.3 is old and the runtime cannot even be built with
it now it seems.

Since it is no longer considered a stable version [1], move to the
oldest official stable version (version 1.9.7).

Fixes #642.

[1] - https://golang.org/dl/

Signed-off-by: James O. D. Hunt james.o.hunt@intel.com

[jodh-intel]

/cc @chavafg.

[grahamwhaley]

lgtm

@chavafg @jodh-intel - do we need to tweak our Travis setup - I think we have a 1.8 job there?

[jodh-intel]

grep isn't finding that in https://github.com/kata-containers/ci, but does memory serve that Travis installs the packaged version of go (which might be 1.8.x) and we then install the correct version using https://github.com/kata-containers/tests/blob/master/.ci/install_go.sh @chavafg?

[grahamwhaley]

Ah, it may be in travis.yml in other repos that means I've seen it on the Travis reports:
https://github.com/kata-containers/proxy/blob/master/.travis.yml#L21
and in agent at least. Could be others.

[grahamwhaley]

This repo appears to Travis only 1.10, and that is reflected for instance in the relevant link for this PR
https://travis-ci.org/kata-containers/runtime/builds/420115962?utm_source=github_status&utm_medium=notification

I guess the question is, are we setting 1.9.x as the base for all the repos? I suspect the answer will be yes.

[jodh-intel]

ok great, so no further changes required for this repo though :)

[devimc]

lgtm

[codecov]

Codecov Report

Merging #643 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #643   +/-   ##
=======================================
  Coverage   65.35%   65.35%           
=======================================
  Files          85       85           
  Lines        9879     9879           
=======================================
  Hits         6456     6456           
  Misses       2766     2766           
  Partials      657      657

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• kata-runsh : TIMED_OUT in 1h 01m 12s

[bergwolf]

@jodh-intel Thanks for raising this. Is this version yaml used to build kata packages we ship? If so, I would suggest that we use the latest stable go compiler instead. Newer compilers have a lot of improvements that can benefit kata users.

For old go compilers, we can do a simply sanity check by building with them. travis-ci can be a good place to play such compile only tests.

[jodh-intel]

Hi @bergwolf - see kata-containers/packaging#147 regarding the version of golang we use for package builds.

I do wonder if we want to re-assess whether we need to specify two go versions in versions.yaml any more.

@jcvenegas, @chavafg - wdyt? Is languages.golang.meta.newest-version in versions.yaml still useful or could we just drop it and only have languages.golang.version?

[bergwolf]

@jodh-intel Thanks for the pointers. I think we can:

1. build with different go versions
2. test and ship with the latest stable go version

I don't remember we have any dependency on golang versions yet. If we do, we can declare a minimal go version to support (like 1.9.7).

WDYT?

[katacontainersbot]

PSS Measurement:
Qemu: 165709 KB
Proxy: 4006 KB
Shim: 8890 KB

Memory inside container:
Total Memory: 2043464 KB
Free Memory: 2003572 KB

[chavafg]

lgtm

I see that tests, proxy shim... repositories have different go versions in their .travis.yml. We should also change them to the same here.

For jenkins we use the .ci/install_go.sh, which reads languages.golang.meta.newest-version.

I agree that we can stick to only one version.

[caoruidong]

"not ok 2 Running within memory constraints"
This test fails on many PRs, like kata-containers/agent#331.
But we just bump golang version. No idea about why.

[WeiZhang555]

1. build with different go versions
2. test and ship with the latest stable go version

I agree with @bergwolf , this looks reasonable

[jodh-intel]

Hi @bergwolf,

• build with different go versions

I'm not quite clear what you mean here - do you mean we should build each component with a range of go versions (like we do in some of the .travis.yml files)? Or do you mean we should all the CI's to build with any version of go they like (as long as it's => minimum supported version and <= latest stable version)?

• test and ship with the latest stable go version

Ah - so presumably you mean we should run all CI + packaging using the same version (latest stable) - sounds good to me.

I don't remember we have any dependency on golang versions yet.

I had thought there was a reason we standardised on 1.8.3. Maybe clearcontainers/runtime@c5569a5 but @sboeuf may remember more :)

If we do, we can declare a minimal go version to support (like 1.9.7).

I might be misunderstanding, but that's the intention of this PR - to update the minimum version we will use for CI + packaging.

[WeiZhang555]

Hi @jodh-intel , today I debugged a bit and find that it may need little change to fix golang 1.8.3 build, so I raised another PR #662 to address this, I think it's better to fix the build issue though 1.8.3 is not stable anymore. What do you think?

This PR is still valid despite of #662 so we can still merge it.

[opendev-zuul]

Build failed (third-party-check pipeline) integration testing with
OpenStack. For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

• kata-runsh : RETRY_LIMIT in 5m 33s

[katacontainersbot]

PSS Measurement:
Qemu: 169077 KB
Proxy: 4006 KB
Shim: 8996 KB

Memory inside container:
Total Memory: 2043464 KB
Free Memory: 2003564 KB

[WeiZhang555]

@jodh-intel How about update golang to latest stable 1.11?

[jodh-intel]

Sounds like a good idea. But I'm still not clear on the best approach here. Your recent #662 suggests folk do still care about older versions of go, but should we leave such PRs up to those in the community that do care, or just constantly follow the "tip" (1.11)?

Maybe we should change the golang entry in the versions database to something like:

diff --git a/versions.yaml b/versions.yaml
index 145e8aa..76c0740 100644
--- a/versions.yaml
+++ b/versions.yaml
@@ -183,9 +183,9 @@ languages:
   golang:
     description: "Google's 'go' language"
     notes: "'version' is the default minimum version used by this project."
-    version: "1.8.3"
+    version: "1.11"
     meta:
-      newest-version: "1.10"
+      oldest-version: "1.8.3"

But if we do that, who / what will ensure that we haven't broken support for oldest-version? I don't think our current CI has sufficient capacity to test with >1 golang versions but maybe that situation will change if zuul ever happens (kata-containers/ci#42).

Related:

• Decide on golang version strategy kata-containers#15
• Detect updated external versions kata-containers#30

/cc @grahamwhaley, @chavafg, @jcvenegas, @egernst, @bergwolf.

[sboeuf]

This conversation has to continue and as @jodh-intel mentioned, maybe testing several version of Golang might be a good idea if we have enough CI resources.
But for the moment (cc @jodh-intel @WeiZhang555), I think it's still better to move to 1.9.7 given the fact this is the oldest latest stable, and that 1.8.3 is too old.