Client-go: Issue at compilation time when required with dep

Created on 23 May 2018 · 28Comments · Source: kubernetes/client-go

Hi,

It seems that there is a compilation error when the client-go is required from dep.

The dep ensure command goes well. But then... go build output this error :

# github.com/seblegall/test-k8s-go-client/vendor/k8s.io/client-go/discovery
vendor/k8s.io/client-go/discovery/restmapper.go:42:75: undefined: meta.VersionInterfacesFunc
vendor/k8s.io/client-go/discovery/restmapper.go:176:19: undefined: meta.VersionInterfacesFunc

Steps to reproduce this error :

Copy past the source code from : https://github.com/kubernetes/client-go/blob/master/examples/out-of-cluster-client-configuration/main.go in new project.
Run dep init
Run go build

I originally had this trouble when trying to do a dep update on project that use this dependency : https://github.com/Meetic/blackbeard

I'm using : go version go1.9.2 darwin/amd64

dep version output (I'm using dep build from source and I'm up to date with master) :

dep:
 version     : devel
 build date  :
 git hash    :
 go version  : go1.9.2
 go compiler : gc
 platform    : darwin/amd64
 features    : ImportDuringSolve=false

lifecyclrotten

Source

seblegall

Most helpful comment

You have to put this explicitly in your Gopkg.toml file :

[[constraint]]
  name = "k8s.io/api"
  version = "kubernetes-1.9.0"

[[constraint]]
  name = "k8s.io/apimachinery"
  version = "kubernetes-1.9.0"

[[constraint]]
  name = "k8s.io/client-go"
  version = "6.0.0"

In this example I have set the version to kubernetes-1.9.0 because I'm using the client-go version 6.0.0. But you should put the right version of k8s.io/* packages depending on the client-go you are using.

seblegall on 5 Jun 2018

👍4

All 28 comments

what branches are you using?

liggitt on 23 May 2018

My Gopkg.toml file contains :

[[constraint]]
  name = "k8s.io/client-go"
  version = "7.0.0"

The Gopkg.lock file contains :

[[projects]]
  name = "k8s.io/client-go"
  packages = [
    "discovery",
    "kubernetes",
    "kubernetes/scheme",
    "kubernetes/typed/admissionregistration/v1alpha1",
    "kubernetes/typed/admissionregistration/v1beta1",
    "kubernetes/typed/apps/v1",
    "kubernetes/typed/apps/v1beta1",
    "kubernetes/typed/apps/v1beta2",
    "kubernetes/typed/authentication/v1",
    "kubernetes/typed/authentication/v1beta1",
    "kubernetes/typed/authorization/v1",
    "kubernetes/typed/authorization/v1beta1",
    "kubernetes/typed/autoscaling/v1",
    "kubernetes/typed/autoscaling/v2beta1",
    "kubernetes/typed/batch/v1",
    "kubernetes/typed/batch/v1beta1",
    "kubernetes/typed/batch/v2alpha1",
    "kubernetes/typed/certificates/v1beta1",
    "kubernetes/typed/core/v1",
    "kubernetes/typed/events/v1beta1",
    "kubernetes/typed/extensions/v1beta1",
    "kubernetes/typed/networking/v1",
    "kubernetes/typed/policy/v1beta1",
    "kubernetes/typed/rbac/v1",
    "kubernetes/typed/rbac/v1alpha1",
    "kubernetes/typed/rbac/v1beta1",
    "kubernetes/typed/scheduling/v1alpha1",
    "kubernetes/typed/settings/v1alpha1",
    "kubernetes/typed/storage/v1",
    "kubernetes/typed/storage/v1alpha1",
    "kubernetes/typed/storage/v1beta1",
    "pkg/apis/clientauthentication",
    "pkg/apis/clientauthentication/v1alpha1",
    "pkg/version",
    "plugin/pkg/client/auth/exec",
    "rest",
    "rest/watch",
    "tools/auth",
    "tools/clientcmd",
    "tools/clientcmd/api",
    "tools/clientcmd/api/latest",
    "tools/clientcmd/api/v1",
    "tools/metrics",
    "tools/reference",
    "transport",
    "util/cert",
    "util/flowcontrol",
    "util/homedir",
    "util/integer"
  ]
  revision = "23781f4d6632d88e869066eaebb743857aa1ef9b"
  version = "v7.0.0"

So, I'm using the v7.0.0 tag.

