Proposal: Predictable data path in volume across plugins

[clintkitson]

With the current specification, I believe that the same volume is able to be consumed by multiple container orchestrators. From a data perspective, this is true since the target_path as part of the NodePublishVolumeRequest enables the CO to specify to the plugin where the path is that contains the data for the application.

But the process in which the plugin successfully mounts the data directory to the target_path may differ across plugins. The problem is that we may end up with multiple plugin implementations for a specific storage platform, and then an incompatibility volumes being used across these plugins. For example, consumer uses plugin A for the storage platform, has applications read/write to volumes. Consumer then switches to plugin B for same storage platform, the existing applications can no longer read/write data.

This is possible since the node plugin performs multiple mounts. First it does the initial device mount, and then following it can perform a bind mount on a subdirectory to make the volume occupy the target_path. The plugin may determine that /_data is the proper source for the bind mount, or it may determine that /data is the right path. Or it may just mount the device directly to the target_path.

The proposal is to suggest in the spec a standard sub-directory of /data be used for volumes with a bind mount following to target_path. The bind mount is necessary to ensure applications do not see .lost+found or other directories or files that filesystems may establish. Some applications like postgres react negatively to these artifacts since they might expect empty directories.

[jdef]

It sounds like you're describing two discrete problems here: (a) multiple plugin implementations that tie back to the same storage backend (b) exposing filesystem roots (and the dot-path dirs they may contain) to containers Am I parsing this correctly?

…

On Fri, Jun 9, 2017 at 1:17 PM, Clinton Kitson ***@***.***> wrote: With the current specification, I believe that the same volume is able to be consumed by multiple container orchestrators. From a data perspective, this is true since the target_path as part of the NodePublishVolumeRequest enables the CO to specify to the plugin where the path is that contains the data for the application. But the process in which the plugin successfully mounts the data directory to the target_path may differ across plugins. The problem is that we may end up with multiple plugin implementations for a specific storage platform, and then an incompatibility volumes being used across these plugins. For example, consumer uses plugin A for the storage platform, has applications read/write to volumes. Consumer then switches to plugin B for same storage platform, the existing applications can no longer read/write data. This is possible since the node plugin performs multiple mounts. First it does the initial device mount, and then following it can perform a bind mount on a subdirectory to make the volume occupy the target_path. The plugin may determine that /_data is the proper source for the bind mount, or it may determine that /data is the right path. Or it may just mount the device directly to the target_path. The proposal is to suggest in the spec a standard sub-directory of /data be used for volumes with a bind mount following to target_path. The bind mount is necessary to ensure applications do not see .lost+found or other directories or files that filesystems may establish. Some applications like postgres react negatively to these artifacts since they might expect empty directories. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLHhQFuuOMDZco0ZAlWlpt5KYGTQYks5sCX4tgaJpZM4N1nqh> .

[clintkitson]

Yes I think you parsed the two topics, but that are related in the case I am describing. It is (a) which can have different implementations of handling (b) where the issue is.

[saad-ali]

(a) multiple plugin implementations that tie back to the same storage backend

This is not a supported use case for CSI.

(b) exposing filesystem roots (and the dot-path dirs they may contain) to containers

In this case the application needs to handle this by either mounting a subdir or handling it gracefully in application. Forcing this on all implementations doesn't make sense.