Description of the problem:

In 1.2, the chart assumes the RHDH instance is installed in the same namespace as the RHDH subscription. 

This assumption applies for RHDH instance created by the operator, but if there is an existing RHDH instance, it may be already deployed in any namespace.

This affects the creation of the NetworkPolicy - https://github.com/parodos-dev/orchestrator-helm-operator/blob/main/helm-charts/orchestrator/templates/network-policies.yaml#L15

that shares the same assumption.

In any case, the chart creates the NetworkPolicy in the targetNamespace of the subscription and the document suggests creating another namespace which leads to a conflict, since a NetworkPolicy was already created by the chart:

https://github.com/parodos-dev/orchestrator-helm-operator/tree/main/docs/release-1.2#additional-information

How reproducible:

always

Steps to reproduce:

1. Create RHDH instance in test namespace
2. Use the orchestrator-operator to install the orchestrator with RHDH disabled
3. Follow the instructions of https://github.com/parodos-dev/orchestrator-helm-operator/blob/main/docs/release-1.2/existing-rhdh.md 
4. Try access sonataflow resources (data-index or workflows) from RHDH instance.

Actual results:

Communication is denied since there is an existing NetworkPolicy pointing to a wrong namespace than the one in which RHDH instance exist.

Expected results:

RHDH should reach to sonataflow resources.

Addition Information:

Since installing the orchestrator on an existing RHDH instance is considered a common use-case, we should simplify the creation of the NetworkPolicy for the user by enabling the option to specify the namespace of the existing RHDH instance, in case the use provides and (should go with disable RHDH installation by the operator).