Support multi-tenancy in access zone networks (v2.14.1 hotfix)#452
Conversation
Co-authored-by: Don Khan <don.khan@dell.com>
Co-authored-by: Alexander Hoppe <Alexander.Hoppe@dell.com>
Co-authored-by: Oliver Chen <oliver.chen1@dell.com>
Co-authored-by: Don Khan <don.khan@dell.com>
bpjain2004
left a comment
There was a problem hiding this comment.
Have you validated the following use cases related to these changes?
-
Mixed Access Zones (Access-Zone-1 & System Zone):
Create a PVC pvc1 in Access-Zone-1 using a storage class configured with a valid AzServiceIP and AzNetwork, and attach it to a pod scheduled on node1.
Create another PVC pvc2 in the System access zone using a default storage class (no AZ, AzServiceIP, or AzNetwork) and attach it to a pod forcibly scheduled on node1.
Expected behavior:
pvc1 export should use the client IP from the AzNetwork of Access-Zone-1.
pvc2 export should use the default client IP based on the node’s IP (k8s node IP). -
Different Access Zones (Access-Zone-1 & Access-Zone-3):
Create a PVC pvc1 in Access-Zone-1 with the appropriate AzServiceIP and AzNetwork, and attach it to a pod on node1.
Create another PVC pvc2 in Access-Zone-3 with its respective AzServiceIP and AzNetwork, and attach it to another pod also scheduled on node1.
Expected behavior:
pvc1 export should use the client IP from the AzNetwork of Access-Zone-1.
pvc2 export should use the client IP from the AzNetwork of Access-Zone-3.
However, based on the current implementation, it appears that in both scenarios, all PVC exports are using the client IP from the AzNetwork of Access-Zone-1.
Could you please verify this? This is to make sure that we are backward compatible and there are no regressions.
Thanks for the suggestions. We tested exactly what you said in the second point before raising the PR and verified that the exports are using the corresponding client IPs from the AZ networks. I have sent you the logs. For the first point, AZ1 works the same way. But for the System access zone, due to the network setup of the cluster provided for us, we weren't able to see the same result. So we determined to run on a normal cluster to make sure backward compatibility, and Kubernetes E2E has passed with an image built from this branch. |
Description
Add the ability to support multiple tenants by allowing for storage classes to specify an access zone which will be used to match nodes and networks in the access zone. On driver startup the nodes will be labelled with entries aligning with the networks and IP addresses, for example:
csi-isilon.dellemc.com/az-192.168.100.0-24-192.168.100.10=trueDuring CreateVolume the storage class will contain the new field for specifying the access zone and that value will override the value in the driver's configuration.
NOTE: This PR intends to support the same functionality of multi-tenancy in AZ networks as in #432. However, this PR is built on top of the
v2.14.0branch instead ofmain.GitHub Issues
List the GitHub issues impacted by this PR:
Checklist:
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration
AzNetworkparameter). NFS volumes provisioned for a tenant are exported using an IP from that tenant’s network interface.