My understanding is that the *usernames* are more portable across machines (e.g. ssh [email protected]), since uid 1000 on the machine where the scheduler is running is not necessarily the same user as uid 1000 on each mesos slave. So, if I want to run tasks as user 'hadoop' across my cluster, I will have to create that user on each node, and depending on the creation order, the uids could differ. The username would still have the same meaning across nodes. Let us know if you disagree, and we can reconsider this. We just use the username for chown'ing the executor sandbox and then running the executor, so a uid could work as well, if it is present.
Note that the FrameworkInfo.user defaults to the user that runs the scheduler process, but this can also be overridden by the scheduler code. Also, each task can override the framework user by setting CommandInfo.user to the desired user just for that executor/task. On Mon, Apr 20, 2015 at 3:48 AM, <[email protected]> wrote: > I’m interested in the user running a mesos task on a slave. The > `switch_user` flag says: > > --[no-]switch_user > Whether to run tasks as the user who submitted them rather than the user > running the slave (requires setuid permission) (default: true) > > Now, from experiments, and from what I read in : > > https://github.com/apache/mesos/blob/master/src/slave/containerizer/fetcher.cpp > > If you run with —switch-user, or with the default configuration, mesos > runs the task on the slave based on the *username* reported by the > framework. I would have expected, in the Unix world, mesos would choose to > go with to the *userid* detected from the framework. > > It is indeed the more portable option IIUC: > - under a unix, two users declared with distinct names and the same userid > are aliases of each other, > - following the userid is standard practice in cross-network applications > (e.g. ssh) > > Why the username ? > > — > FG >
