Currently, in federated end2end tests, the creation of services are
done with a randomize NodePort selection. It causing e2e test
flakes if the creation of a federated service failed if the port is
not available.
Now the util.CreateService(...) function is re trying to create the
service on different nodePort in an error case. The method retries until
success or 10 creation retry with other random NodePorts.
If never the service has not been created properly on one of the
federated cluster, a Service shards cleanup is executed before retrying
again the federated service creation.
fixes#44018
Automatic merge from submit-queue (batch tested with PRs 42762, 42739, 42425, 42778)
[Federation][e2e] Use correct default dns name in e2e-testing
After some kubefed changes, the environment variable did not get propagated and we defaulted back to 'federation' instead of 'e2e-federation'. This fixes ongoing service test issues in e2e.
After some kubefed changes, the environment variable did not get propagated
and we defaulted back to 'federation' instead of
'e2e-federation'. This fixes ongoing service test issues in e2e.
We now run e2e tests in parallel in the CI environment and nodeports are
a single available range of numbers for all the service objects, so they
have to be unique for each service object.
gives each ingress object a cluster-unique Uid that can be
leveraged by ingress providers.
In the process, supplement the testing of configMap updates to
ensure that the updates are propagated prior to any ingress
object being created. Configmap key/vals for Uid and ProviderUid
must exist at time of Ingress creation.
Cedric Lamoriniere