Problems building Go application with client-go #749

jpedro1992 · 2020-02-12T14:56:11Z

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?

The text was updated successfully, but these errors were encountered:

sbhardwaj-mt · 2020-02-16T12:50:26Z

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 · 2020-02-27T16:20:50Z

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 · 2020-02-28T13:07:06Z

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 · 2020-03-03T12:54:55Z

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 · 2020-03-14T15:50:17Z

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 · 2020-03-14T15:56:25Z

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 · 2020-03-25T12:07:17Z

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 · 2020-03-31T05:12:43Z

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 · 2020-04-03T02:20:55Z

I have the same problem.

lozenko · 2020-04-29T16:26:14Z

same problem

carnott-snap · 2020-05-12T21:37:57Z

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 · 2020-05-12T21:41:48Z

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)

carnott-snap · 2020-05-12T21:58:09Z

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 · 2020-08-11T17:33:21Z

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 · 2020-08-11T17:37:27Z

/remove-lifecycle stale

fejta-bot · 2020-11-09T17:38:17Z

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 · 2020-11-19T05:34:53Z

/remove-lifecycle stale

albertmenglongli · 2021-02-02T10:41:15Z

same problem

ebilling · 2021-03-03T22:20:50Z

This module has a major issue with its version tags that confuse Golang:

Latest version tag is supposed to be v0.20.4, but there are also tags of v1.. through v12.0.0 (dated Jun 20, 2019)

This breaks basic module versioning as of GO 1.11. If you don't select a version for v2 or greater that it will only pull the highest major of 0 or 1. Which as of today is v1.5.2 which contains a go.mod that retracts all previous module versions including v1.5.2. I have no idea if that works or not, but since I'm still having trouble just using the module without an explicit replace directive in my go.mod, I suspect it's not.

I created a similar issue in one of my repos and the only way to deal with it was to delete the version tags for the higher versions. Otherwise, everyone has to manually run the replace, and they won't pick up changes on an update. That's a major pain and makes it difficult to stay current for security fixes.

I appreciate that some people may have hard coded those old version tags, but IMHO, they need to be removed. They have been causing problems for over a year.

liggitt · 2021-03-03T22:27:17Z

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 · 2021-03-04T15:11:29Z

The reporter of this issue in particular is encountering problems because it is trying to depend on k8s.io/kubernetes as a library, which is not recommended or supported.

For more general go get issues, https://github.com/kubernetes/client-go/blob/master/INSTALL.md has been updated to give more specific guidance for using a particular version, and for resolving the most common issues encountered.

lboix · 2021-03-25T19:57:18Z

Here is a workaround that could help, especially if you are using Kubernetes 1.14 : #741 (comment)

bcmills mentioned this issue May 19, 2020

proxy.golang.org returning 410 for k8s.io/client-go@v12.0.0+incompatible golang/go#33558

Closed

bcmills mentioned this issue Jun 8, 2020

cmd/go: can not modify the go mod library version golang/go#39425

Closed

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 11, 2020

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 11, 2020

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 9, 2020

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 19, 2020

liggitt closed this as completed Mar 4, 2021

mflendrich mentioned this issue Mar 19, 2021

chore(mod): bump to go 1.16, upgrade k8s and knative Kong/kubernetes-ingress-controller#1110

Merged

lion7 mentioned this issue May 8, 2023

Update k8s client-go kubevirt/kubevirt#9715

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problems building Go application with client-go #749

Problems building Go application with client-go #749

jpedro1992 commented Feb 12, 2020 •

edited

Loading

sbhardwaj-mt commented Feb 16, 2020

StiviiK commented Feb 27, 2020 •

edited

Loading

StiviiK commented Feb 28, 2020

mstrYoda commented Mar 3, 2020

EwanValentine commented Mar 14, 2020

EwanValentine commented Mar 14, 2020

lwabish commented Mar 25, 2020

lossanarch commented Mar 31, 2020

gosoon commented Apr 3, 2020

lozenko commented Apr 29, 2020

carnott-snap commented May 12, 2020

liggitt commented May 12, 2020 •

edited

Loading

carnott-snap commented May 12, 2020 •

edited

Loading

fejta-bot commented Aug 11, 2020

carnott-snap commented Aug 11, 2020

fejta-bot commented Nov 9, 2020

carnott-snap commented Nov 19, 2020

albertmenglongli commented Feb 2, 2021

ebilling commented Mar 3, 2021

liggitt commented Mar 3, 2021

liggitt commented Mar 4, 2021

lboix commented Mar 25, 2021

Problems building Go application with client-go #749

Problems building Go application with client-go #749

Comments

jpedro1992 commented Feb 12, 2020 • edited Loading

Problem Description

Dependencies

Compilation Error

sbhardwaj-mt commented Feb 16, 2020

StiviiK commented Feb 27, 2020 • edited Loading

StiviiK commented Feb 28, 2020

mstrYoda commented Mar 3, 2020

EwanValentine commented Mar 14, 2020

EwanValentine commented Mar 14, 2020

lwabish commented Mar 25, 2020

lossanarch commented Mar 31, 2020

gosoon commented Apr 3, 2020

lozenko commented Apr 29, 2020

carnott-snap commented May 12, 2020

liggitt commented May 12, 2020 • edited Loading

carnott-snap commented May 12, 2020 • edited Loading

fejta-bot commented Aug 11, 2020

carnott-snap commented Aug 11, 2020

fejta-bot commented Nov 9, 2020

carnott-snap commented Nov 19, 2020

albertmenglongli commented Feb 2, 2021

ebilling commented Mar 3, 2021

liggitt commented Mar 3, 2021

liggitt commented Mar 4, 2021

lboix commented Mar 25, 2021

jpedro1992 commented Feb 12, 2020 •

edited

Loading

StiviiK commented Feb 27, 2020 •

edited

Loading

liggitt commented May 12, 2020 •

edited

Loading

carnott-snap commented May 12, 2020 •

edited

Loading