Re: Persistent volume ownership issue

On 21 June 2016 at 12:25, Jie Yu wrote: > James, sticky bit means that there will be no write sharing between two > users even if the underlying permission allows it. I'd prefer not having > this restriction:) No, it just prevents users renaming or deleting each others

Allow executors to reject killing request?

Noticed https://issues.apache.org/jira/browse/MESOS-4919 and curious if there were any considerations to allow executors to reject killing requests entirely? This could be quite useful to stateful services where data replication/backfilling latencies are not known in advance and as such

Re: Persistent volume ownership issue

I created https://issues.apache.org/jira/browse/MESOS-5680 to track. Since this is no objection, we'll make sure the fix go into 1.0. - Jie On Tue, Jun 21, 2016 at 12:25 PM, Jie Yu wrote: > James, sticky bit means that there will be no write sharing between two > users

GPU Support: Library Injection

Moving this to a new thread (see some context below). It may be worth exploring adding a generic mechanism for doing label-based injection of volumes: if a container is tagged with a particular label, we will inject a particular volume into the container. For Nvidia GPU containers, the operator

Improving support for partitioned tasks

Currently, Mesos implements a hardcoded policy for handling partitioned agents and tasks: * agents are deemed to be partitioned when they fail health checks (~75 seconds by default) * partitioned agents are removed from the cluster. Frameworks receive TASK_LOST for all tasks running on the

Re: Persistent volume ownership issue

+1 if no one is relying on the old behavior. Jiang Yan Xu  On Mon, Jun 20, 2016 at 11:25 PM, Jie Yu wrote: > Hi folks, > > 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

Re: Persistent volume ownership issue

Non-recursive chown is an improvement over recursive chown which seems fraught and should be avoided. For an interim fix, could you make the volume root world writeable with the sticky bit set? Then you wouldn't have to chown and volume users would still be able to create files. I wonder whether

Re: Persistent volume ownership issue

Currently the volume is owned by say framework user A when a CREATE is done. When a task is launched, the ownership of the volume is changed recursively to say user B, which means the root directory and all of its content has now ownership of user B. This enables user B to write into this

Re: source code compile failure mesos-0.28.0

Can you post the content of "config.log"? Thanks, Neil On Tue, Jun 21, 2016 at 3:17 PM, Ali Aktar wrote: > Hi; > > All dependencies as per doc were installed. I’m using Centos 7: > Linux ip-172-31-46-249.eu-west-1.compute.internal 3.10.0-327.10.1.el7.x86_64 > #1 SMP

Re: source code compile failure mesos-0.28.0

Do you ensure that all dependencies described here: http://mesos.apache.org/documentation/latest/getting-started/ are installed? Furthermore, which Linux flavour are you using? Thanks On Tue, 21 Jun 2016 at 09:22 Ali Aktar wrote: > Hi; > > Can someone please help, I’m

Re: Persistent volume ownership issue

For the case where a container drops down in privileges and still wants to create a new file, this will result in an error if it is at the root of the persistent volume right? Is the recommended pattern then to always create a stub directory at the root of the persistent volume, and then launch

Persistent volume ownership issue

Hi folks, 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