Test ControllerModifyVolume for "Values specified in mutable_parameters MUST take precedence over the values from parameters"

[AndrewSirenko]

TLDR: The ControllerModifyVolume RPC sanity tests added in PR #538 do not cover the CSI Spec requirement of 'Values specified in mutable_parameters MUST take precedence over the values from parameters.` However, the current best idea for adding this test would require yet another csi-sanity test file, which is a confusing experience for CSI Driver maintainers.

---

An issue I had implementing this test case is that parameters & mutable_parameters are opaque, and therefore CSI components have no visibility into created volume respecting the precedence.

One way we could potentially test this is by finding a shared parameter + mutable_parameter (looping through the two lists), and forcing the mutable_parameter to be invalid. If the driver would return INVALID_ARGUMENTS error code, it suggests that precedence is respected, and the test would pass.

However, I was afraid that this would be too 'hacky' of a test to add, because we don't know if there are shared parameters, or what an invalid parameter might be.

---

Hemant suggested that the CSI Driver writer can pass in an additional flag where a shared parameter name can be passed, and requiring that this flag be passed if driver implements the ModifyVolume RPC. With this + the invalid_arguments precedence test above we could test this CSI Spec requirement.

Pros:

• This forces CSI Driver writer to know about this precedence requirement.

Cons:

• Another test flag/file. Not the most intuitive to add because it likely needs to mention what would make the parameter invalid.
• We need some way of skipping this test if the tested CSI Driver does not share any parameters between parameters and mutable_parameters.

---

I'll go create a PR with this test and additional flag sometime mid-August, and then we can debate its inclusion once we see the code. But in meantime, I am all ears for a better idea.

/assign

[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