NodePublishVolume target_path uniqueness requirement

[Jgoldick]

There is an assumed uniqueness of target_path across Volumes that today must be enforced by the CO. If two volumes had the same target_path and they ended up on the same node there would be problems, even worse this bad config would be masked if they were first published on different nodes.

Even if we implemented the changes described in https://github.com/container-storage-interface/spec/issues/17 and the target_path would still need to be unique relative to the container-scoped name space.

Note for those of a Windows-bent: be aware that not every file system is case sensitive so one can have two different strings that are effectively the same target_path.

[jdef]

The CO determines target_path. I think we envisioned that CO's would be smart enough to not specify overlapping values for target_path such that multiple vols were published to the same path. Are you saying that CSI should explicity state this assumption?

…

On Sun, Jun 18, 2017 at 9:41 PM, Jgoldick ***@***.***> wrote: There is an assumed uniqueness of target_path across Volumes that today must be enforced by the CO. If two volumes had the same target_path and they ended up on the same node there would be problems, even worse this bad config would be masked if they were first published on different nodes. Even if we implemented the changes described in #17 <http://url> and the <#37> target_path would still need to be unique relative to the container-scoped name space. Note for those of a Windows-bent: be aware that not every file system is case sensitive so one can have two different strings that are effectively the same target_path. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLIrbyyay1tmCYVhNAlfueBbVqnO-ks5sFdG0gaJpZM4N9rDL> .

[Jgoldick]

Yes, I have a general leaning to making assumptions explicit in specs within reason.

While I know there's a background assumption that these paths are probably some form of hash or UUID, that is not necessarily going to be case forever unless it's added as a requirement in this spec.

There's a lot of motivation for human readable strings in practice. Once you allow that, and add in the fact that Windows file names are case-insensitive Unicode, then cluster unique target names are not going to happen without enforcement by the CO.