fix: intree volume unmount failure

[andyzhangx]

What type of PR is this?
/kind bug

What this PR does / why we need it:
fix: intree volume unmount failure

though intree volume is not supported any more, we still want to address the unmount failure if there is solution with best efforts

Which issue(s) this PR fixes:

Fixes #

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

NodeUnpublishVolume: remove direct volume mount info #storage--storage-test-rotate#arc-appint-stage-p-env1northcentralusstagerotate4830#volume1#containerapps-ns1 from /var/lib/kubelet/pods/5c80b21a-52ee-42c9-bd96-3c66bbd2a108/volumes/kubernetes.io~csi/#xx#xx#volume1#containerapps-ns1/mount azurefile E0723 03:20:44.829002       1 utils.go:110] GRPC error: rpc error: code = Internal desc = failed to direct volume remove mount info /var/lib/kubelet/pods/5c80b21a-52ee-42c9-bd96-3c66bbd2a108/volumes/kubernetes.io~csi/#xx#xx#volume1#containerapps-ns1/mount: unlinkat /run/kata-containers/shared/direct-volumes/xx-xx==: file name too long  

Release note:

fix: intree volume unmount failure

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andyzhangx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andyzhangx]

/cherrypick release-1.33

[andyzhangx]

/cherrypick release-1.32

[k8s-infra-cherrypick-robot]

@andyzhangx: new pull request created: #2689

In response to this:

/cherrypick release-1.33

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-infra-cherrypick-robot]

@andyzhangx: new pull request created: #2690

In response to this:

/cherrypick release-1.32

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[nearora-msft]

@andyzhangx is this issue applicable only to the in-tree volumes?
I don't think it should matter whether it is in-tree or csi?

[andyzhangx]

@andyzhangx is this issue applicable only to the in-tree volumes? I don't think it should matter whether it is in-tree or csi?

@nearora-msft in-tree volume would make the mount path longer than csi volume, and from what users have reported, all such issues are due to using in-tree volume, I don't see there is csi volume hitting such issue up till now, do you have any?

[nearora-msft]

@andyzhangx is this issue applicable only to the in-tree volumes? I don't think it should matter whether it is in-tree or csi?

@nearora-msft in-tree volume would make the mount path longer than csi volume, and from what users have reported, all such issues are due to using in-tree volume, I don't see there is csi volume hitting such issue up till now, do you have any?

Oh I see, thanks for responding. No I haven't seen any other than this.

[nearora-msft]

@andyzhangx is this issue applicable only to the in-tree volumes? I don't think it should matter whether it is in-tree or csi?

@nearora-msft in-tree volume would make the mount path longer than csi volume, and from what users have reported, all such issues are due to using in-tree volume, I don't see there is csi volume hitting such issue up till now, do you have any?

Oh I see, thanks for responding. No I haven't seen any other than this.

@andyzhangx on another note, why was enableKataCCMount path invoked for the customer? Shouldn't it be disabled by default unless the cx has set it in storageclass or PV?

[andyzhangx]

@andyzhangx is this issue applicable only to the in-tree volumes? I don't think it should matter whether it is in-tree or csi?

@nearora-msft in-tree volume would make the mount path longer than csi volume, and from what users have reported, all such issues are due to using in-tree volume, I don't see there is csi volume hitting such issue up till now, do you have any?

Oh I see, thanks for responding. No I haven't seen any other than this.

@andyzhangx on another note, why was enableKataCCMount path invoked for the customer? Shouldn't it be disabled by default unless the cx has set it in storageclass or PV?

@nearora-msft that would require an extra config in sc if user wants to mount pv on kata enabled node, with current design, as long as it's kata enabled node, user could mount azure file volume directly without any extra config.