help for support for csi snapshot

[garcetto]

good afternoon,
does it support csi snapshot?
thank you.

[tamalsaha]

https://github.com/kubernetes-csi/csi-driver-nfs

[lindhe]

@tamalsaha What do you mean? Is that a no?

[Starttoaster]

The person you're replying to doesn't even appear to be a maintainer here, so they wouldn't have the authority to tell you a "yes" or "no." But as another non-maintainer, they were hinting for you to look at that other NFS storage driver for k8s that already supports snapshotting.

[Starttoaster]

@lindhe You thumbs downed my comment, but the fact is that this NFS driver is a single, <300 lines of code, source file that doesn't even get basic security updates over time (run the latest version of this image through a Trivy scan and you'll see how bad the current state is.) I'm just saying it's unlikely that feature gets added to this NFS provisioner. I would recommend looking at the other NFS provisioner that person linked if this provisioner doesn't already have the feature you requested. I've forked this repository just to give it the security updates it desperately needs, but it seems like the author(s) of this repo may be trying to abandon it in favor of that other one anyway, as it seems to still be quite actively receiving updates.

[lindhe]

@Starttoaster I downvoted your comment because you told me to use another NFS provisioner, which happens to be useless advice to me (for technical reasons). You have no obligation to help me, but I think you wanted to be helpful since you posted a reply. But your reply turned out to be too blunt, lacking the nuance to be helpful for me. Also I disagree that a non-contributor lacks the authority to tell a yes or no. Anyone is allowed to pitch in, if they are knowledgeable!

For the record: it's fine that you wrote a comment I didn't like, I just wanted to express that with a 👎 .

Have a good day. 🙃

[Starttoaster]

Also I disagree that a non-contributor lacks the authority to tell a yes or no.

A non-maintainer quite literally lacks the authority to give a "yes" or "no" to a feature addition. A non-maintainer literally couldn't do a thing about it if the maintainer(s) lacked interest in a feature proposal, besides own their own fork of course. A non-maintainer can voice their opinion, but they can't force a maintainer to accept code they don't want to accept.

lacking the nuance to be helpful for me.

Criticism accepted, I'll try to make my help more nuanced in the future. Granted, I'm not sure that you understand that I was only translating the other person's message for you, and that you were actually disliking their message 🙃

My addition to their message, which you probably also dislike, is just that this NFS provisioner is maintained a bit less closely than the other, that one already having the feature you want too. But I'll take your word for it on the technical reasons for being unable to switch to the other provisioner; I'm imagining the migration would be fairly simple most of the time, mostly requiring standing up a different PVC using the other provisioner's storage class, and copying the current NFS share's data over, and then migrating your services that use the old NFS storage class to the new PVCs. But it sounds like you may have a more unique situation.

But have a good day too. Apologies for the bluntness, we don't all speak with tact 100% of the time.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale