The spaces are unnecessary because Ginkgo adds spaces automatically.
This was detected before only for tests using the wrapper functions,
now it also gets detected for ginkgo methods.
Inline the endpointSlicesEqual() method into the test, since despite
its generic-sounding name, it made assumptions specific to this test.
Also, port to generic sets.
Move the Endpoints API test from endpointslice.go to endpoints.go
Move the "kubernetes.default Service exists" and "kubernetes.default
endpoints exist" tests to apiserver.go, since (unlike the rest of
service.go/endpointslice.go) they aren't testing the behavior of the
Service/EndpointSlice/Endpoints APIs.
(No code changes, but fixed a typo in a comment.)
While createServiceReportErr could be fixed to use
framework.ExpectNoErrorWithOffset (and, uh, to log "error creating
Service" rather than "error deleting Service"), it's too trivial to
really be all that useful.
The dual-stack integration tests already validate that we get the
expected Endpoints for single- and dual-stack Services. There is no
further "end to end" testing needed for Endpoints, given that
everything in a normal cluster would look at EndpointSlices, not
Endpoints.
Slightly-more-generic replacement for validateEndpointsPortsOrFail()
(but only validates EndpointSlices, not Endpoints).
Also, add two new unit tests to the Endpoints controller, to assert
the correct Endpoints-generating behavior in the cases formerly
covered by the "should serve endpoints on same port and different
protocols" and "should be updated after adding or deleting ports" e2e
tests (since they are now EndpointSlice-only). (There's not much point
in testing the Endpoints controller in "end to end" tests, since
nothing in a normal cluster ever looks at its output, so there's
really only one "end" anyway.)
These tests were using validateEndpointsPortsOrFail() not because they
cared about ports, but just because it was there, or in some cases
because they needed to wait for one pod to exit and a different pod to
start, which can't be done with framework.WaitForServiceEndpointsNum()
(or e2eendpointslice.WaitForEndpointCount) without racing. Update
these tests using the new e2eendpointslice.WaitForEndpointPods, which
can wait for specific expected pods.
(This also means these tests now only watch EndpointSlices, rather
than watching both Endpoints and EndpointSlices, which is fine,
because none of them are doing tricky things that actually require
making assertions about the exact contents of the
Endpoints/EndpointSlices. They just want to know when the controller
has updated things to point to the expected pods.)
A bunch of tests in test/e2e/network were using
validateEndpointsPortsOrFail but didn't actually care about ports at
all; they were just using it because that helper function was there.
Make them use WaitForEndpointCount instead.
Likewise, fix one test that was manually counting Endpoints and
EndpointSlices to use WaitForEndpointCount.
It was trying to reconnect to the LoadBalancer as fast as possible to
try to catch any transient problems, but "as fast as possible" ended
up meaning about 12,500 times a second, which is clearly excessive.
Limit it to 100 times a second.
