Tests might want to use there own options for specifying a file path,
while still using the abstract file access API. For example,
framework.CreateFromManifests might be used to create a mixture of
files under the repo root and from elsewhere. To support this,
absolute paths can now be given to the testfiles package and they will
be read directly.
While debugging issues I found myself having to change the constant in the code
for a cluster > 20 nodes, and then on a very small cluster I found myself passing
0 to avoid the mostly useless output (it's useful in specific scenarios but generates
a *lot* of output that doesn't help debugging the rest of the time).
Some mounttest related tests are checking the file permissions set on the
container files, but the default file permissions on Windows is 775 instead of
644, causing some tests to fail.
Keep in mind that file permissions work differently on Windows, and setting file
permissions via Kubernetes is not currently supported on Windows.
Attempting to retrieve logs for a container that hasn't started yet
may have been the reason for the "the server does not allow this
method on the requested resource" error that showed up on the GCE CI
test cluster (issue #70888).
If we wait with retrieving logs until the pod is running or has
terminated, then we might be able to avoid that error. It's the right
thing to do either way and not complicated to implement.
There were providers which would:
- allow overrides of the file base name but not the path
- allow oeverrides of the file path
- not allow any overrides at all
This change makes it such that each of the supported providers
can override the SSH key location using an env var. The env
var itself may vary based on the provider though.
If given an absolute path to the key, it is used. If given
a relative path it will be made relative to ~/.ssh
Fixes: #68747
Ginkgo expects the caller to pass the appropriate skip, which we do
not do. Slightly improve call site messages by eliding the util.go
stack frame. Also drop the timestamp from skip messages since skip
is almost always called to check for global conditions, not temporal
ones.
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
The existence of /proc/net/nf_conntrack depends on the Linux kernel
config CONFIG_NF_CONNTRACK_PROCFS, and Ubuntu 16.04's one is disabled.
So the e2e test "should set TCP CLOSE_WAIT timeout" fails on that.
This adds the existence check of /proc/net/nf_conntrack for skipping
the test if not existing.
In addition, this makes IssueSSHCommandWithResult return Stderr in
the error message if err is nil to check "No such file or directory"
as nonexistence of /proc/net/nf_conntrack.
Creating secrets is useful for CSI drivers like ceph-csi which have to
be configured via secrets.
While at it, the UniqueName method gets replaced with
MetaNamespaceKeyFunc which does the same thing (at least as long as
non-namespaced items don't have a redundant namespace set) and the
factory types aren't exported anymore (not necessary).
This way we can be sure that the kubelet can't communicate with the
master, even if falls-back to the internal/external IP (which seems to
be the case with DNS)
Issue #56787
The command executed in ValidateController function uses the
image name of the running container. This is a problem in multiarch
images, since the image name is the name of the image specific to
the architecture, but the image passed as parameter is the multiarch
one (as the test are architecture agnostic), making the test to fail.
This patch fixes it by making the logic use a command that get the
multiarch name given in the container spec.
Signed-off-by: Miguel Herranz <miguel@midokura.com>