seblegall on 23 May 2018

client-go v7.0.0 depends on k8s.io/apimachinery 31dade610c053669d8054bfd847da657251e8c1a:

https://github.com/kubernetes/client-go/blob/v7.0.0/Godeps/Godeps.json#L373-L376

the referenced type exists at that revision https://github.com/kubernetes/apimachinery/blob/31dade610c053669d8054bfd847da657251e8c1a/pkg/api/meta/restmapper.go#L90-L92

liggitt on 23 May 2018

With dep you have to pin all dependencies (especially those under the k8s.io org) to the right versions. For client-go 7.0.0 use the kubernetes-1.10.0 tags on the other k8s.io repos.

sttts on 23 May 2018

@sttts It works when specifying the version instead of branch in the Gopkg.toml.

However... isn't wired that the default use case with dep doesn't work?

I'm not an expert of dep but... couldn't we find a solution to make client-go explicitly require version
kubernetes-1.10.0 of apimachinery ?

seblegall on 23 May 2018

@seblegall compare https://github.com/kubernetes/publishing-bot/pull/55. Looks like dep's SAT algorithm falls over. Actually though, nobody has found out whether we have a mistake in our (experimentally) shipped Gopkg.tomls or whether dep just explodes.

sttts on 29 May 2018

@sttts Well, did you also try to migrate to vgo? 🤣

seblegall on 29 May 2018

😄1

Well, did you also try to migrate to vgo?

I think nobody dared to try that yet for the whole kube. Maybe just for client-go and friends it's feasible.

sttts on 29 May 2018

I may take some time in the next few days to test vgo on my own project (that require the go-client), then, I may test vgo also on the go-client. Keep you updated.

seblegall on 30 May 2018

also running into this issue with dep

ilackarms on 31 May 2018

👍3

aalubin on 3 Jun 2018

Also having this issue.. Can anyone suggest a fix? Im blocked right now

cheynewallace on 5 Jun 2018

You have to put this explicitly in your Gopkg.toml file :

[[constraint]]
  name = "k8s.io/api"
  version = "kubernetes-1.9.0"

[[constraint]]
  name = "k8s.io/apimachinery"
  version = "kubernetes-1.9.0"

[[constraint]]
  name = "k8s.io/client-go"
  version = "6.0.0"

seblegall on 5 Jun 2018

👍4

@cheynewallace setting the client-go to reference master solves the problem as well:

[[constraint]]
  name = "k8s.io/client-go"
  branch = "master"

aalubin on 5 Jun 2018

setting the client-go to reference master solves the problem as well:

not a good idea. We have no guarantees whatsoever about compatibility with former or future Kube versions.

sttts on 5 Jun 2018

@sttts, you are absolutely right. I should have added a warning for this workaround.

aalubin on 5 Jun 2018

Thanks @seblegall , that one solved it for me..

cheynewallace on 6 Jun 2018

I think nobody dared to try that yet for the whole kube. Maybe just for client-go and friends it's feasible.

actually I did try, and indeed I ended up in a situation where all staging repositories were behaving, but no solution could be found for the main repo.
As far as I can tell, the combination of excessive v0.0.0-* fake versions (really v2+) and dependency cycles in the implicit vgo modules was deadly

sigma on 8 Jun 2018

@sigma am curious, can you upload your experiments to a branch?

sttts on 11 Jun 2018

vgo and kubernetes: https://github.com/kubernetes/kubernetes/pull/65683 :sparkles:

nikhita on 5 Jul 2018

👍1

About dep, I found that it works well to use the same tag for client-go, api and apimachinery. Could this be the recommended way when pinning dependencies?

ref: https://github.com/kubernetes/api/issues/5#issuecomment-338368674

idealhack on 10 Jul 2018

👍1

Could this be the recommended way when pinning dependencies?

Yes, that's recommended.

sttts on 10 Jul 2018

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

fejta-bot on 8 Oct 2018

@seblegall wrote:

you should put the right version of k8s.io/* packages depending on the client-go you are using

How does one go about finding the "right version of k8s.io/*", given a certain client-go version, e.g. v9.0.0?

808codist on 31 Oct 2018

@808codist Give this tool a try https://github.com/ash2k/kubegodep2dep

ash2k on 31 Oct 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

fejta-bot on 30 Nov 2018

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

fejta-bot on 31 Dec 2018

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.