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.
Note that the fake client isn't designed to work with informer. It
doesn't support resource version. It's encouraged to use a real client
in an integration/E2E test if you need to test complex behavior with
informer/controllers.
Removing myself from OWNERS as I haven't had the bandwidth to go over
these reviews for a long time.
This should have been part of #99718, which has already been merged.
* Before this change, even on non-AWS platforms, the Enabled() check attempts
to make calls to the metadata endpoint when the session and credentials
are initialized (in order to determine if the provider should be
initialized at all).
* This can cause latency because the SDK times out and retries -- up to
20 seconds of latency has been observed on non-AWS platforms when the
metadata IP was blocked with an iptables rule.
* Instead, check once if we are running on an EC2 platform, first trying
to find the EC2 UUID in system files, and second attempting to get
credentials.
* Add a benchmark test that includes intialization and the credential
check.
We should not attempt creation of mandatory objects if ensuring
the suggested configuration resulted in an error.
We rely on the presence of the "exempt" priority level configuration
object in the cluster to indicate whether we should ensure
suggested configuration.
