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.
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_parametersare 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_ARGUMENTSerror 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:
Cons:
parametersandmutable_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