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
Is your feature request related to a problem?/Why is this needed
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I find having one FileSystemId per storage class is limiting
all the PVC's which are created have different reasons for life, with different backup policies, and different delete policies;
if we had to role back to a certain backup for one of the PVC's we would need to figure out how without impacting all other PVC's on the same FileSystem (even though they are in different PVCs, will be in the same filesystem, of which a backup is applied)
/feature
Describe the solution you'd like in detail
A clear and concise description of what you want to happen.
a way to provide us to configure the FileSystem in the PVC, not storage class.
Storage class, when there is no FileSystemId provided
possible way:
provide a FileSystem Resource, allowing us to create a FileSystem in yaml
and the allowing us to reference the managed resource in a PVC
Another possible way:
PVC, will have an option to include the FileSystemId (annotation?)
if provided, it creates an access point to the existing FileSystem
if not provided, it create the filesystem, and access point <- default
the PVC will allow us to spec the folder/volume inside, default is /
it would be nice to be able to specify a back up policy as well against each PVC
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Crossplane (or an custom operator) to setup a storage class for every PVC (1 to 1)
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Hi,
This is indeed interesting.
Not sure how we can handle a Storage Class(SC) with no EFS Id. The reason being SC is immutable. If the driver creates the EFS there will be no way to modify this SC to have a parameter of FileSystemId added. This might need some more brainstorming.
The other idea of being able to pass the FileSystemId can be done where the FileSystemId of the PVC takes precedence over the FileSystemId of the SC. So we can start users having to pass FileSystemId in both SC and PVC where PVC will override it, but if it is not provided in the PVC we must use the FileSystemId in SC.
Is your feature request related to a problem?/Why is this needed
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I find having one FileSystemId per storage class is limiting
all the PVC's which are created have different reasons for life, with different backup policies, and different delete policies;
if we had to role back to a certain backup for one of the PVC's we would need to figure out how without impacting all other PVC's on the same FileSystem (even though they are in different PVCs, will be in the same filesystem, of which a backup is applied)
/feature
Describe the solution you'd like in detail
A clear and concise description of what you want to happen.
a way to provide us to configure the FileSystem in the PVC, not storage class.
Storage class, when there is no FileSystemId provided
possible way:
provide a FileSystem Resource, allowing us to create a FileSystem in yaml
and the allowing us to reference the managed resource in a PVC
Another possible way:
PVC, will have an option to include the FileSystemId (annotation?)
the PVC will allow us to spec the folder/volume inside, default is /
it would be nice to be able to specify a back up policy as well against each PVC
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: