-
Spike
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
-
False
-
None
-
None
-
None
STORY:
- As an OCP engineer working in platform type External, I would like to make sure the API Load Balancer is properly created according to the OpenShift documentation, so that we can decrease the time taking reviewing many e2e failures failing for wrong configuration not controlled by the cluster.
DESCRIPTION
Platform type External installations are based in agnostic installations (upi), which means user need to create the infrastructure correctly, and the test tooling assumes it was created according to the documentation. Although some tests depends on it, and would eventually fail when, for example, the health checks of API Load Balancer is not properly configured.
We need to find a way to identify such failures and provide a feedback to the user.
The intention of this spike is to create a smoke test to answer some questions like:
- Is the provider's Load Balancer offering supports the minimum requirements of API Load Balancer? Specially for Health Checks (HTTPS, or at least, HTTP)? (we can't accept TCP)
- Is the provider's LB used by the cluster being tested had been created with the supported configuration? Tip: we can rolls out and watch kube-apiserver if it is receiving requests even after marked the health check endpoint as DOWN.
- Is there a smoke test to validate if the provider supports similar API configuration if manipulating kube-apiserver would be more complicated?
- How we can make this validation available to partners (not tied to OCP CI/release repo)?
ENGINEERING REFERENCES
When reviewing the VCSP partner evaluating the preview release (Epic OPCT-20), there was found an issue which the API Load Balancer Health Check was not properly set and there were no e2e tests pointing to it.
- clones
-
SPLAT-2080 [platform-external][CI] Spike agnostic test for LB hairpin connection issues
-
- To Do
-