Skip to content
This repository has been archived by the owner on Dec 1, 2022. It is now read-only.

frontier-squid storageClassName is hard coded to "nfs-provisioner" #582

Open
rptaylor opened this issue Jul 13, 2022 · 2 comments
Open

frontier-squid storageClassName is hard coded to "nfs-provisioner" #582

rptaylor opened this issue Jul 13, 2022 · 2 comments
Assignees

Comments

@rptaylor
Copy link

rptaylor commented Jul 13, 2022

https://github.com/slateci/slate-catalog/blob/master/stable/osg-frontier-squid/osg-frontier-squid/templates/pvc.yaml#L17

Each cluster may have different CSI provisioners so the storageClassName should be a configurable variable.
In fact, usually it shouldn't need to be set because the cluster's default storageClass should be sufficient. I think a PVC should only need to specify a storageClass if there are multiple types of storage available and it has a strong opinion on which type of storage it wants, so having storageClassName absent (unless defined by the user) may be a suitable default.

Note that the DefaultStorageClass admission controller is enabled by default.

Moreover, to support the use of statically provisioned volumes, it would be good for the helm chart to also support setting volumeName, with storageClassName: "" as described here:
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reserving-a-persistentvolume
NB storageClassName: "" is different from not having a storageClassName.

@LincolnBryant
Copy link
Contributor

Hi @rptaylor

I think this is a good idea. We'll tackle this shortly! Thanks for the links.

@rptaylor
Copy link
Author

@LincolnBryant Okay great. I may be able to make some MRs for straightforward fixes if you want.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants