Sorry,
Forgot to mention the platform details. Seeing the crash on Debian 8
dmin@ip-172-31-26-151:~/mesos/build$ cat /etc/issue
Debian GNU/Linux 8 \n \l
admin@ip-172-31-26-151:~/mesos/build$ uname -a
Linux ip-172-31-26-151 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3
(2016-01-17) x86_64 GNU/
I am seeing the following crash when I run mesos build of 0.28.0-rc1 `sudo
bin/mesos-tests.sh` :
[ RUN ] MemIsolatorTest/1.MemUsage
F0305 02:43:01.791003 32494 isolator_tests.cpp:905] CHECK_SOME(isolator):
Failed to create memory cgroup: Failed to mount cg
roups hierarchy at '/sys/fs/cgroup/me
Hi,
If you are in the NYC area and are a Mesos enthusiast, you might be
interested in the upcoming meetup in NYC.
Please visit http://www.meetup.com/Apache-Mesos-NYC-Meetup/events/229086077/
for more details.
Looking forward to the meetup,
Vinod
P.S: @MPark, can you please add this to our event
+1 (Binding)
Successful CI builds for the following distros:
amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid
On Fri, Mar 4, 2016 at 1:06 PM, Vinod Kone wrote:
> Bad copy paste into the email, sorry. It looks fine in the CHANGELOG.
+1 (binding)
On Mon, Feb 29, 2016 at 3:24 PM, Greg Mann wrote:
> +1 (non-binding)
>
> `sudo make check` on Ubuntu 14.04, using gcc with libevent and SSL enabled.
> All tests pass except MemoryPressureMesosTest.CGROUPS_ROOT_Statistics,
> which is a known failure in 0.24.
>
> Cheers,
> Greg
>
>
>
+1 (binding)
Greg's upgrade scripts & CI results
On Fri, Mar 4, 2016 at 11:30 AM, Vinod Kone wrote:
> +1 (binding)
>
> On Tue, Mar 1, 2016 at 5:03 PM, Kevin Klues wrote:
>
> > I committed a fix for this in:
> >
> >
> https://github.com/apache/mesos/commit/42f746937233349660c687ea7a66cc0a7887166
+1 (binding)
Greg's upgrade scripts & CI results
On Tue, Mar 1, 2016 at 4:37 PM, Greg Mann wrote:
> I was also able to successfully test a simple upgrade scenario between
> 0.24.2-rc1 and 0.25.1-rc1 using Niklas's upgrade testing script, which I've
> modified slightly and reposted here: https://
Steven, sorry about the delay. I'll finish the doc today.
On Fri, Mar 4, 2016 at 10:29 AM, Steven Schlansker <
sschlans...@opentable.com> wrote:
>
> > On Mar 3, 2016, at 5:43 PM, Vinod Kone wrote:
> >
> > Hi all,
> > Please vote on releasing the following candidate as Apache Mesos 0.28.0.
> > 0.
+1 (binding)
On Tue, Mar 1, 2016 at 5:03 PM, Kevin Klues wrote:
> I committed a fix for this in:
>
> https://github.com/apache/mesos/commit/42f746937233349660c687ea7a66cc0a78871663
>
> Looks like that's post 0.26 though, so maybe it should be included in the
> .1 rc
>
> On Mon, Feb 29, 2016 at 2
I will rename mesos-provisioner.md -> container-image.md, and do some
re-writing.
- Jie
On Fri, Mar 4, 2016 at 10:35 AM, Jie Yu wrote:
> I am writing that as you speaking
>
> On Fri, Mar 4, 2016 at 10:34 AM, Vinod Kone wrote:
>
>> I think this was supposed to refer to
>> https://github.com/apa
I am writing that as you speaking
On Fri, Mar 4, 2016 at 10:34 AM, Vinod Kone wrote:
> I think this was supposed to refer to
> https://github.com/apache/mesos/blob/master/docs/mesos-containerizer.md
>
> @Jie ^^ ?
>
> On Fri, Mar 4, 2016 at 10:29 AM, Steven Schlansker <
> sschlans...@opentable.co
I think this was supposed to refer to
https://github.com/apache/mesos/blob/master/docs/mesos-containerizer.md
@Jie ^^ ?
On Fri, Mar 4, 2016 at 10:29 AM, Steven Schlansker <
sschlans...@opentable.com> wrote:
>
> > On Mar 3, 2016, at 5:43 PM, Vinod Kone wrote:
> >
> > Hi all,
> > Please vote on r
> On Mar 3, 2016, at 5:43 PM, Vinod Kone wrote:
>
> Hi all,
> Please vote on releasing the following candidate as Apache Mesos 0.28.0.
> 0.28.0 includes the following:
> ...
> * [MESOS-2840] - **Experimental** support for container images in Mesos
> containerizer (a.k.a. Unified Containeri
Bad copy paste into the email, sorry. It looks fine in the CHANGELOG.
On Fri, Mar 4, 2016 at 12:52 AM, Shuai Lin wrote:
> * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
>> Scheduler API.
>> * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
>> ACLs t
Check this out
https://github.com/Capgemini/Apollo/blob/devel/roles/mesos/templates/mesos-slave.service.j2
We run our stack on CoreOS.
Thanks,
Graham.
On 4 Mar 2016, at 12:00, Krish
mailto:krishnan.k.i...@gmail.com>> wrote:
Hi,
I am trying to run mesos slave in a docker container on coreos an
I hit this bug now: https://issues.apache.org/jira/browse/MESOS-3553
Even though I am exporting the LIBPROCESS_IP, my task fails the DNS
resolution and bails out.
Any chance this will be ported to 0.24.1?
In the meantime, any workarounds for this?
--
κρισhναν
On Fri, Mar 4, 2016 at 5:47 PM, Kri
Thanks Stephen! I did just that.
Can you please let me know why is it needed in both containers - the slave
container and the job container?
--
κρισhναν
On Fri, Mar 4, 2016 at 5:30 PM, Erb, Stephan
wrote:
> The Aurora executor runs within the container you want to launch. You
> have to inst
?The Aurora executor runs within the container you want to launch. You have to
install libsasl in there and not just within the container running the slave.
Regards,
Stephan
From: Krish
Sent: Friday, March 4, 2016 12:57
To: user@mesos.apache.org
Subject: Run me
Hi,
I am trying to run mesos slave in a docker container on coreos and am stuck
at libsasl2 dependency.
When I run an aurora job on it, I get this stacktrace in the sandbox stderr:
Traceback (most recent call last):
File "apache/aurora/executor/bin/thermos_executor_main.py", line 45, in
fro
>
> * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
> * [MESOS-4591] - Change the object of ReserveResources and CreateVolume
> ACLs to `roles`.
> * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> Scheduler API.
MESOS-4712 is included
20 matches
Mail list logo
