The recently introduced failure handling in ExpectNoError depends on error
wrapping: if an error prefix gets added with `fmt.Errorf("foo: %v", err)`, then
ExpectNoError cannot detect that the root cause is an assertion failure and
then will add another useless "unexpected error" prefix and will not dump the
additional failure information (currently the backtrace inside the E2E
framework).
Instead of manually deciding on a case-by-case basis where %w is needed, all
error wrapping was updated automatically with
sed -i "s/fmt.Errorf\(.*\): '*\(%s\|%v\)'*\",\(.* err)\)/fmt.Errorf\1: %w\",\3/" $(git grep -l 'fmt.Errorf' test/e2e*)
This may be unnecessary in some cases, but it's not wrong.
The recently introduced failure handling in ExpectNoError depends on error
wrapping: if an error prefix gets added with `fmt.Errorf("foo: %v", err)`, then
ExpectNoError cannot detect that the root cause is an assertion failure and
then will add another useless "unexpected error" prefix and will not dump the
additional failure information (currently the backtrace inside the E2E
framework).
Instead of manually deciding on a case-by-case basis where %w is needed, all
error wrapping was updated automatically with
sed -i "s/fmt.Errorf\(.*\): '*\(%s\|%v\)'*\",\(.* err)\)/fmt.Errorf\1: %w\",\3/" $(git grep -l 'fmt.Errorf' test/e2e*)
This may be unnecessary in some cases, but it's not wrong.
All code must use the context from Ginkgo when doing API calls or polling for a
change, otherwise the code would not return immediately when the test gets
aborted.
Instead of allowing the cloud provider to guess at the zones that
should be applied for a cluster under test, allow the explicit list
of zones to consider to be passed as a new test context flag -gce-zones.
Only the GCE test cloud provider recognizes this value because only
the GCE test cloud provider makes assumptions about zones for verifying
values, and the default assumptions for GKE do not always match non-GKE
providers.
Remove the "OrDie" from the name (since it doesn't "or die") and add
an extra check that there is at least 1 node available, since many
callers already did that themselves, and many others should have.
This makes sub packages of e2e test framework to use log functions
of core framework instead for avoiding circular dependencies.
NOTE: subpackage pod would make circular dependency if changing here.
So we need to take care of it with another PR.
**What type of PR is this?**
/kind cleanup
**What this PR does / why we need it**:
Staging the GCE Cloud Provider as part of KEP [20190125-removing-in-tree-providers](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/20190125-removing-in-tree-providers.md). Staging repo setup here https://github.com/kubernetes/legacy-cloud-providers
Moves the GCE cloud provider implementation to staging.
This is in preparation for moving the cloud provider code out of tree entirely.
However we need it in staging while the code needs to be consumed both in/out of tree.
**Which issue(s) this PR fixes**:
Fixes #
**Special notes for your reviewer**:
**Does this PR introduce a user-facing change?**:
```
NONE
```
Updated import dependency tracking.
Factored in the cleanup from #77412
Minor fix to go.mod.
I was running e2e VPA tests and some were failing because the tests
assume thata they're running on:
- zonal single-zone cluster, or
- regional multi-zone cluster.
And I was running them on regional, single-zoned cluster.
Change-Id: I110a70d2249f981b60cf76d1ad674ccfcedd8fb3
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.
Not all users of the E2E framework want to run cloud-provider specific
tests. By splitting out the code it becomes possible to decide in
a E2E test suite which providers are supported.
This is achieved in two ways:
- the framework calls certain functions through a provider
interface instead of calling specific cloud provider functions
directly
- tests that are cloud-provider specific directly import the
new provider packages
The ingress test utilities are only needed by a few tests. Splitting
them out into a separate package makes the framework simpler for test
suites not using those tests.
Fixes: #66649
