Sushi fileshare: Currently block and file functions are separate.

[jackhaibo]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

What happened: The switch between the block and fileshare functions in the current sushi needs to modify the opensdsstoragetype parameter to block or file in the csi-configmap-opensdsplugin.yaml file and then use command kubectl replace -f . to restart the csi pods, then function can run normally. This implementation is equivalent to two plugins.

kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-configmap-opensdsplugin
data:
  opensdsendpoint: http://8.46.187.238:50040
  opensdsauthstrategy: noauth
  opensdsstoragetype: block
  osauthurl: http://127.0.0.1/identity
  osusername: admin
  ospassword: opensds@123
  ostenantname: admin
  osprojectname: admin
  osuserdomainid: default
  passwordencrypter: aes
  enableEncrypted: F
  osuserdomainid: default

What you expected to happen: According to @xing-yang, the fileshare and block should be in the same plugin.

Anything else we need to know?: In fact, the main reason that the two functions of block and fileshare cannot be placed in the same plugin is that during the deletion process, caller can only obtain the volumeIdparameter and cannot obtain other parameters to judge whether the current deletion is volume or fileshare.My suggestion is to separate as two plugins. Or hotpot's fileshare uses the block's API and that can put them in the same plugin.

@xing-yang @xxwjj @leonwanghui please take a look at this issue as soon as possible.

Environment:

• Sushi(release/branch) version: latest
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[xing-yang]

@jackhaibo Should this issue be opened in nbp repo instead? Is it only a problem when you decide whether to use block API or fileshare API? Does profile help? If it is impossible to use the same plugin, I'm open to separate them into two. I just want to understand exactly what problems we have here.

[jackhaibo]

@xing-yang During the delete or unmap process, the profile can't help, because the profile can't be passed into the function.For example, in the following example, only the volumeId can be obtained from the request parameter of the deleted volume, and the profile cannot be sent in, so that it cannot be determined whether now the volume should be deleted or fileshare. Could you push the kubernetes community to add other parameters into the parameters of the deleted volume and other delete process?

message DeleteVolumeRequest {
  // The ID of the volume to be deprovisioned.
  // This field is REQUIRED.
  string volume_id = 1;

  // Secrets required by plugin to complete volume deletion request.
  // This field is OPTIONAL. Refer to the `Secrets Requirements`
  // section on how to use this field.
  map<string, string> secrets = 2 [(csi_secret) = true];
}

message DeleteVolumeResponse {
  // Intentionally empty.
}

[xing-yang]

What parameters do you need at deletion time? I need an exact list of parameters and why you need them.

Go ahead and make it a separate plugin to support fileshare.

[jackhaibo]

If possible, add VolumeContext: map[string]string{} parameter in VolumeRequest in the following methods:

NodeUnpublishVolume
NodeUnstageVolume
DeleteVolume
ControllerUnpublishVolume
DeleteSnapshot

[satya-gorli]

/assign @jackhaibo