Update provider-api-server to be deployed in internal and provider mode

[rewantsoni]

Allow provider-server to be deployed in intenal and provider mode

Why? This is a part of RDR for Provider Mode RHSTOR-4886. With this epic, we are introducing rpc calls for odf to odf communication, the RPC's we have for this epic are limited to Onboarding a Storage Cluster on different Openshift clusters and Getting the Mirroring Info required for setting up RDR (refer #2671).

This can also be used to replace the mechanism we have in the internal mode for setting up Mirroring for blockpool using MCO's Agents.

Hence moving the ocs-provider-server deployment to be deployed in both modes to enable both client to provider communication and cross odf communication.

The PR does the following:

1. Create service, deployment, onboarding job for both modes
2. Update the variable from watchnamespace to podnamespace
3. Remove hardcoded name for storagecluster
4. Move client configmap in storageclient
5. Update the unit tests

[openshift-ci[bot]]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[nb-ohad]

@rewantsoni Please provide a proper PR title and description

[iamniting]

Can the provider handle requests for multiple storage clusters?

Do we want to run only one ocs-provider-server deployment in case of the multiple storagecluster?

If yes then we can have it as part of the ocs initialization otherwise it should be part of the storagecluster reconciliation.

[rewantsoni]

Can the provider handle requests for multiple storage clusters?

Yes, the server should be able to handle multiple storage clusters, but the client will onboard to only the storageCluster in the same namespace as the provider-server

Do we want to run only one ocs-provider-server deployment in case of the multiple storagecluster?

Yes, one provider-server for multiple storageClusters

If yes then we can have it as part of the ocs initialization otherwise it should be part of the storagecluster reconciliation.

I have added the deployment as a part of csv and secret, service as part of ocsinit

[rewantsoni]

/retest-required

[rewantsoni]

client-op needs an update after this gets merged, isn't it?

@leelavg I don't think we need any update in client o/p after merging this, let me know if I missed anything.

[leelavg]

Looked again, yes, no update required.

[obnoxxx]

@nb-ohad wrote:

@rewantsoni Please provide a proper PR title and description

I think the description is leaking too much internal downstream product information to this public project.

Shouldn't we try to avoid this?

[nb-ohad]

/hold

@rewantsoni This PR introduces architecture changes to the way we handle the API service. Looking at the code I think these changes are unnecessary, complicated, and are pushing us in the wrong direction. I would like to have more discussion on this

[nb-ohad]

Adding to my last comment: The API server is not part of the orchestrator, it is part of the application being deployed. Assuming multiple StorageClusters deployed over multiple namespaces, I would expect to see an API server in each of these namespaces, the same way I would expect to see any other orchestrated payload.

We also need to consider that each of these might be configured differently

[nb-ohad]

LGTM

[rewantsoni]

rebased the PR

[nb-ohad]

@iamniting Can you please take a look as well?

[rewantsoni]

moved unit-tests into a separate commit

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: iamniting, rewantsoni

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](https://github.com/red-hat-storage/ocs-operator/blob/main/OWNERS)~~ [iamniting] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[iamniting]

/unhold