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

[jpedro1992]

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/[email protected] requires
  k8s.io/[email protected]: 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?

[sbhardwaj-mt]

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)

[StiviiK]

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)

I also receive the same error.

[StiviiK]

Fixed @sbhardwaj-mt's and mine error by using the following go.mod:

go 1.14

require (
    k8s.io/api v0.0.0-20200214081623-ecbd4af0fc33
    k8s.io/apimachinery v0.0.0-20200214081019-7490b3ed6e92
    k8s.io/client-go v0.0.0-20200214082307-e38a84523341
    k8s.io/code-generator v0.0.0-20200214080538-dc8f3adce97c
    k8s.io/klog v1.0.0
)

replace (
    golang.org/x/sys => golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a // pinned to release-branch.go1.13
    golang.org/x/tools => golang.org/x/tools v0.0.0-20190821162956-65e3620a7ae7 // pinned to release-branch.go1.13
    k8s.io/api => k8s.io/api v0.0.0-20200214081623-ecbd4af0fc33
    k8s.io/apimachinery => k8s.io/apimachinery v0.0.0-20200214081019-7490b3ed6e92
    k8s.io/client-go => k8s.io/client-go v0.0.0-20200214082307-e38a84523341
    k8s.io/code-generator => k8s.io/code-generator v0.0.0-20200214080538-dc8f3adce97c
)

[mstrYoda]

It might not resolve your issue but can you try to replace k8s.io/client-go v11.0.0+incompatible with k8s.io/client-go v0.17.0 in your go.mod file?

[EwanValentine]

I'm having similar issues with dependencies unfortunately:

build github.com/EwanValentine/hypermap/api: cannot load github.com/googleapis/gnostic/OpenAPIv2: module github.com/googleapis/gnostic@latest found (v0.4.1), but does not contain package github.com/googleapis/gnostic/OpenAPIv2

Here's my go.mod file:

module github.com/EwanValentine/hypermap/api

go 1.13

replace (
    golang.org/x/sys => golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a // pinned to release-branch.go1.13
    golang.org/x/tools => golang.org/x/tools v0.0.0-20190821162956-65e3620a7ae7 // pinned to release-branch.go1.13
    k8s.io/api => k8s.io/api v0.0.0-20200214081623-ecbd4af0fc33
    k8s.io/apimachinery => k8s.io/apimachinery v0.0.0-20200214081019-7490b3ed6e92
    k8s.io/client-go => k8s.io/client-go v0.17.0
    k8s.io/code-generator => k8s.io/code-generator v0.0.0-20200214080538-dc8f3adce97c
)

require (
    github.com/99designs/gqlgen v0.11.3
    github.com/googleapis/gnostic v0.4.1 // indirect
    github.com/imdario/mergo v0.3.8 // indirect
    github.com/json-iterator/go v1.1.9 // indirect
    github.com/rs/cors v1.7.0
    github.com/stripe/stripe-go v70.5.0+incompatible
    github.com/vektah/gqlparser/v2 v2.0.1
    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.0
    k8s.io/apimachinery v0.17.0
    k8s.io/client-go v0.17.0
)

[EwanValentine]

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

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

[lwabish]

It might not resolve your issue but can you try to replace k8s.io/client-go v11.0.0+incompatible with k8s.io/client-go v0.17.0 in your go.mod file?

yes, works for me.
I wonder why go mod uses v11.0.0 version at first when initiating?

[lossanarch]

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.

[gosoon]

I have the same problem.

[lozenko]

same problem

[carnott-snap]

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?

[liggitt]

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/[email protected])

[carnott-snap]

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.
  
  

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[carnott-snap]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[carnott-snap]

/remove-lifecycle stale