Re: Mesos CLI

+1 for keeping it in Mesos repo and rewrite it in C++. Also, do we need a CLI work group on this? Thanks & Best Wishes, Tom Xing(邢舟) Emerging Technology Institute, IBM China Software Development Lab -- IBM China Software Development Laboratory (CSDL) Notes ID:Zhou Z

Re: Mesos CLI

+1 for keeping it in the repo. We can establish maintainers for the CLI to ensure that it can maintain a reasonable update cadence. Note that we haven't done this well for the webui and CLI, so we need to make sure we do it better this time around. If the architecture allows for easy integration

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

Re: [GPU] [Allocation] "Scarce" Resource Allocation

As an FYI, preliminary support to work around this issue for GPUs will appear in the 1.0 release https://reviews.apache.org/r/48914/ This doesn't solve the problem of scarce resources in general, but it will at least keep non-GPU workloads from starving out GPU-based workloads on GPU capable

Re: [GPU] [Allocation] "Scarce" Resource Allocation

Thanks, looking forward to discussion and review on your document. The main use case I see here is that some of our frameworks will want to request the GPU resources, and we want to make sure that those frameworks are able to successfully launch tasks on agents with those resources. We want to

Re: Mesos CLI

+1 to in repo C++ would be nice to maintain language parity, GO would be a great choice also -Jake On Tue, Jun 21, 2016 at 3:15 PM, Vinod Kone wrote: > +1 for keeping it in repo. > > Would be nice if the CLI can be written entirely in C++ though, to avoid > supporting

Re: Mesos CLI

+1 for keeping it in repo. Would be nice if the CLI can be written entirely in C++ though, to avoid supporting more languages. On Tue, Jun 21, 2016 at 12:12 PM, Jie Yu wrote: > I personally prefer it being part of the Mesos repo so that when people > install our package,

Re: Mesos CLI

I personally prefer it being part of the Mesos repo so that when people install our package, they'll get the command line tools as well. That also avoids the potential version mismatch between Mesos and CLI (as you mentioned). What does others think? - Jie On Tue, Jun 21, 2016 at 10:20 AM,

Re: 1.0.0 RC2

There are still 8 outstanding issues, including 1 blocker. We are waiting for these to land for RC2. On Fri, Jun 17, 2016 at 5:11 PM, Vinod Kone wrote: > We still have 12 issues, including 1 blocker, targeted for 1.0. > > Dashboard:

Re: Mesos CLI

I've created an Epic to track this: https://issues.apache.org/jira/browse/MESOS-5676 There have been efforts on this that have failed in the past (e.g. https://github.com/mesosphere/mesos-cli) I'm curious what people's thoughts are in terms of keeping the CLI integrated into mesos itself vs.

Re: Slack as the canonical chat channel

Yeah, sound as a good option. On Mon, 20 Jun 2016 at 20:04 Cosmin Lehene wrote: > Looks like there's a majority of +1 for Slack, so this this may be > pointless, however :), have you considered gitter.im ( > https://gitter.im/home/explore/)? > > > It has similar capabilities

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

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

Hi; I’ve managed to solve it, the tar file for 0.28.0 is broken, incomplete, I hand’t noticed that, so I tried downloading 28.2. This has worked perfectly. Many thanks Ali. On 21 Jun 2016, at 13:55, José Guilherme Vanz wrote: > Do you ensure that all dependencies

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

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 Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.2.1511 (Core) Thanks Ali. On 21 Jun 2016, at 13:55, José

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: source code compile failure mesos-0.28.0

Hi; Can someone please help, I’m getting the following errors while running ./configure: [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos checking build system type... x86_64-unknown-linux-gnu checking host system

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

Re: creating mesos cluster of three cloud nodes with public ip

As you said, you agents are outside the network, so you need ``` sudo ./bin/mesos-agent.sh --master=129.114.110.26:5050 ``` On Tue, Jun 21, 2016 at 3:23 AM, Pankaj Saha wrote: > Hi I am using a command like below: > > sudo ./bin/mesos-master.sh --ip=10.50.0.26

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