You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When PV's from multiple projects are distributed across netapp volumes, it makes restoration of data impossible. Being able to specify the netapp volume that an iscsi lun or NFS qtree will reside in would enforce multitenancy, separating each OSE Project (or multiple related Projects) into one or more volumes dedicate for this purpose. Andrew Sullivan and my client have proved out that label matching is effective to specify the pvc to pv to lun/qtree relationship, and it would be helpful if Trident supported this.
One challenge here is that when a NetApp LUN or qtree is provisioned, any OSE Project with an outstanding pv is allowed to immediately claim it. This If Trident could provide some enforcement of this and make it standard that project x creates qtrees/luns in volume y, customers would require all PVCs/PV's be created via Trident to enforce this standard.
The text was updated successfully, but these errors were encountered:
Based on how a storage class is defined, Trident does allow limiting the provisioning operation to a single or multiple storage pools. Therefore, supporting your use case is a matter of treating FlexVols as new storage pools for Trident. I'm personally not in favor of passing FlexVol names in PVCs as such infrastructure details are typically not exposed to users. However, as I mentioned, one can achieve the same through storage classes without exposing any details of the infrastructure. Also, as of Kubernetes 1.6, it's not possible to use both storage classes and labels for dynamic provisioning.
This issue should be treated as a requirement for #2 and #31.
Closing this as virtual pools are now supported in Trident that provide a mechanism to correctly select a storage pool when provisioning a Trident volume.
When PV's from multiple projects are distributed across netapp volumes, it makes restoration of data impossible. Being able to specify the netapp volume that an iscsi lun or NFS qtree will reside in would enforce multitenancy, separating each OSE Project (or multiple related Projects) into one or more volumes dedicate for this purpose. Andrew Sullivan and my client have proved out that label matching is effective to specify the pvc to pv to lun/qtree relationship, and it would be helpful if Trident supported this.
One challenge here is that when a NetApp LUN or qtree is provisioned, any OSE Project with an outstanding pv is allowed to immediately claim it. This If Trident could provide some enforcement of this and make it standard that project x creates qtrees/luns in volume y, customers would require all PVCs/PV's be created via Trident to enforce this standard.
The text was updated successfully, but these errors were encountered: