Currently, the test-operator role installs the test-operator from the test-operator-index. The goal of this ticket to update the role so that it installs the test-operator from the openstack-operator-index by default according to the updated documentation [1]. Creation of catalogsource and operatorgroup can be dropped [2][3] in case the operator is installed from openstack-operator-index. Note that we should probably still support somehow installation of the test-operator from different indices (e.g., test-operator-index).

This whole change will be useful because:

• We will be running test-operator the same way as the users.
• Once this [4] ticket is merged we will be running tests using the downstream images in downstream if possible and using upstream images in upstream. This will require us to also updated downstream jobs so that they install the test-operator from the downstream build of openstack-operator-index (somewhere in top parent job - needs a research)

DoD:

• Test-operator role installs the test-operator from openstack-operator-index by default.
• The role still supports installation from test-operator-index and other indices.
• The downstream jobs are installing test-operator from downstream build of openstack-operator-index. If not then a new ticket is created to ensure that we deal with this later.

[1] https://openstack-k8s-operators.github.io/test-operator/guide.html#running-test-operator-using-the-operator-lifecycle-manager-olm
[2] https://github.com/openstack-k8s-operators/ci-framework/blob/f7da3b94dbf8f39f7efcfa84369575bc3d271852/roles/test_operator/tasks/main.yml#L30
[3] https://github.com/openstack-k8s-operators/ci-framework/blob/f7da3b94dbf8f39f7efcfa84369575bc3d271852/roles/test_operator/tasks/main.yml#L48
[4] https://issues.redhat.com/browse/OSPRH-7377