E2e kind tests

[coleenquadros]

https://issues.redhat.com/browse/ACM-10473

For kind tests the following changes were made

• Since kind needs prometheus installed, an annotation is added to MCO to enable the installPrometheus flag. This allows the code path to take the installPrometheus flags route to install the necessary resources while running on kind.
• We need to also ensure that the prometheus resources are installed in the correct namespace i.e. the open-cluster-management-observability. Even the clusterrolebindings should refer to the correct namespace. The scrape-targets has been modified in place to ensure the jobs in the correct namespace are picked.
• Annotations logic was merged with e2e tests PR - https://github.com/stolostron/multicluster-observability-operator/pull/1400/files

[jacobbaungard]

Looks good, I just wonder if you can explain a little further why this is specifically needed in the kind tests, vs a normal deployment?

We need to also ensure that the prometheus resources are installed in the correct namespace i.e. the open-cluster-management-observability. Even the clusterrolebindings should refer to the correct namespace. The scrape-targets has been modified in place to ensure the jobs in the correct namespace are picked.

[coleenquadros]

Looks good, I just wonder if you can explain a little further why this is specifically needed in the kind tests, vs a normal deployment?

We need to also ensure that the prometheus resources are installed in the correct namespace i.e. the open-cluster-management-observability. Even the clusterrolebindings should refer to the correct namespace. The scrape-targets has been modified in place to ensure the jobs in the correct namespace are picked.

@jacobbaungard
In the normal deployments in the Hub which is always an OCP cluster, we have prometheus installed and the cluster role bindings subjects and scrape jobs point to the open-cluster-management-addon-observability namespace in the templates which is correct in the case of a normal non-OCP spoke when it needs to install prometheus because that namespace exists. In the case of a kind cluster behaving as a hub, we need to explicitly install prometheus and the role bindings subjects and scrape targets should point to open-cluster-management-observability namespace. Under normal deployments we will never install prometheus in the hub because its always an OCP cluster and will have prometheus.

This is how its always been tested prior to global hub changes and now we are just ensuring the correct namespace is referred to in kind.

[jacobbaungard]

Thanks for the explanation @coleenquadros , makes sense!

/lgtm

[coleenquadros]

/retest

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: coleenquadros, jacobbaungard, philipgough

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [coleenquadros,jacobbaungard,philipgough]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

New changes are detected. LGTM label has been removed.

[philipgough]

/test test-e2e

[coleenquadros]

/retest

[sonarqubecloud]

Quality Gate failed

Failed conditions
33.3% Coverage on New Code (required ≥ 70%)

See analysis details on SonarCloud

[openshift-ci]

@coleenquadros: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/sonarcloud	f1a95fd	link	true	/test sonarcloud

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.