-
Story
-
Resolution: Done
-
Critical
-
None
-
None
-
Proactive Architecture
-
False
-
None
-
False
-
-
-
Workloads Sprint 232, Workloads Sprint 233, Workloads Sprint 234
Some of the e2e extended tests rely on the existence of config.openshift.io API to decide whether a test is to be skipped, run or which branch (if-else) of a test should be executed. So far there's been an assumption all the mentioned API is present in any OpenShift installation. MicroShift is the first OpenShift kind that does not deploy the mentioned API. Yet, some of the e2e tests relying on the API are expected to be running and passing over MicroShift. The cluster characteristics deduced from the API objects are:
- cluster topology: HighlyAvailable, SingleReplica
- platform type: AWS, Azure, KubeVirt, OVirt, ...
- network type: OVNKubernetes, OpenShiftSDN
The characteristics are used to decide whether a cluster has a load balancer present, proxy is enabled, ICMP is enabled, etc.
The goal of this task is to suggest an approach on how to make various cluster characteristics available without a need for installing the config.openshift.io API group.
*Alternatives*
- Deploy config.openshift.io API with read-only CR. Disadvantage is the installed MicroShift will not be exactly the same installation as is in production. Previous discussion in https://redhat-internal.slack.com/archives/C03DP9PABNC/p1669976509805749.
- Inject the characteristics as e.g. envs into openshift-tests binary in CI job definitions. Disadvantage is the characteristics will be stored outside a cluster. The jobs have tendency to get quickly outdated.
- Store the characteristics inside a CM. This way the oc command can be extended to print a generic description of a cluster. Disadvantage: the same information about a cluster will be duplicated.
Google docs for reviews/comments in https://docs.google.com/document/d/1b-5b-Cmddt1SbAv6IOSd_Jb53I5aL0ENjPXEQzFxF_k/edit#