I agree that the executor shouldn't need to known about the sandbox host path for itself but today it provides a way for the information to be propagated to the scheduler or external systems.
I don't remember how thermos observer works but I guess the executor registers itself to a the observer and provides it with information about the host path for its sandbox? I could be incorrect about thermos but this usage pattern exists elsewhere as well and will break after this change. Overall I agree that we should deprecate this usage pattern but it's worth providing solutions to replace it. This sandbox host path information is available through the agent's /state endpoint but I don't think it's available via the agent HTTP API? The `GetExecutors` call doesn't return this path but its `ListFiles` and `ReadFile` calls expect this path. Should the host path be added to the result of GetExecutors call? (This being just one example) On Fri, Oct 7, 2016 at 4:49 PM, Jie Yu <[email protected]> wrote: > Hi, > > Want to initiate a discussion here. Before Mesos containerizer has > container image support (all containers share the same host file system), > $MESOS_DIRECTORY env variable is used to let executor know their sandbox > location. > > Later, we introduced container image support to Mesos containerizer so that > each container can has its own root filesystem. Due to some historical > reason (thermos), we decided to keep $MESOS_DIRECTORY to be the path to the > sandbox on the host filesystem (e.g., `/var/lib/mesos/slaves/...`) even if > the container has its own root filesystem. And introduced a new > $MESOS_SANDBOX to point to the sandbox in the container's root filesystem > (e.g., `/mnt/mesos/sandbox`). If the container does not have a root > filesystem, $MESOS_DIRECTORY == $MESOS_SANDBOX. > > Now, we plan to deprecate $MESOS_DIRECTORY because it'll be really > confusing to executor writers, and it'll be an error if they try to access > $MESOS_DIRECTORY if their container has a root filesystem defined. > > - Jie >
