oss: allow setup mime.types by configmap

[AlbeeSo]

What type of PR is this?

/kind feature

What this PR does / why we need it:

allow users setup mime.types with volume scoped, and modify it after CSI startup

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: AlbeeSo
Once this PR has been reviewed and has the lgtm label, please assign mowangdk for approval. For more information see the Kubernetes Code Review Process.

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

[huww98]

I would design the API like this:
Add two per-PV options:

• mimeVolume: we just pass it through to fuse pod spec.volumes. Should support both hostPath and configMap type volume. The name of configmap should be configurable.
• mimeSubpath: use this path to access the actual mime.types file in the volume

The current design is not desiable because:

• If user have too many volumes, the ossfs-mime-config can be very large. It is not scalable.
• The user cannot reuse the same config for multiple volume, making ossfs-mime-config even larger. And hard to operate.
• It is hard to authorize config for different volumes to different users (e.g. by RBAC) if we put all of them in the same configMap.

[huww98]

Please reuse clientset, for rate-limiter and others to work properly.

[huww98]

Please try to inject a fake clientset into the tested instance, and avoid modifying global state, to enable parallel test in the future.
And, why not use the fake clientset implemented in client-go?

[AlbeeSo]

I would design the API like this: Add two per-PV options:

• mimeVolume: we just pass it through to fuse pod spec.volumes. Should support both hostPath and configMap type volume. The name of configmap should be configurable.
• mimeSubpath: use this path to access the actual mime.types file in the volume

The current design is not desiable because:

• If user have too many volumes, the ossfs-mime-config can be very large. It is not scalable.
• The user cannot reuse the same config for multiple volume, making ossfs-mime-config even larger. And hard to operate.
• It is hard to authorize config for different volumes to different users (e.g. by RBAC) if we put all of them in the same configMap.

sounds great. but i think a entire volume config is a little bit hard to config? maybe we can just support the configmap way to set up the mime.types. users can just specify the name of cm, then CSI convert the map of data to standard format for mime.types.