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.
Fix some warnings from go-staticcheck.
"should use buffer.String() instead of string(buffer.Bytes()) (S1030)"
This warning is explained at this link.
https://staticcheck.io/docs/checks#S1030
* 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.
