This fixes golint failures on the following files:
- test/e2e/framework/deployment_util.go
- test/e2e/framework/exec_util.go
Cleanup:
- ScaleDeployment() was not used at all, so let's remove it.
- ExecCommandInPod() and ExecCommandInPodWithFullOutput() were called
in the framework only, so let's make them local.
In addition, this replaces the combination of GetCPUSummary() and
FormatCPUSummary() with LogCPUSummary() in e2e/node/kubelet_perf.go
because that is completely same.
This fixes golint failures on the following files:
- test/e2e/framework/authorizer_util.go
- test/e2e/framework/cleanup.go
- test/e2e/framework/create.go
This fixes golint failures under test/e2e/framework/providers/gce/.
Cleanup:
* FirewallTimeoutDefault is not used at all, so remove it.
* FirewallTestTcpTimeout, FirewallTestHttpPort and FirewallTestUdpPort
are used at test/e2e/network/firewall.go only. So move them.
The Python code used in the example_cluster_dns test is not compatible with Python3.
Keeping in mind that Python2 will no longer be supported from 2020 onwards, it is a good idea to address this issue.
The GlusterDynamicProvisioner test will not work on GKE because master
node is in a different project and cannot talk to the pod running on
node which is used for gluster provisioner. So add the code to skip the
test on GKE
[stackdriver addon] Bump prometheus-to-sd to v0.5.0 to pick up security fixes.
[fluentd-gcp addon] Bump fluentd-gcp-scaler to v0.5.1 to pick up security fixes.
[fluentd-gcp addon] Bump event-exporter to v0.2.4 to pick up security fixes.
[fluentd-gcp addon] Bump prometheus-to-sd to v0.5.0 to pick up security fixes.
[metatada-proxy addon] Bump prometheus-to-sd v0.5.0 to pick up security fixes.
Because the code was moved, golint is now active. Because users of the
code must adapt to the new location of the code, it makes sense to
also change the API at the same time to address the style comments
from golint ("struct field ApiGroup should be APIGroup", same for
ApiExtensionClient).
E2E Test "Secret should fail to create secret in volume
due to empty secret key" tries to create a secret
with empty key and check whether it fails or not.
But the secret creation in this test fails with
double error due to invalid secret name. This will
make this test to pass even if the fuctionality
which needs to be tested is broken.
This commit fix the secret name error(name should not
have capital letters) so that the secret creation fails
only due to desired reason.
Signed-off-by: kanwar saad bin liaqat <kanwar.sbl@gmail.com>
There are two reason why this is useful:
1. less code to vendor into external users of the framework
The following dependencies become obsolete due to this change (from `dep`):
(8/23) Removed unused project github.com/grpc-ecosystem/go-grpc-prometheus
(9/23) Removed unused project github.com/coreos/etcd
(10/23) Removed unused project github.com/globalsign/mgo
(11/23) Removed unused project github.com/go-openapi/strfmt
(12/23) Removed unused project github.com/asaskevich/govalidator
(13/23) Removed unused project github.com/mitchellh/mapstructure
(14/23) Removed unused project github.com/NYTimes/gziphandler
(15/23) Removed unused project gopkg.in/natefinch/lumberjack.v2
(16/23) Removed unused project github.com/go-openapi/errors
(17/23) Removed unused project github.com/go-openapi/analysis
(18/23) Removed unused project github.com/go-openapi/runtime
(19/23) Removed unused project sigs.k8s.io/structured-merge-diff
(20/23) Removed unused project github.com/go-openapi/validate
(21/23) Removed unused project github.com/coreos/go-systemd
(22/23) Removed unused project github.com/go-openapi/loads
(23/23) Removed unused project github.com/munnerz/goautoneg
2. works around https://github.com/kubernetes/kubernetes/issues/75338
which currently breaks vendoring
Some recent changes to crd_util.go must now be pulling in the broken
k8s.io/apiextensions-apiserver packages, because it was still working
in revision 2e90d92db9 (as demonstrated by
586ae281ac).
We try using an atomic with a CAS, as a potential workaround for
issue #74890.
Kudos to @neolit123 for the investigation & idea.
This is a speculative workaround - we are really seeing if this is
better; if not we should revert.
If it is better we should file a bug against go 1.12, and then revert!
Issue #74890
We REJECT every other case. Close this FIXME.
To get this to work in all cases, we have to process service in
filter.INPUT, since LB IPS might be manged as local addresses.
This is a prefactoring for followup changes that need to use very
similar but subtly different test. Now it is more generic, though it
pushes a little logic up the stack. That makes sense to me.
Need to add bracket in the tag for sig-windows. Also fix an issue: for
current testing structure, it first init driver and then set up the
framework. So when initialize the driver, it does not know what OS is
and we can not set up the capabilities correctly. Instead we have to add
all the capabilities and supported fs types including both linux and
windows. Later in the code, we will check the Node OS and decide how to
run the test.
Current e2e tests for the Container Lifecycle Hooks weren't
using brackets for the IPv6 URL addresses per RFC2732, thus those
tests were failing.
This patches add brackets to the target URL if it's an IPv6 address.
Reference: https://github.com/kubernetes/kubernetes/issues/70248
The test [k8s.io] Probing container [It] should not be restarted with a
/healthz http liveness probe [NodeConformance] [Conformance]
fails because it's using a nginx image that's spawns a server that's
only listening on IPv4 by default.
Switching to an image like TestWebserver that's listening in IPv4 and IPv6 by default
allows the test to run on IPv4 and IPv6 environments.
Reference: https://github.com/kubernetes/kubernetes/issues/70248
Windows containers do not include a route to the GCE metadata server by
default. This check is causing the "DNS should provide DNS for the
cluster" test to fail for clusters with Windows nodes
(https://testgrid.k8s.io/sig-windows#gce-windows-master&width=20).
Tested that this works by running "DNS should provide DNS for the
cluster" against an e2e cluster with Windows nodes brought up on GCE.
Current IPv6 e2e test for external connectivity is using a
domain address (google.com) as target.
However, the same IPv4 test uses the well known Google DNS address
8.8.8.8.
We should be coherent in the testing, this patch changes the target to use
the Google IPv6 DNS address 2001:4860:4860::8888.
It looks like node does become unschedulable for the pod
but condition does not get added to the pod in time.
Also ginkgo could retry the test and hence it helps to use
unique node label for scheduling.
When using an already installed driver, the snapshot name is the
original driver name. Renaming was incorrectly copied from the in-tree
CSI hostpath driver.
It is useful to apply the storage testsuite also to "external" (=
out-of-tree) storage drivers. One way of doing that is setting up a
custom E2E test suite, but that's still quite a bit of work.
An easier alternative is to parameterize the Kubernetes e2e.test
binary at runtime so that it instantiates the testsuite for one or
more drivers. Some parameters have to be provided before starting the
test because they define configuration and capabilities of the driver
and its storage backend that cannot be discovered at runtime. This is
done by populating the DriverDefinition with the content of the file
that the new -storage.testdriver parameters points to.
The universal .yaml and .json decoder from Kubernetes is used. It's
flexible, but has some downsides:
- currently ignores unknown fields (see https://github.com/kubernetes/kubernetes/pull/71589)
- poor error messages when fields have the wrong type
Storage drivers have to be installed in the test cluster before
starting e2e.test. Only tests involving dynamically provisioned
volumes are currently supported.
This is the 2nd PR to move CSINodeInfo/CSIDriver APIs to
v1beta1 core storage APIs. It includes controller side changes.
It depends on the PR with API changes:
https://github.com/kubernetes/kubernetes/pull/73883
The network connection might not yet be established by the time the
container starts, causing the dig command to fail.
Retrying the dig command will solve this issue. This approach is similar
to the other DNS Conformance tests.
It has been suggested to replace the "e2eteam/busybox:1.29" image
used in the test "should be able to pull image from docker hub [NodeConformance]"
with a nanoserver image manifest list.
Adds a TODO for it.
Kubelet might miss reporting the new Running state when restarting
a pod after its backoff period expired, and thus, the pod will
continue to remain in CrashLoopBackOff state, causing the
"should cap back-off at MaxContainerBackOff" and
"should have their auto-restart back-off timer reset on image update"
tests to fail, since they're waiting the Pods to enter a Running state.
Waiting for the next Terminated state instead of the next Running state
is more reliable.
Note that this adds 5 seconds to the restart delay due to the fact that
the Container runs for 5 seconds (it's command is "sleep 5"), but it is
within the test's expectations.
When running ginkgo directly against the source code of the test suite
instead of using some pre-compiled e2e.test binary, ginkgo no longer
recognized that it runs a Ginkgo testsuite, which broke "-focus" and
"-p".
By re-inserting the magic strings that ginkgo looks for into a
comment, we can restore the desired behavior without affecting the
code.
Fixes: #74827
ravisantoshgudimetla