You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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>
.
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.
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.
The text was updated successfully, but these errors were encountered: