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
When using a GFS2 file system, each compute is allocated its own Rabbit volume. The Rabbit software mounts a collection of mount paths with a common prefix and an ending indexed value.
Application AUTHORS must be aware that their desired mount-point really contains a collection of directories, one for each compute node. The mount point type can be known by consulting the config map values.
We discussed using symbolic links to map the directories to the compute nodes' hostnames. However, this approach may not be desirable due to potential issues with hostnames changing, etc.
The text was updated successfully, but these errors were encountered:
A non-NNF solution for this would be for the compute node application to touch a file on the GFS2 filesystem and deposit an identifier in that file. Then, the containerized application running on the rabbit could look for these files and gather the IDs and configure a map between IDs and the index-mount.
One potential ID could be the filesystem UID, rather than the hostname. Since each compute node gets a separate GFS2 filesystem, this could be a less error prone choice of identification. This depends on how easy it is to obtain the filesystem ID.
Via https://github.com/NearNodeFlash/NearNodeFlash.github.io/tree/containers-communication-update/docs/rfcs/0002#special-note-indexed-mount-type-for-gfs2-file-systems:
We discussed using symbolic links to map the directories to the compute nodes' hostnames. However, this approach may not be desirable due to potential issues with hostnames changing, etc.
The text was updated successfully, but these errors were encountered: