The `-mod=mod` option is only supported from go1.14. Since `release-1.18`
and `release-1.17` branches use go1.13.15, this commit adds smoke tests
per branch to only add the `-mod=mod` option to branches after
`release-1.18`.
The duplicate smoke test config can be removed once v1.21 is released
and v1.18 is out of support.
The pause image should not run sleep commands. This will cause pod fail
to start correctly.
See details in issue #100047. We discovered some behavior about
development in certain cases like new pod fail to start correctly, but will be further investigated.
Change-Id: I9761bbefa694f6fe51a6f1e7561fa7e566ce4d8f
We can support topology detection for all drivers with a single
topology key by allowing different nodes to have the same topology
value. This makes the test a bit more generic and its configuration
simpler.
Drivers need to opt into the new test. Depending on how the driver
describes its behavior, the check can be more specific. Currently it
distinguishes between getting any kind of information about the
storage class (i.e. assuming that capacity is not exhausted) and
getting one object per node (for local storage). Discovering nodes
only works for CSI drivers.
The immediate usage of this new test is for csi-driver-host-path with
the deployment for distributed provisioning and storage capacity
tracking. Periodic kubernetes-csi Prow and pre-merge jobs can run this
test.
The alternative would have been to write a test that manages the
deployment of the csi-driver-host-path driver itself, i.e. use the E2E
manifests. But that would have implied duplicating the
deployments (in-tree and in csi-driver-host-path) and then changing
kubernetes-csi Prow jobs to somehow run for in-tree driver definition
with newer components, something that currently isn't done. The test
then also wouldn't be applicable to out-of-tree driver deployments.
Yet another alternative would be to create a separate E2E test suite
either in csi-driver-host-path or external-provisioner. The advantage
of such an approach is that the test can be written exactly for the
expected behavior of a deployment and thus be more precise than the
generic version of the test in k/k. But this again wouldn't be
reusable for other drivers and also a lot of work to set up as no such
E2E test suite currently exists.
It is the caller's responsibility to remove sensitive information prior to creation.
This allows for potential extensions in the future.
For example, it preserves HTTP wrappers for custom behavior per request.
There might be cases in which callers want to preserve HTTP wrappers for custom behavior per request.
For example, there might be distributions that would like to add custom HTTP Headers for each HTTP request.
This PR allows for that.
It uses the Wrap method that adds a transport middleware function that will give the caller an opportunity to wrap the underlying http.RoundTripper prior to the first API call being made.
We cannot use WrapTransport because it simply overwrites RoundTrippers for the current config instead of appending to already existing ones.
