Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

+1 Tested on Fedora release 23 (Twenty Three) - make check - 1.0.0-rc2 2016-07-15 23:01 GMT+08:00 haosdent : > +1 > > Tested on CentOS 7. > > - sudo make check > - upgrade from 0.28.2 to 1.0.0-rc2 > > On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov >

Re: Initial Design Document Apache Mesos Federation (JIRA 3548)

Hi All, I got a chance to bring this up during yesterdays Community Sync. It was great discussing with you all. As a general feedback the role of policy engine in the design needs to be clearer, i will update the Document with more information on PE very soon. We are yet to get more insight on

Re: mesos agent not recovering after ZK init failure

Vinod, MESOS-5854 created. Feel free to change the priority appropriately. Yes, the workaround I mentioned for disk size is based on resource specification, so that works for now. On Fri, Jul 15, 2016 at 11:48 AM, Andrew Leung

Re: mesos agent not recovering after ZK init failure

Hi Jie, Yes, that is how we are working around this issue. However, we wanted to see if others were hitting this issue as well. If others had a similar Mesos Slave on ZFS setup, it might be worth considering a disk space calculation approach that works more reliably with ZFS or at least

Re: mesos agent not recovering after ZK init failure

On Fri, Jul 15, 2016 at 11:31 AM, Sharma Podila wrote: > We had this issue happen again and were able to debug further. The cause > for agent not being able to restart is that one of the resources (disk) > changed its total size since the last restart. However, this error

Re: mesos agent not recovering after ZK init failure

Can you hard code your disk size using --resources flag? On Fri, Jul 15, 2016 at 11:31 AM, Sharma Podila wrote: > We had this issue happen again and were able to debug further. The cause > for agent not being able to restart is that one of the resources (disk) > changed

Re: mesos agent not recovering after ZK init failure

We had this issue happen again and were able to debug further. The cause for agent not being able to restart is that one of the resources (disk) changed its total size since the last restart. However, this error does not show up in INFO/WARN/ERROR files. We saw it in stdout only when manually

Re: Windows Build on Jenkins almost working

A few notes: * Lowering the number of warnings is on our TODO list. Currently, seeing 1000's of warnings is fairly common :( * The windows build does not work if your files have Unix-style line endings. If you use Git on Windows, you should run: git config core.autocrlf true * The CMake

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

+1 Tested on CentOS 7. - sudo make check - upgrade from 0.28.2 to 1.0.0-rc2 On Fri, Jul 15, 2016 at 7:47 PM, Alex Rukletsov wrote: > Haosdent investigated the issue, and it seems that health checks do work > for docker executor. Hence I retract my negative vote. > > On

RE: mesos/dcos user issue?

That’s not entirely true. “USER 4567” without an entry for the uid in /etc/password works just fine when I run the docker image. My problem is that regardless of the existence of the user in the container, mesos/dcos seem to be complaining when the user doesn’t exist on the host system.

Re: Mesos fine-grained multi-user mode failed to allocate tasks

Cook launches shells with around one minute of latency. I believe there is a project to reduce that to seconds. On Thu, Jul 14, 2016 at 10:50 PM Rahul Palamuttam wrote: > Hallelujah! > > We'll definitely take a look at cook. > Right now we're observing in both fine

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

Haosdent investigated the issue, and it seems that health checks do work for docker executor. Hence I retract my negative vote. On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov wrote: > -1 (binding): MESOS-5848 > . The fix

Re: [VOTE] Release Apache Mesos 1.0.0 (rc2)

-1 (binding): MESOS-5848 . The fix is on the way. On Wed, Jul 13, 2016 at 1:19 AM, Zhitao Li wrote: > +1 (nonbinding) > > Tested by 1)running all tests on Mac OS, 2) perform upgrade and downgrade > on a small test cluster