This doubles the termination timeout for the eviction test from 5min to
10min. Reason for that is that the eviction manager relies on pod stats
metrics, which may not be acceessible during a period of time because of
the kubelet API unreachable. This could be reasoned in hardware or
network pressure when multiple tests run in parallel.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
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 special test (for example, one which manages its own cluster) could almost
construct a Framework instance because most fields are exported. The
`clientConfig` field isn't because REST configs often need to be deep-copied to
avoid accidentally updating some shared copy, so for this special case a
SetClientConfig is needed.
This is more useful when viewing results in spyglass because related tests are
shown together. The default was to show them by start or end time (not exactly
sure), which almost looked random because those times are not shown.
It's possible that a conflict will happen when
attempting to create a `ClusterRole` resource
without a randomized name given that is a cluster
scoped object and another object with same name
might exist. This commit fixes this issue by ensuring
the name of the `ClusterRole` is randomized. Additionally,
it adds clean up for the clusterRole and clusterRoleBinding.
This sets the appropriate groups (system:authenticated, system:serviceaccounts,
system:serviceaccounts:<ns>) in the SAR used in WaitForAuthzUpdate to accurately
simulate the service account’s identity.
