Open rewantsoni opened 1 month ago
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
@rewantsoni Please provide a proper PR title and description
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.
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
/retest-required
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.
Looked again, yes, no update required.
@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?
[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
/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
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
New changes are detected. LGTM label has been removed.
Allow provider-server to be deployed in all modes
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 all modes to enable both client to provider communication and cross odf communication.
The PR does the following: