Add GetClosestVolumeIDFromTargetPath API to the Volume API Group

[mauriciopoppe]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind feature

What this PR does / why we need it:
Adds the new Volume API, GetClosestVolumeIDFromTargetPath, it allows getting the closest volume from a target path handling more scenarios as described below.

The algorithm is:

• given a target path do the following for a max of 256 iterations (1)
  • if it's a symlink and has the form Volume{ then its a volume, return it
  • if it's a symlink and points to a location that exists then follow it and go to 1
  • if it's not a symlink then move up one level in the hierarchy and go to 1
  • if after moving one level up we get to the same location then we're at the root, return the volume corresponding to the boot disk

In the following example all the calls to GetClosestVolumeIDFromTargetPath are with paths inside /mnt/disks:

/               (Volume{A}) # boot disk
/foo/bar
/mnt/volume/  (symlink -> Volume{B})
  shared-disk/
     foo/bar/shared0/
     shared1/
/mnt/single0/ (symlink -> Volume{C})  # standalone disk
/mnt/disks/ (discovery directory)
  shared0/ (symlink -> /mnt/volume/shared-disk/foo/bar/shared0) # returns Volume{B}
  shared1/ (symlink -> /mnt/volume/shared-disk/shared1) # returns Volume{B}
  single0/ (symlink -> /mnt/single0) # returns Volume{C}
  volume0/ (symlink -> Volume{D}) # returns Volume{D}
  boot0/   (symlink -> /foo/bar) # returns Volume{A}

Does this PR introduce a user-facing change?:

Add Volume API GetClosestVolumeIDFromTargetPath to find the closest Volume from a given path.

/cc @jingxu97 @ddebroy @msau42

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mauriciopoppe
To complete the pull request process, please assign andyzhangx after the PR has been reviewed.
You can assign the PR to them by writing /assign @andyzhangx in a comment when ready.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[ddebroy]

Recommend starting a v2beta1 API group in volume for the new changes.

[ddebroy]

Will it be possible to make this a more rigorous check? For example, a regex to match the Volume{volumeID} pattern rather than a prefix and also checking with Get-Volume when the regex matches.

[mauriciopoppe]

@jingxu97 shared some code from k/k that uses this function: https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/util/subpath/subpath_windows.go#L62:6, what I saw is that after dereferencing a symlink it had the form: Volume{X} or C:/foo/bar

[ddebroy]

Will it be possible to start a v2beta1 API to incorporate the new set of APIs?

[jingxu97]

I think you are implementing same or similar function of evalSymlink here https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/util/subpath/subpath_windows.go#L92

[mauriciopoppe]

@jingxu97 I see, it's very similar, I think that with these lines:

	if isDeviceOrUncPath(path) || isDriveLetterorEmptyPath(path) {
		klog.V(4).Infof("Path '%s' is not a symlink, return its original form.", path)
		return path, nil
	}

If the path is C:/ then that function will return C:/, the new function in CSI Proxy always returns a volume (in the previous case, it'd return the volume for C:/)

[mauriciopoppe]

/close

#189 implements the same on top of the new v2alpha1 version of the Volume API

[k8s-ci-robot]

@mauriciopoppe: Closed this PR.

In response to this:

/close

#189 implements the same on top of the new v2alpha1 version of the Volume API

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/test-infra repository.