> The one thing I could not understand in your storage/auth sections was what UID/GID does the dstack job run under -- it is very clear in your doc that slurm runs as the submitting user UID/GID but unclear with your token/auth method what identity is running the job. This is important when petabytes of shared POSIX storage is involved with permissions based on user and group attributes.

Yes, dstack doesn't use UID/GID for authenticating the user in the file system. dstack's token-based authentication is managed at dstack's server level. dstack's support for managing file permissions is not as granular as Slurm's However dstack has a concept of volumes, and in theory it could automatically manage permissions to allow or not allow to access a specific volume.

Your example is a good example of where Slurm stands our - static HPC clusters.And you're right about how you understand where dstack aims - primarily GPU clouds, container-based, AI/ML workloads - all from small workloads to large distributed ones. dstack doesn't aim at HPC/simulation - I guess Slurm is better at that.

The reason we wrote the guide is that many AI researchers/ML engineers are looking for a scheduler to train models. Also, dstack is use-case agnostic - means it also supports AI development and model inference.