server: add rbd storageid and clientProfile name to the GetStorageClientInfo rpc #3189
Conversation
Signed-off-by: Rewant Soni <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rewantsoni The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
rewantsoni
changed the title
send the clientProfile and rbd storageid from the GetStorageClinetsInfo rpc Signed-off-by: Rewant Soni <[email protected]>
rewantsoni
force-pushed
the
clientprofilemapping
branch
from
0732217 to
b4eb10e
Compare
|
@rewantsoni: The following test failed, say
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-sigs/prow repository. I understand the commands that are listed here. |
ClientProfileMapping creation requires blockpoolIDs (local and remote) and clientProfile (local and remote). We are sending the remote blockpool IDs via the getBlockPoolsInfo rpc call. For 4.18 provider mode RDR, we made an assumption as the clientProfile name was a hash of the storageClaim name. This doesn't hold true for 4.19 onwards. We need to move away from such an assumption and fetch the remote ClientProfile from the other side. Hence, adding the clientProfile name to the GetStorageClientsInfo rpc.
There is another hack that we use to construct the rbdStorageID from the mirroring token and remote radosnamesape to build the replicationID. We should stop relying on this hack a well and send the rbdstorageID in the GetStorageClientsInfo rpc.
Fixes a part of https://issues.redhat.com/browse/DFBUGS-2307 , more PRs will follow for the mirroring controller and the provider server (update the ClientProfileMapping and remove the hack for peer rbd storageID)