kubernetes: kubernetes unit tests fail with Panic messages stating "invalid type"

logs_ci-unit-kubernetes_50_build-log.txt

What happened: Below are the 27 unit tests that panic and FAIL while I run “make test”

Also the analysis says that the failure started occurring after the below PR merge: #https://github.com/kubernetes/kubernetes/pull/90582/commits/283d9f7483d9a5b30746921a68e7a5e586c2c80e This commit updates github.com/golang/protobuf from v1.3.3 to v1.4.2. The invalid Type failures that occur are from the newer implementation of protobuf that is added at “kubernetes/vendor/google.golang.org/protobuf” which did not exist prior to this commit.

Failure Message: panic: field etcdserverpb.Request.ID has invalid type: got uint64, want pointer

  1. pkg/master TestStorageVersionHashes
  2. pkg/registry/apps/daemonset/storage TestDelete
  3. pkg/registry/apps/replicaset/storage TestList
  4. pkg/registry/core/configmap/storage TestCreate
  5. pkg/registry/core/event/storage TestDelete
  6. pkg/registry/core/persistentvolume/storage TestCreate
  7. pkg/registry/core/persistentvolumeclaim/storage TestGet
  8. pkg/registry/core/pod/storage TestEviction
  9. pkg/registry/core/service/storage
  10. pkg/registry/scheduling/priorityclass/storage TestUpdate
  11. pkg/registry/storage/csinode/storage TestCreate
  12. pkg/registry/storage/volumeattachment/storage TestWatch
  13. vendor/k8s.io/apiserver/pkg/registry/generic/registry TestDryRunCreateDoesntCreate
  14. vendor/k8s.io/apiserver/pkg/storage/etcd3 TestCreateWithTTL
  15. vendor/k8s.io/apiserver/pkg/storage/tests TestWatchBookmarksWithCorrectResourceVersion Failure message: panic: invalid Go type int for field k8s_io.kubernetes.vendor.go_etcd_io.etcd.etcdserver.etcdserverpb.loggablePutRequest.value_size
  16. pkg/registry/apps/deployment/storage TestUpdate
  17. pkg/registry/apps/statefulset/storage TestStatusUpdate
  18. pkg/registry/batch/cronjob/storage TestCreate
  19. pkg/registry/core/namespace/storage TestCreate
  20. pkg/registry/core/node/storage TestList (
  21. pkg/registry/core/replicationcontroller/storage TestWatch
  22. pkg/registry/core/secret/storage TestCreate
  23. pkg/registry/networking/networkpolicy/storage TestCreate
  24. pkg/registry/settings/podpreset/storage TestUpdate
  25. pkg/registry/storage/csidriver/storage TestList
  26. pkg/registry/storage/storageclass/storage TestUpdate
  27. vendor/k8s.io/apiextensions-apiserver/pkg/registry/customresource

What you expected to happen: The unit tests must pass without error message.

How to reproduce it (as minimally and precisely as possible):

  1. Setup Go lang 1.13.5
  2. Clone kubernetes source code : git clone git@github.com:kubernetes/kubernetes.git
  3. Ensure you are on master branch : git checkout master
  4. cd kubernetes/hack/tools
  5. GO111MODULE=on go install gotest.tools/gotestsum
  6. make generated_files
  7. make test WHAT=<Path of any one test from above failures> eg: make test WHAT=k8s.io/kubernetes/pkg/registry/apps/deployment/storage/

Anything else we need to know?: This failure consistently occurs when unit test is run through an automated Jenkins pipeline. But the failure is seen intermittently when run “make test” manually. Sometimes, easily reproducible when we do “make clean”, “make clean_generated” followed by “make test” Please see the consistent failure at https://k8s-testgrid.appspot.com/sig-node-ppc64le#unit-tests

Environment: Architechture: linux/ppc64le

  • Kubernetes version (use kubectl version):
  • Cloud provider or hardware configuration:
  • OS (e.g: cat /etc/os-release): Ubuntu 18.04.4
  • Kernel (e.g. uname -a):
  • Install tools:
  • Network plugin and version (if this is a network-related bug):
  • Others: @mkumatag

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (17 by maintainers)

Most upvoted comments

the fix is in the release-3.4 branch. However, 3.4.10 has not been released yet.

go.mod PR has been created as well.

@Rajalakshmi-Girish Did you ever find a solution to the second bug above? I’m seeing the same after applying the original fix from etcd-io/etcd#12000.

No I haven’t. @liggitt Is there a solution?