Hi Folks, We found some issues for the solutions of this project and propose a better one, see here <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.tjuy5xk67tuu> for details. Please let me know if you have any comments, thanks!
Regards, Qian Zhang On Sat, Apr 28, 2018 at 7:57 AM, Qian Zhang <zhq527...@gmail.com> wrote: > > The framework launched tasks in a group with different users? Sounds > like they dug their own hole :) > > So you mean we should actually put a best practice or limitation in doc: > when launching a task group with multiple tasks to share a SANDBOX volume > of PARENT type, all the tasks should be run with the same user, and that > user must be same with the user to launch the executor? Otherwise the task > will not be able to write to the volume. > > > I'd argue that the "rw" on the sandbox path is analogous to the "rw" > mount option. That is, it is mounted writeable, but says nothing about > which credentials can write to it. > > Can you please elaborate a bit on this? What would you suggest for the > "rw` volume mode? > > > Regards, > Qian Zhang > > On Fri, Apr 27, 2018 at 12:07 PM, James Peach <jor...@gmail.com> wrote: > >> >> >> > On Apr 26, 2018, at 7:25 PM, Qian Zhang <zhq527...@gmail.com> wrote: >> > >> > Hi James, >> > >> > Thanks for your comment! >> > >> > I think you are talking about the SANDBOX_PATH volume ownership issue >> > mentioned in the design doc >> > <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE >> -v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, >> > IIUC, you prefer to leaving it to framework, i.e., framework itself >> ought >> > to be able to handle such issue. But I am curious how framework can >> handle >> > it in such situation. If the framework launches a task group with >> different >> > users and with a SANDBOX_PATH volume of PARENT type, the tasks in the >> group >> > will definitely fail to write to the volume due to the ownership issue >> > though the volume's mode is set to "rw". So in this case, how should >> > framework handle it? >> >> The framework launched tasks in a group with different users? Sounds like >> they dug their own hole :) >> >> I'd argue that the "rw" on the sandbox path is analogous to the "rw" >> mount option. That is, it is mounted writeable, but says nothing about >> which credentials can write to it. >> >> > And if we want to document it, what is our recommended >> > solution in the doc? >> > >> > >> > >> > Regards, >> > Qian Zhang >> > >> > On Fri, Apr 27, 2018 at 1:16 AM, James Peach <jpe...@apache.org> wrote: >> > >> >> I commented on the doc, but at least some of the issues raised there I >> >> would not regard as issues. Rather, they are about setting expectations >> >> correctly and ensuring that we are documenting (and maybe enforcing) >> >> sensible behavior. >> >> >> >> I'm not that keen on Mesos automatically "fixing" filesystem >> permissions >> >> and we should proceed down that path with caution, especially in the >> ACLs >> >> case. >> >> >> >>> On Apr 10, 2018, at 3:15 AM, Qian Zhang <zhq527...@gmail.com> wrote: >> >>> >> >>> Hi Folks, >> >>> >> >>> I am working on MESOS-8767 to improve Mesos volume support regarding >> >> volume ownership and permission, here is the design doc. Please feel >> free >> >> to let me know if you have any comments/feedbacks, you can reply this >> mail >> >> or comment on the design doc directly. Thanks! >> >>> >> >>> >> >>> Regards, >> >>> Qian Zhang >> >> >> >> >> >> >
