client-go: Problems building Go application with client-go

Problem Description

I am not being able to compile my application due to client-go. I am working on a different scheduler for Kubernetes. These are my main dependencies:

Dependencies

k8sApi "k8s.io/api/core/v1"
k8sSchedulerApi "k8s.io/kubernetes/pkg/scheduler/apis/extender/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes"
"k8s.io/client-go/rest"

Compilation Error

k8s.io/client-go/transport
..\k8s.io\client-go\transport\round_trippers.go:70:11: cannot convert klog.V(9) (type klog.Verbose) >to type bool
..\k8s.io\client-go\transport\round_trippers.go:72:11: cannot convert klog.V(8) (type klog.Verbose) >to type bool
..\k8s.io\client-go\transport\round_trippers.go:74:11: cannot convert klog.V(7) (type klog.Verbose) >to type bool
..\k8s.io\client-go\transport\round_trippers.go:76:11: cannot convert klog.V(6) (type klog.Verbose) >to type bool

I tried to use go.mod but I had no success, unable to sync packages:

go: finding k8s.io/kubernetes/pkg latest
go: finding k8s.io/kubernetes/pkg/scheduler/apis latest
go: finding k8s.io/kubernetes/pkg/scheduler/apis/extender latest
go: finding k8s.io/kubernetes/pkg/scheduler latest
go: k8s.io/kubernetes@v1.17.3 requires
	k8s.io/api@v0.0.0: reading k8s.io/api/go.mod at revision v0.0.0: unknown revision v0.0.0

go.mod:

go 1.13

require (
	golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d // indirect
	golang.org/x/time v0.0.0-20191024005414-555d28b269f0 // indirect
	k8s.io/api v0.17.3
	k8s.io/apimachinery v0.17.3
	k8s.io/client-go v11.0.0+incompatible
	k8s.io/utils v0.0.0-20200124190032-861946025e34 // indirect
)

Any way to make it work with or without go.mod? How it is supposed to write the Dockerfile?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 22 (3 by maintainers)

Most upvoted comments

same problem

lozenko on Apr 29, 2020

I have the same problem.

gosoon on Apr 3, 2020

This is really painful for upgrades, and the selected version scheme conflicts with minimum version selection in nuanced and complex ways. Is there any plan to improve things, or are you indicating that it is not yet painful enough to justify investment?

Spitballing alternatives:

Move to semver such that compatibility guarantees are provided:
- from: v0.18.2
- to: v18.2.0
- This was initially one of the proposed versioning schemes, but was turned down.
- This could conflict with old releases like v11.0.0, but since nothing lower than v0.15.8 has been released this year, it seems moot.
Move to a new import path prefix, either a new domain or a new folder:
- from: k8s.io/api
- to: k8s.dev/api
- or: k8s.io/v/api
Move to a prohibitively large major, and keep rolling:
- from: v0.18.2
- to: v99.18.2
- This has the same effect of a new folder, since k8s.io/api/v99 is the import path.

carnott-snap on May 13, 2020

Sorry for the noise but I’ve just resolved this by doing:

replace (
	github.com/googleapis/gnostic => github.com/googleapis/gnostic v0.3.1
        ...
)

EwanValentine on Mar 14, 2020

using go1.16 (which honors the retract directives we just added), go get k8s.io/client-go@latest will resolve to the latest unretracted version, and works as expected:

go version
go version go1.16 darwin/amd64

go mod init myexample
go: creating new go.mod: module myexample

go get k8s.io/client-go
go get: added k8s.io/client-go v0.20.4

Deleting the old tags has all the downsides of disrupting builds of older clients, and wouldn’t remove cached versions of those versions held by things like the module proxy.

Explicitly specifying the version you want with go get k8s.io/client-go@$version or using go1.16+ to go get k8s.io/client-go@latest is the current recommendation.

liggitt on Mar 3, 2021

Related issue is that go get k8s.io/client-go@latest resolves to v11.0.0+incompatible not v0.18.2. Should I break this off as a separate discussion?

Unfortunately, that is not possible to resolve. k8s.io/client-go had major versions tagged prior to the introduction of go modules. go modules require any major version X >= 2 rename the module to k8s.io/client-go/v<X>.

Go considers tags >= 2.x.x which contain a go.mod file with a module name that doesn’t end with /v<X> invalid and won’t include them when resolving @latest, so until the k8s.io/client-go module is renamed with version suffixes, go get must indicate specific versions (e.g. go get k8s.io/client-go@v0.18.2)

liggitt on May 12, 2020

This is still a problem, and being forced to use replace is not a good solution. I would guess that the proxy is selecting the highest semver available to it, which means since the valid major version is now v0, it’s always going to prefer to select v12.

lossanarch on Mar 31, 2020

I found the similar issue building the repo’s master example for vendor/k8s.io/client-go/rest/request.go:598:31: not enough arguments in call to watch.NewStreamWatcher have (*versioned.Decoder) want (watch.Decoder, watch.Reporter)

sbhardwaj-mt on Feb 16, 2020