After a couple years of seeing changes spawned from this issue, I don't think this is a good use of contributors' or reviewers' time. golint is very opinionated about:
exported type and function names, leading to PRs attempting to change exported things people use downstream
missing documentation on interface implementation functions, which leads to not-very-useful copy/paste of interface godoc
the govet and staticcheck verify jobs are much more useful since they catch correctness issues
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
- as soon as a request is received by the apiserver, determine the
timeout of the request and set a new request context with the deadline.
- the timeout filter that times out non-long-running requests should
use the request context as opposed to a fixed 60s wait today.
- admission and storage layer uses the same request context with the
deadline specified.
we use the default timeout enforced by the apiserver:
- if the user has specified a timeout of 0s, this implies no timeout on the user's part.
- if the user has specified a timeout that exceeds the maximum deadline allowed by the apiserver.
The new releases of klog (via klogr) and logr expose support for call
traces via a new WithCallDepth API in logr.
The new klogr can be configured to pass structured log entries into
klog instead of turning them into a single text message.
Currently target CC can only be set if the host platform
is linux/amd64 . If target is already set in the environment
it is always safe to use it and enable cgo.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
The newer spec will be needed for some test code that uses the new
GetVolume API.
The commit was produced with:
hack/pin-dependency.sh github.com/container-storage-interface/spec v1.3.0
hack/update-vendor.sh
Both images are now sane multi-architecture images and should fix the
kube-proxy container image in the same way.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
The test "validates that there is no conflict between pods with same
hostPort but different hostIP and protocol" was testing the scheduler
capability to schedule pods on the same node with hostPorts, however,
it wasn´t validating that the HostPorts was working, causing false
positives, because the pods were scheduled, but the HostPort exposed
wasn´t working.
In order to test the HostPort functionality, we have to use HostNetwork
pods, that are incompatible with Windows platforms. Also, since this
is touching both network and scheduling, there is no clear the ownership,
but sig-network is happy to adopt it.
We also add a new test for scheduling only under "scheduling", so Windows
folks can use it to test the scheduled in that platform.
