- add Policy API to pkg/scheduler/apis/config and staging/src/k8s.io/kube-scheduler/config/v1
- dual-register Policy as apiGroup "v1" and "kubescheduler.config.k8s.io
- move/merge pkg/scheduler/api to pkg/scheduler/apis/config/...
- alias schedulerapi to pkg/scheduler/apis/config
- alias legacyapi to pkg/scheduler/api
- eliminate latest.Codec; use scheme.Codecs instead
- unit tests to verify Policy YAML with version "v1" or "kubescheduler.config.k8s.io/v1" can be loaded properly
- update api/api-rules/violation_exceptions.list
This uses etcd test data to load resources and then ensures that
kubectl get output contains a different set of columns than default.
This assumes that all future API resources will either have appropriate
kubectl get output or add an exception here.
Co-authored-by: Luis Sanchez <sanchezl@redhat.com>
- SimpleGET: Moved to ingress sub package of e2e framework
- PollURL: Moved to ingress sub package of e2e framework
- ProxyMode: Moved to service e2e test package
- ListNamespaceEvents: Moved to e2e_node test package
- NewE2ETestNodePreparer: Removed since 59533f0cd1
In case node object update fails due to revision conflict, it does not make sense to return success.
It needs to be retried so the v1.PreferAvoidPodsAnnotationKey annotation can be properly set in the next round.
This is needed for raw block volumes. It mirrors a change made in the upstream
deployment in https://github.com/kubernetes-csi/csi-driver-host-path/pull/109
Raw block volumes use loop devices under the hood. "losetup --find
--show" uses LOOP_CTL_GET_FREE to get a free loop device. It then
expects to have the corresponding /dev/loopX already available. When
/dev inside the container is a static tmpfs which doesn't already have
those /dev/loop* devices (*) the new device fails to show up,
resulting in:
I1028 13:25:19.937846 1 server.go:117] GRPC call: /csi.v1.Controller/CreateVolume
I1028 13:25:19.938083 1 server.go:118] GRPC request: {"accessibility_requirements":{"preferred":[{"segments":{"topology.hostpath.csi/node":"pmem-csi-pmem-govm-worker3"}}],"requisite":[{"segments":{"topology.hostpath.csi/node":"pmem-csi-pmem-govm-worker3"}}]},"capacity_range":{"required_bytes":5368709120},"name":"pvc-24985a49-5638-4bf6-b789-bb99a28d1073","volume_capabilities":[{"AccessType":{"Block":{}},"access_mode":{"mode":1}}]}
I1028 13:25:19.961124 1 volume_path_handler_linux.go:41] Creating device for path: /csi-data-dir/635c6569-f986-11e9-baa6-0242ac110004
I1028 13:25:20.391472 1 volume_path_handler_linux.go:75] Failed device create command for path: /csi-data-dir/635c6569-f986-11e9-baa6-0242ac110004 exit status 1 losetup: /csi-data-dir/635c6569-f986-11e9-baa6-0242ac110004: failed to set up loop device: No such file or directory
E1028 13:25:20.392916 1 server.go:121] GRPC error: rpc error: code = Internal desc = failed to create volume 635c6569-f986-11e9-baa6-0242ac110004: failed to attach device /csi-data-dir/635c6569-f986-11e9-baa6-0242ac110004: exit status 1
(*) It seems that the static tmpfs gets populated by Docker based on
what's currently on the host when the container starts. That would
explain why it worked in the Kubernetes Prow testing - the host must
have had enough loop devices already defined.
