Client-go: too many arguments in call to r.DecodeBytes

[CSharpRU]

Hello there,

I'm having a strange issue with the client code, check info below.

Client version: v4.0.0
Go/Dep version:

dep:
 version     : devel
 build date  : 
 git hash    : 
 go version  : go1.9
 go compiler : gc
 platform    : darwin/amd64

Log:

...
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:665:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:2423:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:4252:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:5282:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:5975:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:6886:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:8081:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:9242:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:9564:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:9941:26: too many arguments in call to r.DecodeBytes
        have ([]byte, bool, bool)
        want ([]byte, bool)
vendor/k8s.io/client-go/pkg/api/v1/types.generated.go:9941:26: too many errors
...

Example of code:

package main

import (
    "fmt"

    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/rest"
    "k8s.io/client-go/tools/clientcmd"
)

func main() {
    config, err := rest.InClusterConfig()
    if err != nil {
        panic(err.Error())
    }

    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        panic(err.Error())
    }

    pods, err := clientset.CoreV1().Pods("").List(metav1.ListOptions{})
    if err != nil {
        panic(err.Error())
    }

    if len(pods.Items) > 0 {
        fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
        for _, pod := range pods.Items {
            fmt.Printf("pod %s\n", pod.GetName())
        }
    } else {
        fmt.Println("No pods found!")
    }
}

What I did wrong? Error definitely depends on github.com/ugorji/go/codec. Do I need to install specific hash or something like that?

[TimJones]

I'm having the same issue. Should we use Godep specifically to manage dependencies? My project uses dep since that isshould be the 'official' tool.

[ash2k]

The cause of the issue is the wrong version of github.com/ugorji/go dep is picking up - the latest commit in the repo changes the signature of this method and hence generated code must be regenerated. Try using the same version as client-go - works for me with dep.

[beeradb]

I had the same issue as reported in #293. I also opened https://github.com/golang/dep/issues/1207 in the dep repository to track the issue, as it seems like it's a dep problem.

As I reported in those issues, I was able to get dependencies working properly by using glide (for now).

[TimJones]

For those who can't\don't want to change dependency tools, we added the following to our Gopkg.toml

[[override]]
  name = "github.com/ugorji/go"
  revision = "8c0409fcbb70099c748d71f714529204975f6c3f"

[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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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]

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
/remove-lifecycle stale

[fejta-bot]

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