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
Current regex used in the Downward e2e API tests is matching only
IPv4 addresses, consequently those tests fails with IPv6 clusters.
This patch modifies the regex to match ipv4 and ipv6 addresses.
Ref: 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.
