[
https://issues.apache.org/jira/browse/MESOS-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15342991#comment-15342991
]
Jie Yu commented on MESOS-5680:
-------------------------------
https://reviews.apache.org/r/49045
> We should not 'chown -R' on persistent volumes every time container tries to
> use it.
> ------------------------------------------------------------------------------------
>
> Key: MESOS-5680
> URL: https://issues.apache.org/jira/browse/MESOS-5680
> Project: Mesos
> Issue Type: Bug
> Reporter: Jie Yu
> Fix For: 1.0.0
>
>
> See the discussion here:
> http://mail-archives.apache.org/mod_mbox/mesos-user/201606.mbox/%3CCAJvN1BPBd0_7XOTtpA1mJtP-VOh25QGv7-gKyv%2Bi84p_PUHp9Q%40mail.gmail.com%3E
> {noformat}
> Currently, the ownership of the persistent volumes are set to be the same
> as the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
> Recently, we realized that this behavior is not ideal. Especially, if a
> task created some files in the persistent volume, and the owner of those
> file might be different than the task's user. For instance, a task is
> running under root and it creates some database files under user 'database'
> and launch the database process under user 'database'. When the database
> process is restarted by the scheduler, the current behavior is that the
> we'll do a 'chown -R root.root' on the persistent volume, causes database
> files to be chown to 'root'.
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership
> of files created by previous tasks. It should be a very simple fix which we
> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
