[jira] [Commented] (MESOS-3123) DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
[
https://issues.apache.org/jira/browse/MESOS-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877239#comment-14877239
]
haosdent commented on MESOS-3123:
-
I met this one today.
We need add hostname to /etc/hosts. And the record could not be a 127.0.0.1,
should be a access ip.
So that slave launch on this ip and docker could communicated with the slave
with this access ip.
> DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
> ---
>
> Key: MESOS-3123
> URL: https://issues.apache.org/jira/browse/MESOS-3123
> Project: Mesos
> Issue Type: Bug
> Components: docker, test
>Affects Versions: 0.23.0
> Environment: CentOS 7.1, or Ubuntu 14.04
> Mesos 0.23.0-rc4 or today's master
>Reporter: Adam B
>Assignee: Timothy Chen
> Labels: mesosphere
>
> Fails the test and then crashes while trying to shutdown the slaves.
> {code}
> [ RUN ] DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged
> ../../src/tests/docker_containerizer_tests.cpp:618: Failure
> Value of: statusRunning.get().state()
> Actual: TASK_LOST
> Expected: TASK_RUNNING
> ../../src/tests/docker_containerizer_tests.cpp:619: Failure
> Failed to wait 1mins for statusFinished
> ../../src/tests/docker_containerizer_tests.cpp:610: Failure
> Actual function call count doesn't match EXPECT_CALL(sched,
> statusUpdate(, _))...
> Expected: to be called twice
>Actual: called once - unsatisfied and active
> F0721 21:59:54.950773 30622 logging.cpp:57] RAW: Pure virtual method called
> @ 0x7f3915347a02 google::LogMessage::Fail()
> @ 0x7f391534cee4 google::RawLog__()
> @ 0x7f3914890312 __cxa_pure_virtual
> @ 0x88c3ae mesos::internal::tests::Cluster::Slaves::shutdown()
> @ 0x88c176 mesos::internal::tests::Cluster::Slaves::~Slaves()
> @ 0x88dc16 mesos::internal::tests::Cluster::~Cluster()
> @ 0x88dc87 mesos::internal::tests::MesosTest::~MesosTest()
> @ 0xa529ab
> mesos::internal::tests::DockerContainerizerTest::~DockerContainerizerTest()
> @ 0xa8125f
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @ 0xa8128e
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @ 0x1218b4e testing::Test::DeleteSelf_()
> @ 0x1221909
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x121cb38
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x1205713 testing::TestInfo::Run()
> @ 0x1205c4e testing::TestCase::Run()
> @ 0x120a9ca testing::internal::UnitTestImpl::RunAllTests()
> @ 0x122277b
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x121d81b
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x120987a testing::UnitTest::Run()
> @ 0xcfbf0c main
> @ 0x7f391097caf5 __libc_start_main
> @ 0x882089 (unknown)
> make[3]: *** [check-local] Aborted (core dumped)
> make[3]: Leaving directory `/home/me/mesos/build/src'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/home/me/mesos/build/src'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory `/home/me/mesos/build/src'
> make: *** [check-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3475) TestContainerizer should not modify global environment variables
[
https://issues.apache.org/jira/browse/MESOS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3475:
---
Assignee: haosdent
> TestContainerizer should not modify global environment variables
>
>
> Key: MESOS-3475
> URL: https://issues.apache.org/jira/browse/MESOS-3475
> Project: Mesos
> Issue Type: Bug
>Reporter: Joris Van Remoortere
>Assignee: haosdent
>
> Currently the {{TestContainerizer}} modifies the environment variables. Since
> these are global variables, this can cause other threads reading these
> variables to get inconsistent results, or even segfault if they happen to
> read while the environment is being changed.
> Synchronizing within the TestContainerizer is not sufficient. We should pass
> the environment variables into a fork, or set them on the command line of an
> execute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3475) TestContainerizer should not modify global environment variables
[
https://issues.apache.org/jira/browse/MESOS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3475:
---
Assignee: haosdent
> TestContainerizer should not modify global environment variables
>
>
> Key: MESOS-3475
> URL: https://issues.apache.org/jira/browse/MESOS-3475
> Project: Mesos
> Issue Type: Bug
>Reporter: Joris Van Remoortere
>Assignee: haosdent
>
> Currently the {{TestContainerizer}} modifies the environment variables. Since
> these are global variables, this can cause other threads reading these
> variables to get inconsistent results, or even segfault if they happen to
> read while the environment is being changed.
> Synchronizing within the TestContainerizer is not sufficient. We should pass
> the environment variables into a fork, or set them on the command line of an
> execute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900025#comment-14900025
]
haosdent commented on MESOS-3413:
-
[~neunhoef] No sure I understand your ideas correct or not. Let me show how I
use persistent volumes in docker below.
I need set the volume info correctly in ContainerInfo, so that docker executor
would mount the persistent volumes. Suppose we have already set up a "path1"
persistent volume correctly.
{code}
ContainerInfo::DockerInfo dockerInfo;
dockerInfo.set_image("busybox");
Volume* dockerVolume = containerInfo.add_volumes();
dockerVolume->set_host_path("path1");
dockerVolume->set_container_path("/path2");
dockerVolume->set_mode(Volume::RW);
containerInfo.mutable_docker()->CopyFrom(dockerInfo);
{code}
We could found the docker executor would mount the "path1" to "/path2" in
docker docker. I got below log from executor stderr file.
{code}
docker -v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906/path1:/path2:rw
-v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906:/mnt/mesos/sandbox
--net host --entrypoint /bin/sh --name
mesos-db206124-6d5f-493b-8b72-fdfbf65ed744-S0.88cc5c49-50bd-4bab-9e74-f23c43504906
busybox -c ls /
{code}
>From executor stdout file, because I run "ls /" command we also could see the
>/path2 exists.
{code}
Starting task 1
bin
dev
etc
home
lib
lib64
linuxrc
media
mnt
opt
path2
proc
root
run
sbin
sys
tmp
usr
var
{code}
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker, slave
>Affects Versions: 0.23.0
>Reporter: Max Neunhöffer
>Assignee: haosdent
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For the ArangoDB framework I am trying to use the persistent primitives.
> nearly all is working, but I am missing a crucial piece at the end: I have
> successfully created a persistent disk resource and have set the persistence
> and volume information in the DiskInfo message. However, I do not see any way
> to find out what directory on the host the mesos slave has reserved for us. I
> know it is ${MESOS_SLAVE_WORKDIR}/volumes/roles//_ but we
> have no way to query this information anywhere. The docker containerizer does
> not automatically mount this directory into our docker container, or symlinks
> it into our sandbox. Therefore, I have essentially no access to it. Note that
> the mesos containerizer (which I cannot use for other reasons) seems to
> create a symlink in the sandbox to the actual path for the persistent volume.
> With that, I could mount the volume into our docker container and all would
> be well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3475) TestContainerizer should not modify global environment variables
[
https://issues.apache.org/jira/browse/MESOS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3475:
Assignee: (was: haosdent)
> TestContainerizer should not modify global environment variables
>
>
> Key: MESOS-3475
> URL: https://issues.apache.org/jira/browse/MESOS-3475
> Project: Mesos
> Issue Type: Bug
>Reporter: Joris Van Remoortere
>
> Currently the {{TestContainerizer}} modifies the environment variables. Since
> these are global variables, this can cause other threads reading these
> variables to get inconsistent results, or even segfault if they happen to
> read while the environment is being changed.
> Synchronizing within the TestContainerizer is not sufficient. We should pass
> the environment variables into a fork, or set them on the command line of an
> execute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3475) TestContainerizer should not modify global environment variables
[
https://issues.apache.org/jira/browse/MESOS-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900027#comment-14900027
]
haosdent commented on MESOS-3475:
-
Oh, sorry.
> TestContainerizer should not modify global environment variables
>
>
> Key: MESOS-3475
> URL: https://issues.apache.org/jira/browse/MESOS-3475
> Project: Mesos
> Issue Type: Bug
>Reporter: Joris Van Remoortere
>
> Currently the {{TestContainerizer}} modifies the environment variables. Since
> these are global variables, this can cause other threads reading these
> variables to get inconsistent results, or even segfault if they happen to
> read while the environment is being changed.
> Synchronizing within the TestContainerizer is not sufficient. We should pass
> the environment variables into a fork, or set them on the command line of an
> execute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900025#comment-14900025
]
haosdent edited comment on MESOS-3413 at 9/21/15 12:49 AM:
---
[~neunhoef] No sure I understand your ideas correct or not. Let me show how I
use persistent volumes in docker below.
I need set the volume info correctly in ContainerInfo, so that docker executor
would mount the persistent volumes. Suppose we have already set up a "path1"
persistent volume correctly.
{code}
ContainerInfo::DockerInfo dockerInfo;
dockerInfo.set_image("busybox");
Volume* dockerVolume = containerInfo.add_volumes();
dockerVolume->set_host_path("path1");
dockerVolume->set_container_path("/path2");
dockerVolume->set_mode(Volume::RW);
containerInfo.mutable_docker()->CopyFrom(dockerInfo);
{code}
We could found the docker executor would mount the "path1" to "/path2" in
docker docker. I got below log from executor stderr file.
{code}
docker -v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906/path1:/path2:rw
-v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906:/mnt/mesos/sandbox
--net host --entrypoint /bin/sh --name
mesos-db206124-6d5f-493b-8b72-fdfbf65ed744-S0.88cc5c49-50bd-4bab-9e74-f23c43504906
busybox -c ls /
{code}
>From executor stdout file, because I run "ls /" command we also could see the
>/path2 exists.
{code}
total 52
drwxrwxr-x2 root root 4096 May 22 2014 bin
drwxr-xr-x5 root root 360 Sep 21 00:48 dev
drwxr-xr-x6 root root 4096 Sep 21 00:48 etc
drwxrwxr-x4 root root 4096 May 22 2014 home
drwxrwxr-x2 root root 4096 May 22 2014 lib
lrwxrwxrwx1 root root 3 May 22 2014 lib64 -> lib
lrwxrwxrwx1 root root11 May 22 2014 linuxrc -> bin/busybox
drwxrwxr-x2 root root 4096 Feb 27 2014 media
drwxrwxr-x3 root root 4096 Sep 21 00:48 mnt
drwxrwxr-x2 root root 4096 Feb 27 2014 opt
drwxr-xr-x2 root root 4096 Sep 21 00:48 path1
dr-xr-xr-x 171 root root 0 Sep 21 00:48 proc
drwx--2 root root 4096 Feb 27 2014 root
lrwxrwxrwx1 root root 3 Feb 27 2014 run -> tmp
drwxr-xr-x2 root root 4096 May 22 2014 sbin
dr-xr-xr-x 13 root root 0 Aug 12 09:16 sys
drwxrwxrwt3 root root 4096 May 22 2014 tmp
drwxrwxr-x6 root root 4096 May 22 2014 usr
drwxrwxr-x4 root root 4096 May 22 2014 var
{code}
was (Author: haosd...@gmail.com):
[~neunhoef] No sure I understand your ideas correct or not. Let me show how I
use persistent volumes in docker below.
I need set the volume info correctly in ContainerInfo, so that docker executor
would mount the persistent volumes. Suppose we have already set up a "path1"
persistent volume correctly.
{code}
ContainerInfo::DockerInfo dockerInfo;
dockerInfo.set_image("busybox");
Volume* dockerVolume = containerInfo.add_volumes();
dockerVolume->set_host_path("path1");
dockerVolume->set_container_path("/path2");
dockerVolume->set_mode(Volume::RW);
containerInfo.mutable_docker()->CopyFrom(dockerInfo);
{code}
We could found the docker executor would mount the "path1" to "/path2" in
docker docker. I got below log from executor stderr file.
{code}
docker -v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906/path1:/path2:rw
-v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906:/mnt/mesos/sandbox
--net host --entrypoint /bin/sh --name
mesos-db206124-6d5f-493b-8b72-fdfbf65ed744-S0.88cc5c49-50bd-4bab-9e74-f23c43504906
busybox -c ls /
{code}
>From executor stdout file, because I run "ls /" command we also could see the
>/path2 exists.
{code}
Starting task 1
bin
dev
etc
home
lib
lib64
linuxrc
media
mnt
opt
path2
proc
root
run
sbin
sys
tmp
usr
var
{code}
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: conta
[jira] [Comment Edited] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900025#comment-14900025
]
haosdent edited comment on MESOS-3413 at 9/21/15 12:49 AM:
---
[~neunhoef] No sure I understand your ideas correct or not. Let me show how I
use persistent volumes in docker below.
I need set the volume info correctly in ContainerInfo, so that docker executor
would mount the persistent volumes. Suppose we have already set up a "path1"
persistent volume correctly.
{code}
ContainerInfo::DockerInfo dockerInfo;
dockerInfo.set_image("busybox");
Volume* dockerVolume = containerInfo.add_volumes();
dockerVolume->set_host_path("path1");
dockerVolume->set_container_path("/path2");
dockerVolume->set_mode(Volume::RW);
containerInfo.mutable_docker()->CopyFrom(dockerInfo);
{code}
We could found the docker executor would mount the "path1" to "/path2" in
docker docker. I got below log from executor stderr file.
{code}
docker -v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906/path1:/path2:rw
-v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906:/mnt/mesos/sandbox
--net host --entrypoint /bin/sh --name
mesos-db206124-6d5f-493b-8b72-fdfbf65ed744-S0.88cc5c49-50bd-4bab-9e74-f23c43504906
busybox -c ls /
{code}
>From executor stdout file, because I run "ls /" command we also could see the
>/path2 exists.
{code}
total 52
drwxrwxr-x2 root root 4096 May 22 2014 bin
drwxr-xr-x5 root root 360 Sep 21 00:48 dev
drwxr-xr-x6 root root 4096 Sep 21 00:48 etc
drwxrwxr-x4 root root 4096 May 22 2014 home
drwxrwxr-x2 root root 4096 May 22 2014 lib
lrwxrwxrwx1 root root 3 May 22 2014 lib64 -> lib
lrwxrwxrwx1 root root11 May 22 2014 linuxrc -> bin/busybox
drwxrwxr-x2 root root 4096 Feb 27 2014 media
drwxrwxr-x3 root root 4096 Sep 21 00:48 mnt
drwxrwxr-x2 root root 4096 Feb 27 2014 opt
drwxr-xr-x2 root root 4096 Sep 21 00:48 path2
dr-xr-xr-x 171 root root 0 Sep 21 00:48 proc
drwx--2 root root 4096 Feb 27 2014 root
lrwxrwxrwx1 root root 3 Feb 27 2014 run -> tmp
drwxr-xr-x2 root root 4096 May 22 2014 sbin
dr-xr-xr-x 13 root root 0 Aug 12 09:16 sys
drwxrwxrwt3 root root 4096 May 22 2014 tmp
drwxrwxr-x6 root root 4096 May 22 2014 usr
drwxrwxr-x4 root root 4096 May 22 2014 var
{code}
was (Author: haosd...@gmail.com):
[~neunhoef] No sure I understand your ideas correct or not. Let me show how I
use persistent volumes in docker below.
I need set the volume info correctly in ContainerInfo, so that docker executor
would mount the persistent volumes. Suppose we have already set up a "path1"
persistent volume correctly.
{code}
ContainerInfo::DockerInfo dockerInfo;
dockerInfo.set_image("busybox");
Volume* dockerVolume = containerInfo.add_volumes();
dockerVolume->set_host_path("path1");
dockerVolume->set_container_path("/path2");
dockerVolume->set_mode(Volume::RW);
containerInfo.mutable_docker()->CopyFrom(dockerInfo);
{code}
We could found the docker executor would mount the "path1" to "/path2" in
docker docker. I got below log from executor stderr file.
{code}
docker -v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906/path1:/path2:rw
-v
/tmp//slaves/db206124-6d5f-493b-8b72-fdfbf65ed744-S0/frameworks/db206124-6d5f-493b-8b72-fdfbf65ed744-/executors/1/runs/88cc5c49-50bd-4bab-9e74-f23c43504906:/mnt/mesos/sandbox
--net host --entrypoint /bin/sh --name
mesos-db206124-6d5f-493b-8b72-fdfbf65ed744-S0.88cc5c49-50bd-4bab-9e74-f23c43504906
busybox -c ls /
{code}
>From executor stdout file, because I run "ls /" command we also could see the
>/path2 exists.
{code}
total 52
drwxrwxr-x2 root root 4096 May 22 2014 bin
drwxr-xr-x5 root root 360 Sep 21 00:48 dev
drwxr-xr-x6 root root 4096 Sep 21 00:48 etc
drwxrwxr-x4 root root 4096 May 22 2014 home
drwxrwxr-x2 root root 4096 May 22 2014 lib
lrwxrwxrwx1 root root 3 May 22 2014 lib64 -> lib
lrwxrwxrwx1 root root11 May 22 2014 linuxrc -> bin/busybox
drwx
[jira] [Commented] (MESOS-3046) Stout's UUID re-seeds a new random generator during each call to UUID::random.
[
https://issues.apache.org/jira/browse/MESOS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805207#comment-14805207
]
haosdent commented on MESOS-3046:
-
Oh, I use /usr/local/opt/llvm/bin/clang++ (install through brew)
{code}
clang version 3.6.2 (tags/RELEASE_362/final)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
{code} could not pass
use default /usr/bin/clang++ could pass.
{code}
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
{code}
> Stout's UUID re-seeds a new random generator during each call to UUID::random.
> --
>
> Key: MESOS-3046
> URL: https://issues.apache.org/jira/browse/MESOS-3046
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Benjamin Mahler
>Assignee: Klaus Ma
> Labels: newbie, twitter
> Fix For: 0.25.0
>
> Attachments: tl.cpp
>
>
> Per [~StephanErb] and [~kevints]'s observations on MESOS-2940, stout's UUID
> abstraction is re-seeding the random generator during each call to
> {{UUID::random()}}, which is really expensive.
> This is confirmed in the perf graph from MESOS-2940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3462) Containerization issues with mesos running on CoreOS
[
https://issues.apache.org/jira/browse/MESOS-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14899953#comment-14899953
]
haosdent commented on MESOS-3462:
-
Hi, [~francischuang] Sorry for deplay. I have some questions need confirm with
you.
1. If you build the mesos in ubuntu and "make install" in same ubuntu machine,
could it success?
2. Could you try this in your CoreOS successfully?
{code}
export LD_LIBRARY_PATH=/opt/mesos/lib
python -c "import mesos.native"
{code}
> Containerization issues with mesos running on CoreOS
>
>
> Key: MESOS-3462
> URL: https://issues.apache.org/jira/browse/MESOS-3462
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 0.24.0
> Environment: CoreOS 801.0.0 64-bit
>Reporter: Francis Chuang
>Assignee: haosdent
>
> These are the steps to I used to build mesos 0.24.0 on Ubuntu 15.04 64-bit:
> wget http://www.apache.org/dist/mesos/0.24.0/mesos-0.24.0.tar.gz
> wget http://mirror.ventraip.net.au/apache/apr/apr-1.5.2.tar.gz
> wget http://mirror.ventraip.net.au/apache/apr/apr-util-1.5.4.tar.gz
> wget http://mirror.ventraip.net.au/apache/subversion/subversion-1.9.0.tar.gz
> wget http://www.sqlite.org/sqlite-amalgamation-3071501.zip
> wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz
> mkdir /tmp/mesos-build
> cd /tmp/mesos-build
> - Build apr
> tar zxf apr-$APR_VERSION.tar.gz
> cd apr-$APR_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/apr
> make
> make install
> cd ..
> - Build apr-util
> tar zxf apr-util-$APR_UTIL_VERSION.tar.gz
> cd apr-util-$APR_UTIL_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/apr-util
> --with-apr=/tmp/mesos-build/apr
> make
> make install
> cd ..
> - Build libsasl2
> tar zxf cyrus-sasl-$SASL_VERSION.tar.gz
> cd cyrus-sasl-$SASL_VERSION
> ./configure CC=gcc-4.8 CPPFLAGS=-I/usr/include/openssl
> --prefix=/tmp/mesos-build/sasl2 --enable-cram
> make
> make install
> cd ..
> - Build subversion
> tar zxf subversion-$SVN_VERSION.tar.gz
> unzip sqlite-amalgamation-$SQLITE_AMALGATION_VERSION.zip
> mv sqlite-amalgamation-$SQLITE_AMALGATION_VERSION/
> subversion-$SVN_VERSION/sqlite-amalgamation/
> cd subversion-$SVN_VERSION
> ./configure CC=gcc-4.8 CXX=g++-4.8 --prefix=/tmp/mesos-build/svn
> --with-apr=/tmp/mesos-build/apr --with-apr-util=/tmp/mesos-build/apr-util
> --with-sasl=/tmp/mesos-build/sasl2
> make
> make install
> cd ..
> - Build curl
> tar zxf curl-$CURL_VERSION.tar.gz
> cd curl-$CURL_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/curl
> make
> make install
> cd ..
> - Build mesos
> tar zxf mesos-$MESOS_VERSION.tar.gz
> cd mesos-$MESOS_VERSION
> mkdir build
> cd build
> ../configure CC=gcc-4.8 CXX=g++-4.8
> LD_LIBRARY_PATH=/tmp/mesos-build/sasl2/lib
> SASL_PATH=/tmp/mesos-build/sasl2/lib/sasl2 --prefix=/tmp/mesos-build/mesos
> --with-svn=/tmp/mesos-build/svn --with-apr=/tmp/mesos-build/apr
> --with-sasl=/tmp/mesos-build/sasl2/ --with-curl=/tmp/mesos-build/curl
> make
> make install
> cd ..
> cd ..
> - Copy shared objects into mesos build
> cp apr/lib/libapr-1.so.0.5.2 mesos/lib/libapr-1.so.0
> cp apr-util/lib/libaprutil-1.so.0.5.4 mesos/lib/libaprutil-1.so.0
> cp sasl2/lib/libsasl2.so.3.0.0 mesos/lib/libsasl2.so.3
> cp svn/lib/libsvn_delta-1.so.0.0.0 mesos/lib/libsvn_delta-1.so.0
> cp svn/lib/libsvn_subr-1.so.0.0.0 mesos/lib/libsvn_subr-1.so.0
> I then compress the build into an archive and distributed it onto my CoreOS
> nodes.
> Once I have the archive extracted on each node, I start the master and slaves:
> /opt/mesos/sbin/mesos-master --zk=zk://192.168.33.10/mesos --quorum=1
> --hostname=192.168.33.10 --ip=192.168.33.10
> --webui_dir=/opt/mesos/share/mesos/webui --cluster=mesos
> /opt/mesos/sbin/mesos-slave --hostname=192.168.33.11 --ip=192.168.33.11
> --master=zk://192.168.33.10/mesos
> --executor_environment_variables='{"LD_LIBRARY_PATH": "/opt/mesos/lib",
> "PATH": "/opt/java/bin:/usr/sbin:/usr/bin"}' --containerizers=docker,mesos
> --executor_registration_timeout=60mins
> --launcher_dir=/opt/mesos/libexec/mesos/
> In addition, the following environment variables are set:
> LD_LIBRARY_PATH=/opt/mesos/lib/
> JAVA_HOME=/opt/java
> MESOS_NATIVE_JAVA_LIBRARY=/opt/mesos/lib/libmesos.so
> I am finding that when I run meso-hdfs from
> https://github.com/mesosphere/hdfs, the scheduler starts properly and
> launches the executors. However, the executors will fail and terminat
[jira] [Commented] (MESOS-3451) Failing tests after changes to Isolator/MesosContainerizer API
[
https://issues.apache.org/jira/browse/MESOS-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14899935#comment-14899935
]
haosdent commented on MESOS-3451:
-
[~karya][~jieyu] I think this issue is similar to
[MESOS-3474|https://issues.apache.org/jira/browse/MESOS-3474]
In LinuxLauncher, we use
{code}
// - unsigned long long used for best alignment.
// - static is ok because each child gets their own copy after the clone.
// - 8 MiB appears to be the default for "ulimit -s" on OSX and Linux.
- static unsigned long long stack[(8*1024*1024)/sizeof(unsigned long long)];
{code}
a share memory as child stack. But because we have multi slaves, this share
memory would be override in different threads. So that all threads would got
the same "pipes" and same execute "function" pointer. This cause the problems
above.
> Failing tests after changes to Isolator/MesosContainerizer API
> --
>
> Key: MESOS-3451
> URL: https://issues.apache.org/jira/browse/MESOS-3451
> Project: Mesos
> Issue Type: Bug
> Components: isolation
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>Priority: Blocker
>
> The failures are related to the following recent commits :
> e047f7d69b5297cc787487b6093119a3be517e48
> fc541a9a97eb1d86c27452019ff217eed11ed5a3
> 6923bb3e8cfbddde9fbabc6ca4edc29d9fc96c06
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900337#comment-14900337
]
chenqiang commented on MESOS-3079:
--
Hi Marco Massenzio, I encountered those 37 fails also, and I run following
commands, I can't connect to the mesos web page via http://127.0.0.1:5050, so
does those failures made it cannot access or still have others? thanks.
# Start mesos master (Ensure work directory exists and has proper
permissions).
$ ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos
# Start mesos slave.
$ ./bin/mesos-slave.sh --master=127.0.0.1:5050
# Visit the mesos web page.
$ http://127.0.0.1:5050
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Re
[jira] [Commented] (MESOS-3500) Task counters are broken in mesos ui
[ https://issues.apache.org/jira/browse/MESOS-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14904473#comment-14904473 ] haosdent commented on MESOS-3500: - Seems duplicated with https://issues.apache.org/jira/browse/MESOS-3282 Patch is https://reviews.apache.org/r/38056/ Could you also help review it? > Task counters are broken in mesos ui > > > Key: MESOS-3500 > URL: https://issues.apache.org/jira/browse/MESOS-3500 > Project: Mesos > Issue Type: Bug > Components: statistics, webui >Affects Versions: 0.23.0, 0.24.0 >Reporter: Ian Babrou > > People ignored my comment in MESOS-2058 so I'm creating a dedicated issue. > Task counters in the left panel of mesos ui are empty. This bug appeared in > 0.23.0 and wasn't fixed in 0.24.0. > !http://i.imgur.com/31yZ5be.png! > I though about fixing it myself, but lack of response discouraged me from > doing so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906051#comment-14906051
]
chenqiang commented on MESOS-3079:
--
yes, I thought it would be related to these, but I found not later. So, I
commened to expain that before, OK, thanks all you guys.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Assigned] (MESOS-3482) Compile fails with -Duser.home option set.
[
https://issues.apache.org/jira/browse/MESOS-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3482:
---
Assignee: haosdent
> Compile fails with -Duser.home option set.
> --
>
> Key: MESOS-3482
> URL: https://issues.apache.org/jira/browse/MESOS-3482
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.24.0
> Environment: OS X 10.11, MacBook Pro Mid-2012, Clang-700.0.72
>Reporter: Dominyk Tiller
>Assignee: haosdent
> Labels: build
>
> Apologies in advance; I'm not sure if this is technically your bug or a bug
> with the upstream javadoc plugin.
> I'm trying to sandbox the Mesos installation so the downloaded
> plugins/jars/etc needed by Maven for installation aren't retained after the
> build, as otherwise they get dumped in "$HOME/.m2". To achieve this I've
> exported:
> {noformat}
> _JAVA_OPTIONS=-Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> {noformat}
> This causes the following build failure:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:48 min
> [INFO] Finished at: 2015-09-21T15:24:14+01:00
> [INFO] Final Memory: 29M/242M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:
> [ERROR] Exit code: 1 - Picked up _JAVA_OPTIONS:
> -Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> [ERROR] javadoc: error - No packages or classes specified.
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/javadoc
> @options
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/src/java/target/apidocs'
> dir.
> {noformat}
> Can confirm without setting that variable, the build is fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3482) Compile fails with -Duser.home option set.
[
https://issues.apache.org/jira/browse/MESOS-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906229#comment-14906229
]
haosdent commented on MESOS-3482:
-
I update to lastest jdk. Don't have this error anymore. Seems the root error is
build javadoc failed
{code}
Downloaded:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.jar
(191 KB at 77.9 KB/sec)
Downloaded:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.5/plexus-utils-3.0.5.jar
(226 KB at 87.7 KB/sec)
[WARNING] -subpackages option is not supported on Java version < 1.4
[INFO]
Usage: javadoc [options] [packagenames] [sourcefiles] [@files]
-overview Read overview documentation from HTML file
-public Show only public classes and members
-protected Show protected/public classes and members
(default)
-package Show package/protected/public classes and
members
-private Show all classes and members
-helpDisplay command line options and exit
-doclet Generate output via alternate doclet
-docletpathSpecify where to find doclet class files
-sourcepathSpecify where to find source files
-classpath Specify where to find user class files
-cpSpecify where to find user class files
-excludeSpecify a list of packages to exclude
-subpackages Specify subpackages to recursively load
-breakiterator Compute first sentence with BreakIterator
-bootclasspath Override location of class files loaded
by the bootstrap class loader
-source Provide source compatibility with specified
release
-extdirsOverride location of installed extensions
-verbose Output messages about what Javadoc is doing
-localeLocale to be used, e.g. en_US or en_US_WIN
-encoding Source file encoding name
-quiet Do not display status messages
-J Pass directly to the runtime system
-X Print a synopsis of nonstandard options and
exit
Provided by Standard doclet:
-dDestination directory for output files
-use Create class and package usage pages
-version Include @version paragraphs
{code}
> Compile fails with -Duser.home option set.
> --
>
> Key: MESOS-3482
> URL: https://issues.apache.org/jira/browse/MESOS-3482
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.24.0
> Environment: OS X 10.11, MacBook Pro Mid-2012, Clang-700.0.72
>Reporter: Dominyk Tiller
>Assignee: haosdent
> Labels: build
>
> Apologies in advance; I'm not sure if this is technically your bug or a bug
> with the upstream javadoc plugin.
> I'm trying to sandbox the Mesos installation so the downloaded
> plugins/jars/etc needed by Maven for installation aren't retained after the
> build, as otherwise they get dumped in "$HOME/.m2". To achieve this I've
> exported:
> {noformat}
> _JAVA_OPTIONS=-Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> {noformat}
> This causes the following build failure:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:48 min
> [INFO] Finished at: 2015-09-21T15:24:14+01:00
> [INFO] Final Memory: 29M/242M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:
> [ERROR] Exit code: 1 - Picked up _JAVA_OPTIONS:
> -Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> [ERROR] javadoc: error - No packages or classes specified.
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/javadoc
> @options
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/src/java/target/apidocs'
> dir.
> {noformat}
> Can confirm without setting that variable, the build is fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906037#comment-14906037
]
chenqiang commented on MESOS-3079:
--
good leader
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [
[jira] [Commented] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906369#comment-14906369
]
haosdent commented on MESOS-3413:
-
actually the path1 here is container_path in Volume in Resource::DiskInfo.
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker, slave
>Affects Versions: 0.23.0
>Reporter: Max Neunhöffer
>Assignee: haosdent
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For the ArangoDB framework I am trying to use the persistent primitives.
> nearly all is working, but I am missing a crucial piece at the end: I have
> successfully created a persistent disk resource and have set the persistence
> and volume information in the DiskInfo message. However, I do not see any way
> to find out what directory on the host the mesos slave has reserved for us. I
> know it is ${MESOS_SLAVE_WORKDIR}/volumes/roles//_ but we
> have no way to query this information anywhere. The docker containerizer does
> not automatically mount this directory into our docker container, or symlinks
> it into our sandbox. Therefore, I have essentially no access to it. Note that
> the mesos containerizer (which I cannot use for other reasons) seems to
> create a symlink in the sandbox to the actual path for the persistent volume.
> With that, I could mount the volume into our docker container and all would
> be well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3464) Expose Per Executor Disk Statistics Under Agent's "monitor/statistics.json" Endpoint
[ https://issues.apache.org/jira/browse/MESOS-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14904982#comment-14904982 ] haosdent commented on MESOS-3464: - This link maybe also could help you https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L762 > Expose Per Executor Disk Statistics Under Agent's "monitor/statistics.json" > Endpoint > > > Key: MESOS-3464 > URL: https://issues.apache.org/jira/browse/MESOS-3464 > Project: Mesos > Issue Type: Wish >Affects Versions: 0.23.0 >Reporter: Paul Cavallaro >Priority: Minor > > It's great that monitor/statistics.json exists and exposes a lot of the > cgroup statistics, but it would be great if it could also expose per executor > disk usage so that you could monitor that as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3485) Make hook execution order deterministic
[
https://issues.apache.org/jira/browse/MESOS-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3485:
---
Assignee: haosdent
> Make hook execution order deterministic
> ---
>
> Key: MESOS-3485
> URL: https://issues.apache.org/jira/browse/MESOS-3485
> Project: Mesos
> Issue Type: Improvement
> Components: modules
>Reporter: Felix Abecassis
>Assignee: haosdent
>
> Currently, when using multiple hooks of the same type, the execution order is
> implementation-defined.
> This is because in src/hook/manager.cpp, the list of available hooks is
> stored in a {{hashmap<string, Hook*>}}. A hashmap is probably unnecessary for
> this task since the number of hooks should remain reasonable. A data
> structure preserving ordering should be used instead to allow the user to
> predict the execution order of the hooks. I suggest that the execution order
> should be the order in which hooks are specified with {{--hooks}} when
> starting an agent/master.
> This will be useful when combining multiple hooks after MESOS-3366 is done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3482) Compile fails with -Duser.home option set.
[
https://issues.apache.org/jira/browse/MESOS-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906405#comment-14906405
]
haosdent commented on MESOS-3482:
-
This problem is a bug of maven-javadoc-plugin.
https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocUtil.java#L607-L611
maven-javadoc-plugin would use error output to parse javadoc version. And
javadoc also outpute the version information to stdout. Because we set
_JAVA_OPTIONS before, here broke javadoc version parsing.
{code}
if ( StringUtils.isNotEmpty( err.getOutput() ) )
{
return parseJavadocVersion( err.getOutput() );
}
{code}
> Compile fails with -Duser.home option set.
> --
>
> Key: MESOS-3482
> URL: https://issues.apache.org/jira/browse/MESOS-3482
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.24.0
> Environment: OS X 10.11, MacBook Pro Mid-2012, Clang-700.0.72
>Reporter: Dominyk Tiller
>Assignee: haosdent
> Labels: build
>
> Apologies in advance; I'm not sure if this is technically your bug or a bug
> with the upstream javadoc plugin.
> I'm trying to sandbox the Mesos installation so the downloaded
> plugins/jars/etc needed by Maven for installation aren't retained after the
> build, as otherwise they get dumped in "$HOME/.m2". To achieve this I've
> exported:
> {noformat}
> _JAVA_OPTIONS=-Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> {noformat}
> This causes the following build failure:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:48 min
> [INFO] Finished at: 2015-09-21T15:24:14+01:00
> [INFO] Final Memory: 29M/242M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:
> [ERROR] Exit code: 1 - Picked up _JAVA_OPTIONS:
> -Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> [ERROR] javadoc: error - No packages or classes specified.
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/javadoc
> @options
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/src/java/target/apidocs'
> dir.
> {noformat}
> Can confirm without setting that variable, the build is fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3482) Compile fails with -Duser.home option set.
[
https://issues.apache.org/jira/browse/MESOS-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906442#comment-14906442
]
haosdent commented on MESOS-3482:
-
After add
{code}
+# skip build javadoc because Homebrew sandbox set _JAVA_OPTIONS would
+# trigger maven-javadoc-plugin bug.
+# https://issues.apache.org/jira/browse/MESOS-3482
+maven_javadoc_patch = <<-EOS.undent
+
+true
+
+ \\0
+EOS
+inreplace "src/java/mesos.pom.in",
+ "http://mesos.apache.org",
+ maven_javadoc_patch
+
{code}
==> Summary
/usr/local/Cellar/mesos/0.24.0: 1184 files, 78M, built in 10.9 minutes
> Compile fails with -Duser.home option set.
> --
>
> Key: MESOS-3482
> URL: https://issues.apache.org/jira/browse/MESOS-3482
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.24.0
> Environment: OS X 10.11, MacBook Pro Mid-2012, Clang-700.0.72
>Reporter: Dominyk Tiller
>Assignee: haosdent
> Labels: build
>
> Apologies in advance; I'm not sure if this is technically your bug or a bug
> with the upstream javadoc plugin.
> I'm trying to sandbox the Mesos installation so the downloaded
> plugins/jars/etc needed by Maven for installation aren't retained after the
> build, as otherwise they get dumped in "$HOME/.m2". To achieve this I've
> exported:
> {noformat}
> _JAVA_OPTIONS=-Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> {noformat}
> This causes the following build failure:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:48 min
> [INFO] Finished at: 2015-09-21T15:24:14+01:00
> [INFO] Final Memory: 29M/242M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:
> [ERROR] Exit code: 1 - Picked up _JAVA_OPTIONS:
> -Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> [ERROR] javadoc: error - No packages or classes specified.
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/javadoc
> @options
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/src/java/target/apidocs'
> dir.
> {noformat}
> Can confirm without setting that variable, the build is fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3282) Web UI no longer shows Tasks information
[ https://issues.apache.org/jira/browse/MESOS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901904#comment-14901904 ] haosdent commented on MESOS-3282: - If you really need it. You could download the patch from https://reviews.apache.org/r/38056/diff.raw And use "patch -p1 < rb38056.patch" to apply the patch. Make it committed need some times I think. > Web UI no longer shows Tasks information > > > Key: MESOS-3282 > URL: https://issues.apache.org/jira/browse/MESOS-3282 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.23.0 >Reporter: Diogo Gomes >Assignee: haosdent > Attachments: task_infomartions.png > > > After update Mesos to 0.23 the Tasks box no longer shows info. Reading the > code, seems like it depends of state.json endpoint. In 0.22.1, it's possible > to see data like "failed_tasks" and"finished_tasks" and this is not present > anymore in 0.23.0 state.json, as is required in > https://github.com/apache/mesos/blob/a0811310c82ee25644fc9a6362313ce3619e46d9/src/webui/master/static/js/controllers.js#L126 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3498) Failed to create a containerizer
[
https://issues.apache.org/jira/browse/MESOS-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903786#comment-14903786
]
haosdent commented on MESOS-3498:
-
If you add --privileged, could you success in
{code}
docker run --privileged rafa/docker-mesos-master mesos-slave
--logging_level='INFO' --log_dir=/var/log/mesos
--master="zk://173.255.192.122:2181/mesos"
{code}
> Failed to create a containerizer
>
>
> Key: MESOS-3498
> URL: https://issues.apache.org/jira/browse/MESOS-3498
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.2
> Ubuntu 14.04.1 LTS
> User: root
> Linux li202-122 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015
> x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Rafael Capucho
>Priority: Blocker
>
> I'm using that script to compile mesos[1] and it's working properly, i can
> deploy mesos master ok.
> [1] -
> https://bitbucket.org/rafaelcapucho/docker-mesos-master/src/b8709d3cbe52255f8eb5df17f79abff6b1945e95/Dockerfile?at=master=file-view-default
> The problem is when I will deploy mesos slave with the same [1] script,
> running:
> docker run rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
> It exit after couple of seconds, the log:
> root@li202-122:~# docker run -e "MESOS_LOG_DIR=/var/log/mesos"
> rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
> I0923 00:28:11.621003 1 logging.cpp:172] INFO level logging started!
> I0923 00:28:11.621363 1 main.cpp:185] Build: 2015-09-22 23:39:14 by
> I0923 00:28:11.621389 1 main.cpp:187] Version: 0.25.0
> I0923 00:28:11.621397 1 main.cpp:194] Git SHA:
> f5ec1d006794ef906e8b56861aa771888a73702f
> I0923 00:28:11.622469 1 containerizer.cpp:143] Using isolation:
> posix/cpu,posix/mem,filesystem/posix
> Failed to create a containerizer: Could not create MesosContainerizer: Failed
> to create launcher: Failed to create Linux launcher: Failed to create root
> cgroup /sys/fs/cgroup/freezer/mesos: Failed to create directory
> '/sys/fs/cgroup/freezer/mesos': Read-only file system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3498) Failed to create a containerizer
[
https://issues.apache.org/jira/browse/MESOS-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903803#comment-14903803
]
haosdent commented on MESOS-3498:
-
docker mount /sys/fs/cgroup as read-only default. Only when specify
--privileged, would mount /sys/fs/cgroup as write filesystem. And for this one
{quote}
Failed to get docker version: Failed to execute 'docker -H
unix:///var/run/docker.sock --version': exited with status 127
{quote}
Seems because your docker image not support docker in docker.
> Failed to create a containerizer
>
>
> Key: MESOS-3498
> URL: https://issues.apache.org/jira/browse/MESOS-3498
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.2
> Ubuntu 14.04.1 LTS
> User: root
> Linux li202-122 4.1.5-x86_64-linode61 #7 SMP Mon Aug 24 13:46:31 EDT 2015
> x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Rafael Capucho
>Assignee: Kapil Arya
>Priority: Blocker
>
> I'm using that script to compile mesos[1] and it's working properly, i can
> deploy mesos master ok.
> [1] -
> https://bitbucket.org/rafaelcapucho/docker-mesos-master/src/b8709d3cbe52255f8eb5df17f79abff6b1945e95/Dockerfile?at=master=file-view-default
> The problem is when I will deploy mesos slave with the same [1] script,
> running:
> docker run rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
> It exit after couple of seconds, the log:
> root@li202-122:~# docker run -e "MESOS_LOG_DIR=/var/log/mesos"
> rafa/docker-mesos-master mesos-slave --logging_level='INFO'
> --log_dir=/var/log/mesos --master="zk://173.255.192.122:2181/mesos"
> I0923 00:28:11.621003 1 logging.cpp:172] INFO level logging started!
> I0923 00:28:11.621363 1 main.cpp:185] Build: 2015-09-22 23:39:14 by
> I0923 00:28:11.621389 1 main.cpp:187] Version: 0.25.0
> I0923 00:28:11.621397 1 main.cpp:194] Git SHA:
> f5ec1d006794ef906e8b56861aa771888a73702f
> I0923 00:28:11.622469 1 containerizer.cpp:143] Using isolation:
> posix/cpu,posix/mem,filesystem/posix
> Failed to create a containerizer: Could not create MesosContainerizer: Failed
> to create launcher: Failed to create Linux launcher: Failed to create root
> cgroup /sys/fs/cgroup/freezer/mesos: Failed to create directory
> '/sys/fs/cgroup/freezer/mesos': Read-only file system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906687#comment-14906687
]
haosdent commented on MESOS-3413:
-
Maybe a bit confuse. "path1" is host_path in DockerInfo::Volume and it is the
container_path name in Resource::DiskInfo::Volumn
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker, slave
>Affects Versions: 0.23.0
>Reporter: Max Neunhöffer
>Assignee: haosdent
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For the ArangoDB framework I am trying to use the persistent primitives.
> nearly all is working, but I am missing a crucial piece at the end: I have
> successfully created a persistent disk resource and have set the persistence
> and volume information in the DiskInfo message. However, I do not see any way
> to find out what directory on the host the mesos slave has reserved for us. I
> know it is ${MESOS_SLAVE_WORKDIR}/volumes/roles//_ but we
> have no way to query this information anywhere. The docker containerizer does
> not automatically mount this directory into our docker container, or symlinks
> it into our sandbox. Therefore, I have essentially no access to it. Note that
> the mesos containerizer (which I cannot use for other reasons) seems to
> create a symlink in the sandbox to the actual path for the persistent volume.
> With that, I could mount the volume into our docker container and all would
> be well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900602#comment-14900602
]
chenqiang commented on MESOS-3079:
--
yes, got the right response, typo error maste->master.
curl http://127.0.0.1:5050/master/state.json
[root@chenqiang-master-dev001-shgq ~]# curl
http://127.0.0.1:5050/master/state.j son
{"activated_slaves":1,"build_date":"2015-09-21
11:53:53","build_time":1442807633
,"build_user":"root","completed_frameworks":[],"deactivated_slaves":0,"elected_t
ime":1442824269.81597,"flags":{"allocation_interval":"1secs","allocator":"Hierar
chicalDRF","authenticate":"false","authenticate_slaves":"false","authenticators"
:"crammd5","framework_sorter":"drf","help":"false","initialize_driver_logging":"
true","ip":"127.0.0.1","log_auto_initialize":"true","logbufsecs":"0","logging_le
vel":"INFO","max_slave_ping_timeouts":"5","port":"5050","quiet":"false","recover
y_slave_removal_limit":"100%","registry":"replicated_log","registry_fetch_timeou
t":"1mins","registry_store_timeout":"5secs","registry_strict":"false","root_subm
issions":"true","slave_ping_timeout":"15secs","slave_reregister_timeout":"10mins
","user_sorter":"drf","version":"false","webui_dir":"\/home\/chenqiang\/download
s\/mesos-0.23.0\/build\/..\/src\/webui","work_dir":"\/var\/lib\/mesos","zk_sessi
on_timeout":"10secs"},"frameworks":[],"hostname":"localhost","id":"20150921-1631
09-16777343-5050-4289","leader":"master@127.0.0.1:5050","orphan_tasks":[],"pid":
"master@127.0.0.1:5050","slaves":[{"active":true,"attributes":{},"hostname":"che
nqiang-master-dev001-shgq.qiyi.virtual","id":"20150921-130346-16777343-5050-2307
4-S0","offered_resources":{"cpus":0,"disk":0,"mem":0},"pid":"slave(1)@10.221.75.
130:5051","registered_time":1442824286.47122,"reregistered_time":1442824286.4722
9,"reserved_resources":{},"resources":{"cpus":4,"disk":31036,"mem":6845,"ports":
"[31000-32000]"},"unreserved_resources":{"cpus":4,"disk":31036,"mem":6845,"ports
":"[31000-32000]"},"used_resources":{"cpus":0,"disk":0,"mem":0}}],"start_time":1
442824269.80855,"unregistered_frameworks":[],"version":"0.23.0"}[root@chenqiang-
[root@chenqiang-master-dev001-shgq ~]#
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarc
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900494#comment-14900494
]
haosdent commented on MESOS-3079:
-
You could open http://:5050 successfully in other machine?
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900595#comment-14900595
]
chenqiang commented on MESOS-3079:
--
It returned with nothing...
What' state json playload should be got? thanks.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
>
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900489#comment-14900489
]
chenqiang commented on MESOS-3079:
--
It's there some good idea to fix the my connection issue? thanks.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::inter
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900650#comment-14900650
]
chenqiang commented on MESOS-3079:
--
I re-depolyed in CentOS 6.4, mesos-0.21.0, g++ 4.4.7.
Everything is OK, but also got the same issue that can not access via
http::5050 what's wrong??
I run the mesos in following steps:
1. login with putty, go to the mesos build dir, run:
$ ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos
2. open another putty, run:
./bin/mesos-slave.sh --master=127.0.0.1:5050
3. # Visit the mesos web page.
$ http://127.0.0.1:5050 (failed to access..., my god, what's wrong...)
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSl
[jira] [Issue Comment Deleted] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenqiang updated MESOS-3079:
-
Comment: was deleted
(was: no, can't too.)
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Issue Comment Deleted] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenqiang updated MESOS-3079:
-
Comment: was deleted
(was: no, can't too.)
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900518#comment-14900518
]
chenqiang commented on MESOS-3079:
--
no, can't too.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900516#comment-14900516
]
chenqiang commented on MESOS-3079:
--
no, can't too.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900517#comment-14900517
]
chenqiang commented on MESOS-3079:
--
no, can't too.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900563#comment-14900563
]
haosdent commented on MESOS-3079:
-
Could you "curl http://127.0.0.1:5050/help; success? And also use netstat to
make sure mesos-master is listened on 5050.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reco
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900591#comment-14900591
]
haosdent commented on MESOS-3079:
-
You aslo could curl http://127.0.0.1:5050/maste/state.json successfully?
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos
[jira] [Commented] (MESOS-3282) Web UI no longer shows Tasks information
[ https://issues.apache.org/jira/browse/MESOS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901785#comment-14901785 ] haosdent commented on MESOS-3282: - Because it is still not committed, I think it could not include in a bug fix release. > Web UI no longer shows Tasks information > > > Key: MESOS-3282 > URL: https://issues.apache.org/jira/browse/MESOS-3282 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.23.0 >Reporter: Diogo Gomes >Assignee: haosdent > Attachments: task_infomartions.png > > > After update Mesos to 0.23 the Tasks box no longer shows info. Reading the > code, seems like it depends of state.json endpoint. In 0.22.1, it's possible > to see data like "failed_tasks" and"finished_tasks" and this is not present > anymore in 0.23.0 state.json, as is required in > https://github.com/apache/mesos/blob/a0811310c82ee25644fc9a6362313ce3619e46d9/src/webui/master/static/js/controllers.js#L126 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901787#comment-14901787
]
chenqiang edited comment on MESOS-3079 at 9/22/15 2:09 AM:
---
The issue is fixed by instead of local loopback ip 127.0.0.1 with
ex.
$ ./bin/mesos-master.sh --ip=10.210.175.16 --work_dir=/var/lib/mesos
was (Author: chenqiang):
The issue is fixed by instead of local loopback ip 127.0.0.1 with
ex.
$ ./bin/mesos-master.sh --ip= --work_dir=/var/lib/mesos
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where Type
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901787#comment-14901787
]
chenqiang commented on MESOS-3079:
--
The issue is fixed by instead of local loopback ip 127.0.0.1 with
ex.
$ ./bin/mesos-master.sh --ip= --work_dir=/var/lib/mesos
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Commented] (MESOS-3488) /sys/fs/cgroup/memory/mesos missing after running a while
[ https://issues.apache.org/jira/browse/MESOS-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902244#comment-14902244 ] haosdent commented on MESOS-3488: - Hi, could you use mesos 0.24 and try again? > /sys/fs/cgroup/memory/mesos missing after running a while > - > > Key: MESOS-3488 > URL: https://issues.apache.org/jira/browse/MESOS-3488 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.21.0 > Environment: mesos 0.21.0 on CentOS 7.1 >Reporter: Chengwei Yang > > I setup mesos 0.21.0 on CentOS 7.1 with mesos-0.21.0 rpm downloaded from > mesosphere. > at first, it works fine, jobs are finished correctly, however, after running > a while, all task goes to LOST. > And there is nothing in **sandbox** and I see below from mesos-slave.ERROR > ``` > E0922 14:02:31.329264 8336 slave.cpp:2787] Container > '865c9a1c-3abe-4263-921e-8d0be2f0a56d' for executor > '21bf1400-6456-45e5-8f28-fe5ade7e7bfd' of framework > '20150401-105258-3755085578-5050-14676-' failed to start: Failed to > prepare isolator: Failed to create directory > '/sys/fs/cgroup/memory/mesos/865c9a1c-3abe-4263-921e-8d0be2f0a56d': No such > file or directory > ``` > And I checked that /sys/fs/cgroup/cpu/mesos does exist while > /sys/fs/cgroup/memory/mesos is missing. > Since at first mesos works fine (and I checked source code, that if it create > /sys/fs/cgroup/memory/mesos failed at mesos-slave startup, it will log that > error), so I'm curious when/which removed /sys/fs/cgroup/memory/mesos. > Has anyone saw this issue before? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3479) COMMAND Health Checks are not executed if the timeout is exceeded
[ https://issues.apache.org/jira/browse/MESOS-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3479: --- Assignee: haosdent > COMMAND Health Checks are not executed if the timeout is exceeded > - > > Key: MESOS-3479 > URL: https://issues.apache.org/jira/browse/MESOS-3479 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Matthias Veit >Assignee: haosdent >Priority: Critical > > The issue first appeared as Marathon Bug: See here for reference: > https://github.com/mesosphere/marathon/issues/2179. > A COMMAND health check is defined with a timeout of 20 seconds. > The command itself takes longer than 20 seconds to execute. > Current behavior: > - The mesos health check process get's killed, but the defined command > process not (in the example the curl command returns after 21 seconds). > - The check attempt is considered healthy, if the timeout is exceeded > - The health check stops and is not executed any longer > Expected behavior: > - The defined health check command is killed, when the timeout is exceeded > - The check attempt is considered Unhealthy, if the timeout is exceeded > - The health check does not stop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3479) COMMAND Health Checks are not executed if the timeout is exceeded
[
https://issues.apache.org/jira/browse/MESOS-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902646#comment-14902646
]
haosdent commented on MESOS-3479:
-
{quote}
The health check does not stop
{quote}
Do you increase the consecutive_failures in your task? After your failure times
greater than consecutive_failures, would killTask and exit healthCheck.
> COMMAND Health Checks are not executed if the timeout is exceeded
> -
>
> Key: MESOS-3479
> URL: https://issues.apache.org/jira/browse/MESOS-3479
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Matthias Veit
>Assignee: haosdent
>Priority: Critical
>
> The issue first appeared as Marathon Bug: See here for reference:
> https://github.com/mesosphere/marathon/issues/2179.
> A COMMAND health check is defined with a timeout of 20 seconds.
> The command itself takes longer than 20 seconds to execute.
> Current behavior:
> - The mesos health check process get's killed, but the defined command
> process not (in the example the curl command returns after 21 seconds).
> - The check attempt is considered healthy, if the timeout is exceeded
> - The health check stops and is not executed any longer
> Expected behavior:
> - The defined health check command is killed, when the timeout is exceeded
> - The check attempt is considered Unhealthy, if the timeout is exceeded
> - The health check does not stop
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3046) Stout's UUID re-seeds a new random generator during each call to UUID::random.
[
https://issues.apache.org/jira/browse/MESOS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805182#comment-14805182
]
haosdent commented on MESOS-3046:
-
what's your clang version? Seems work for me.
My clang version
{code}
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
{code}
Could your compiler pass this code snippet directly.
{code}
#include
#include
#include
#include
#include
#ifdef __APPLE__
#define THREAD_LOCAL __thread
#else
#define THREAD_LOCAL thread_local
#endif
struct UUID : boost::uuids::uuid
{
public:
static UUID random()
{
typedef boost::uuids::random_generator generator;
static THREAD_LOCAL generator* uuid_generator = new generator();
return UUID((*uuid_generator)());
}
private:
explicit UUID(const boost::uuids::uuid& uuid)
: boost::uuids::uuid(uuid) {}
};
int main() {
std::cout << UUID::random() << std::endl;
}
{code}
> Stout's UUID re-seeds a new random generator during each call to UUID::random.
> --
>
> Key: MESOS-3046
> URL: https://issues.apache.org/jira/browse/MESOS-3046
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Benjamin Mahler
>Assignee: Klaus Ma
> Labels: newbie, twitter
> Fix For: 0.25.0
>
> Attachments: tl.cpp
>
>
> Per [~StephanErb] and [~kevints]'s observations on MESOS-2940, stout's UUID
> abstraction is re-seeding the random generator during each call to
> {{UUID::random()}}, which is really expensive.
> This is confirmed in the perf graph from MESOS-2940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3430) LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem fails on CentOS 7.1
[
https://issues.apache.org/jira/browse/MESOS-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877168#comment-14877168
]
haosdent edited comment on MESOS-3430 at 9/19/15 3:13 PM:
--
Thanks for [~jieyu] patch. Today I read the origin document which describe the
implement shared
subtrees.https://www.kernel.org/doc/ols/2006/ols2006v2-pages-209-222.pdf and
https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
Let me try to record my understand for shared/slave mount points here. And try
to explain the behaviours above. When the filesystem we used is a shared mount
point, assume we have folder A and folder B under this filesystem. After we
execute
{code}
$ mount --bind A B
{code}
, we would have two mount subtrees and these subtrees use a same "peer group".
Event mount/unmount events under one peer of this "peer group" would sync to
other peers in this "peer group". For example, if we execute
{code}
$ mount --bind C B/c
{code}
, we could found two records in /proc/self/mountinfo.
{code}
104 38 8:3 /tmp/A /tmp/B rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
105 104 8:3 /tmp/C /tmp/B/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
106 38 8:3 /tmp/C /tmp/A/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
{code}
When mount C to B/c, it would produce a new mount event which mount C to A/c.
So that the mount points under the shared filesystem could keep same.
And when we make a mount point to slave. The mount and umount events only
propagate towards it. So when we execute
{code}
$ mount --make-slave B
$ mount --bind C B/c
{code}
, we could found only B/c become a mount point while A/c is still not a mount
point. Also it only have one new record in /proc/self/mountinfo.
And after we make a mount point to slave and make it as a shared mount point
again. It would create a new "peer group". This new "peer group" is different
which the outside shared mount. And every mount/unmount events in this new
"peer group" also which sync between every peers under this new "peer group".
According the document mentioned above, B becomes a shared-and-slave-mount now.
It would also receive mount events from its master(the outside shared mount),
share them with its peers(the new peer group).
was (Author: haosd...@gmail.com):
Thanks for [~jieyu] patch. Today I read the origin document which describe the
implement shared
subtrees.https://www.kernel.org/doc/ols/2006/ols2006v2-pages-209-222.pdf and
https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
Let me try to record my understand for shared/slave mount points here. And try
to explain the behaviours above. When the filesystem we used is a shared mount
point, assume we have folder A and folder B under this filesystem. After we
execute
{code}
$ mount --bind A B
{code}
, we would have two mount subtrees and these subtrees use a same "peer group".
Event mount/unmount events under one peer of this "peer group" would sync to
other peers in this "peer group". For example, if we execute
{code}
$ mount --bind C B/c
{code}
, we could found two records in /proc/self/mountinfo.
{code}
104 38 8:3 /tmp/A /tmp/B rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
105 104 8:3 /tmp/C /tmp/B/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
106 38 8:3 /tmp/C /tmp/A/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
{code}
When mount C to B/c, it would produce a new mount event which mount C to A/c.
So that the mount points under the shared filesystem could keep same.
And when we make a mount point to slave. The mount and umount events only
propagate towards it. So when we execute
{code}
$ mount --make-slave B
$ mount --bind C B/c
{code}
, we could found only B/c become a mount point while A/c is still not a mount
point. Also it only have one new record in /proc/self/mountinfo.
And after we make a mount point to slave and make it as a shared mount point
again. It would create a new "peer group". This new "peer group" is different
which the outside shared mount. And every mount/unmount events in this new
"peer group" also which sync between every "peer". According the document
mentioned above, B becomes a shared-and-slave-mount. It would also receive
mount events from its master(the outside shared mount), share them with its
peers(the new peer group).
> LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem fails
> on CentOS 7.1
> ------
>
> Key: MESOS-3430
> URL: https://issues.apache.org/jira/browse/MESOS-3
[jira] [Commented] (MESOS-3430) LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem fails on CentOS 7.1
[
https://issues.apache.org/jira/browse/MESOS-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14877168#comment-14877168
]
haosdent commented on MESOS-3430:
-
Thanks for [~jieyu] patch. Today I read the origin document which describe the
implement shared
subtrees.https://www.kernel.org/doc/ols/2006/ols2006v2-pages-209-222.pdf and
https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
Let me try to record my understand for shared/slave mount points here. And try
to explain the behaviours above. When the filesystem we used is a shared mount
point, assume we have folder A and folder B under this filesystem. After we
execute
{code}
$ mount --bind A B
{code}
, we would have two mount subtrees and these subtrees use a same "peer group".
Event mount/unmount events under one peer of this "peer group" would sync to
other peers in this "peer group". For example, if we execute
{code}
$ mount --bind C B/c
{code}
, we could found two records in /proc/self/mountinfo.
{code}
104 38 8:3 /tmp/A /tmp/B rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
105 104 8:3 /tmp/C /tmp/B/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
106 38 8:3 /tmp/C /tmp/A/c rw,relatime shared:1 - xfs /dev/sda3
rw,seclabel,attr2,inode64,noquota
{code}
When mount C to B/c, it would produce a new mount event which mount C to A/c.
So that the mount points under the shared filesystem could keep same.
And when we make a mount point to slave. The mount and umount events only
propagate towards it. So when we execute
{code}
$ mount --make-slave B
$ mount --bind C B/c
{code}
, we could found only B/c become a mount point while A/c is still not a mount
point. Also it only have one new record in /proc/self/mountinfo.
And after we make a mount point to slave and make it as a shared mount point
again. It would create a new "peer group". This new "peer group" is different
which the outside shared mount. And every mount/unmount events in this new
"peer group" also which sync between every "peer". According the document
mentioned above, B becomes a shared-and-slave-mount. It would also receive
mount events from its master(the outside shared mount), share them with its
peers(the new peer group).
> LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem fails
> on CentOS 7.1
> --
>
> Key: MESOS-3430
> URL: https://issues.apache.org/jira/browse/MESOS-3430
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.25.0
>Reporter: Marco Massenzio
>Assignee: Jie Yu
> Labels: ROOT_Tests, flaky-test
> Attachments: verbose.log
>
>
> Just ran ROOT tests on CentOS 7.1 and had the following failure (clean build,
> just pulled from {{master}}):
> {noformat}
> [ RUN ]
> LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:498: Failure
> (wait).failure(): Failed to clean up an isolator when destroying container
> '366b6d37-b326-4ed1-8a5f-43d483dbbace' :Failed to unmount volume
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_PersistentVolumeWithoutRootFilesystem_KXgvoH/sandbox/volume':
> Failed to unmount
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_PersistentVolumeWithoutRootFilesystem_KXgvoH/sandbox/volume':
> Invalid argument
> ../../src/tests/utils.cpp:75: Failure
> os::rmdir(sandbox.get()): Device or resource busy
> [ FAILED ]
> LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem (1943
> ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (1943 ms total)
> [--] Global test environment tear-down
> [==] 1 test from 1 test case ran. (1951 ms total)
> [ PASSED ] 0 tests.
> [ FAILED ] 1 test, listed below:
> [ FAILED ]
> LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3046) Stout's UUID re-seeds a new random generator during each call to UUID::random.
[
https://issues.apache.org/jira/browse/MESOS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14805247#comment-14805247
]
haosdent commented on MESOS-3046:
-
A patch to fix the compile error: https://reviews.apache.org/r/38481/
> Stout's UUID re-seeds a new random generator during each call to UUID::random.
> --
>
> Key: MESOS-3046
> URL: https://issues.apache.org/jira/browse/MESOS-3046
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Benjamin Mahler
>Assignee: Klaus Ma
> Labels: newbie, twitter
> Fix For: 0.25.0
>
> Attachments: tl.cpp
>
>
> Per [~StephanErb] and [~kevints]'s observations on MESOS-2940, stout's UUID
> abstraction is re-seeding the random generator during each call to
> {{UUID::random()}}, which is really expensive.
> This is confirmed in the perf graph from MESOS-2940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3483) LinuxFilesystemIsolator should make the slave's work_dir a shared mount.
[
https://issues.apache.org/jira/browse/MESOS-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901125#comment-14901125
]
haosdent commented on MESOS-3483:
-
Could use http://asciiflow.com/ :-)
> LinuxFilesystemIsolator should make the slave's work_dir a shared mount.
>
>
> Key: MESOS-3483
> URL: https://issues.apache.org/jira/browse/MESOS-3483
> Project: Mesos
> Issue Type: Bug
>Reporter: Jie Yu
>
> So that when a user task is forked, it does not hold extra references to the
> sandbox mount and provisioner bind backend mounts. If we don't do that, we
> could get the following error message when cleaning up bind backend mount
> points and sandbox mount points.
> {noformat}
> E0921 17:35:57.268159 47010 bind.cpp:182] Failed to remove rootfs mount point
> '/var/lib/mesos/provisioner/containers/07eb6660-25ff-4e83-8b2f-06955567e04a/backends/bind/rootfses/30f7e5e2-55d0-4d4d-a662-f8aad0d56b33':
> Device or resource busy
> E0921 17:35:57.268349 47010 provisioner.cpp:403] Failed to remove the
> provisioned container directory at
> '/var/lib/mesos/provisioner/containers/07eb6660-25ff-4e83-8b2f-06955567e04a':
> Device or resource busy
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3483) LinuxFilesystemIsolator should make the slave's work_dir a shared mount.
[ https://issues.apache.org/jira/browse/MESOS-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901122#comment-14901122 ] haosdent commented on MESOS-3483: - Seems the description is not complete? > LinuxFilesystemIsolator should make the slave's work_dir a shared mount. > > > Key: MESOS-3483 > URL: https://issues.apache.org/jira/browse/MESOS-3483 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu > > So that when a user task is forked, it does not hold extra references to the > sandbox mount and provisioner bind backend mounts. If we don't do that, we > could get the following error message when cleaning up bind backend mount > points and sandbox mount points. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3482) Compile fails with -Duser.home option set.
[
https://issues.apache.org/jira/browse/MESOS-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900981#comment-14900981
]
haosdent commented on MESOS-3482:
-
According this link,
http://stackoverflow.com/questions/11683715/suppressing-the-picked-up-java-options-message
and
http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/hotspot/src/share/vm/runtime/arguments.cpp.html
Seems when current user is not root and set up _JAVA_OPTIONS, would print this
error.
{code}
2489 if (os::getenv(name, buffer, sizeof(buffer)) &&
2490 !os::have_special_privileges()) {
2491 JavaVMOption options[N_MAX_OPTIONS]; // Construct option array
2492 jio_fprintf(defaultStream::error_stream(),
2493 "Picked up %s: %s\n", name, buffer);
{code}
> Compile fails with -Duser.home option set.
> --
>
> Key: MESOS-3482
> URL: https://issues.apache.org/jira/browse/MESOS-3482
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.24.0
> Environment: OS X 10.11, MacBook Pro Mid-2012, Clang-700.0.72
>Reporter: Dominyk Tiller
> Labels: build
>
> Apologies in advance; I'm not sure if this is technically your bug or a bug
> with the upstream javadoc plugin.
> I'm trying to sandbox the Mesos installation so the downloaded
> plugins/jars/etc needed by Maven for installation aren't retained after the
> build, as otherwise they get dumped in "$HOME/.m2". To achieve this I've
> exported:
> {noformat}
> _JAVA_OPTIONS=-Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> {noformat}
> This causes the following build failure:
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 02:48 min
> [INFO] Finished at: 2015-09-21T15:24:14+01:00
> [INFO] Final Memory: 29M/242M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:
> [ERROR] Exit code: 1 - Picked up _JAVA_OPTIONS:
> -Duser.home=/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/.brew_home
> [ERROR] javadoc: error - No packages or classes specified.
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/javadoc
> @options
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/private/tmp/mesos20150921-21602-19h9jrr/mesos-0.24.0/src/java/target/apidocs'
> dir.
> {noformat}
> Can confirm without setting that variable, the build is fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900435#comment-14900435
]
haosdent commented on MESOS-3079:
-
Could you telnet to 127.0.0.1 5050 in mesos master machine?
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::inter
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900436#comment-14900436
]
haosdent commented on MESOS-3079:
-
You could ignore this failed tests.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900440#comment-14900440
]
chenqiang commented on MESOS-3079:
--
[root@chenqiang-master-dev001-shgq ~]# telnet 127.0.0.1 5050
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900443#comment-14900443
]
chenqiang commented on MESOS-3079:
--
OK, it means those are not the root cause that made me can't access to
http:127.0.0.1:5050
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
>
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900446#comment-14900446
]
chenqiang commented on MESOS-3079:
--
BTW, I logged in my windows side from the master IP, with
http://:5050, I'm sure it can't be the cause for this issue, thanks.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900445#comment-14900445
]
chenqiang commented on MESOS-3079:
--
BTW, I logged in my windows side from the master IP, with
http://:5050, I'm sure it can't be the cause for this issue, thanks.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveReco
[jira] [Issue Comment Deleted] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenqiang updated MESOS-3079:
-
Comment: was deleted
(was: BTW, I logged in my windows side from the master IP, with
http://:5050, I'm sure it can't be the cause for this issue, thanks.)
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reconcile
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900572#comment-14900572
]
chenqiang commented on MESOS-3079:
--
selinux also closed.
[root@chenqiang-master-dev001-shgq yum.repos.d]# setenforce 0
[root@chenqiang-master-dev001-shgq yum.repos.d]# getenforce
Permissive
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FA
[jira] [Assigned] (MESOS-3471) Disable perf test when perf version is not support
[
https://issues.apache.org/jira/browse/MESOS-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3471:
---
Assignee: haosdent
> Disable perf test when perf version is not support
> --
>
> Key: MESOS-3471
> URL: https://issues.apache.org/jira/browse/MESOS-3471
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
>
> Now we depends perf 2.6.39 in our tests. But we detect should support perf or
> not through "perf help" status code. Need change to use
> {code}
> perf::supported()
> {code}
> to detect, so the distcheck could pass on CentOS 6.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3473) CgroupsAnyHierarchyMemoryPressureTest failed on CentOS 6.6
haosdent created MESOS-3473: --- Summary: CgroupsAnyHierarchyMemoryPressureTest failed on CentOS 6.6 Key: MESOS-3473 URL: https://issues.apache.org/jira/browse/MESOS-3473 Project: Mesos Issue Type: Bug Reporter: haosdent CgroupsAnyHierarchyMemoryPressureTest failed on CentOS.6 because of memory.pressure_level not exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[ https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900417#comment-14900417 ] chenqiang commented on MESOS-3079: -- my fails listed below, thanks. [==] 713 tests from 117 test cases ran. (301085 ms total) [ PASSED ] 676 tests. [ FAILED ] 37 tests, listed below: [ FAILED ] PerfTest.ROOT_SamplePid [ FAILED ] CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy [ FAILED ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf [ FAILED ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS [ FAILED ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreasePageCache [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.SchedulerFailover, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.PartitionedSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MasterFailover, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MultipleFrameworks, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MultipleSlaves, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RestartBeforeContainerizerLaunch, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] MesosContainerizerSlaveRecoveryTest.ResourceStatistics [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceForward [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceBackward [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample [ FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess [ FAILED ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess 37 FAILED TESTS YOU HAVE 12 DISABLED TESTS I0921 14:01:07.216980 29337 exec.cpp:452] Slave exited, but framework has checkpointing enabled. Waiting 15mins to reconnect with slave 20150921-135826-2186009866-44268-27222-S0 make[3]: *** [check-local] Error 1 make[3]: Leaving directory `/home/chenqiang/downloads/mesos-0.23.0/build/src' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/chenqiang/downloads/mesos-0.23.0/build/src' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/chenqiang/downloads/mesos-0.23.0/build/src' make: *** [check-recursive] Error 1 > `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900394#comment-14900394
]
haosdent commented on MESOS-3079:
-
Which version are you used? master branch or 0.24? And what is your operation
system?
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where
>
[jira] [Commented] (MESOS-3079) `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
[
https://issues.apache.org/jira/browse/MESOS-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900397#comment-14900397
]
chenqiang commented on MESOS-3079:
--
Hi haosdent,
Thanks for your quick response.
I use the centos 6.4 x86_64, mesos0.23.0, g++ 4.8.1
I checked that the 5050 port is in listen and establish status.
-
In mesos-master side, I saw following msg:
I0921 16:31:26.478057 4309 hierarchical.hpp:588] Slave
20150921-130346-16777343-5050-23074-S0 (my-vm) updated with oversubscribed
resources (total: cpus(*):4; mem(*):6845; disk(*):31036;
ports(*):[31000-32000], allocated: )
and in mesos-slave side,
I0921 16:59:11.596024 4340 slave.cpp:4179] Querying resource estimator for
oversubscribable resources
I0921 16:59:11.596247 4340 slave.cpp:4193] Received oversubscribable resources
from the resource estimator
Thanks.
> `sudo make distcheck` fails on Ubuntu 14.04 (and possibly other OSes too)
> -
>
> Key: MESOS-3079
> URL: https://issues.apache.org/jira/browse/MESOS-3079
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
>Priority: Blocker
> Labels: mesosphere, tests
> Fix For: 0.24.0
>
> Attachments: test-results.log
>
>
> Running tests as root causes a large number of failures.
> {noformat}
> $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.2 LTS
> Release:14.04
> Codename: trusty
> $ sudo make -j12 V=0 check
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [ PASSED ] 676 tests.
> [ FAILED ] 36 tests, listed below:
> [ FAILED ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [ FAILED ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [ FAILED ] SlaveRecoveryTest/0.Shutd
[jira] [Assigned] (MESOS-3567) Support TCP checks in Mesos health check program
[ https://issues.apache.org/jira/browse/MESOS-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3567: --- Assignee: haosdent > Support TCP checks in Mesos health check program > > > Key: MESOS-3567 > URL: https://issues.apache.org/jira/browse/MESOS-3567 > Project: Mesos > Issue Type: Improvement >Reporter: Matthias Veit >Assignee: haosdent > Labels: Mesosphere > > In Marathon we have the ability to specify Health Checks for: > - Command (Mesos supports this) > - HTTP (see progress in MESOS-2533) > - TCP missing > See here for reference: > https://mesosphere.github.io/marathon/docs/health-checks.html > Since we made good experiences with those 3 options in Marathon, I see a lot > of value, if Mesos would also support them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3567) Support TCP checks in Mesos health check program
[
https://issues.apache.org/jira/browse/MESOS-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943187#comment-14943187
]
haosdent commented on MESOS-3567:
-
Before we support tcp check, user could use
{code}
nc -z host port
{code}
to check tcp port first.
> Support TCP checks in Mesos health check program
>
>
> Key: MESOS-3567
> URL: https://issues.apache.org/jira/browse/MESOS-3567
> Project: Mesos
> Issue Type: Improvement
>Reporter: Matthias Veit
> Labels: Mesosphere
>
> In Marathon we have the ability to specify Health Checks for:
> - Command (Mesos supports this)
> - HTTP (see progress in MESOS-2533)
> - TCP missing
> See here for reference:
> https://mesosphere.github.io/marathon/docs/health-checks.html
> Since we made good experiences with those 3 options in Marathon, I see a lot
> of value, if Mesos would also support them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3392) Enhanced option for Docker cli volume plugin
[
https://issues.apache.org/jira/browse/MESOS-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945305#comment-14945305
]
haosdent commented on MESOS-3392:
-
If you really need it, feel free to download it from
https://reviews.apache.org/r/38338/diff/raw/ and patch it directly.
> Enhanced option for Docker cli volume plugin
>
>
> Key: MESOS-3392
> URL: https://issues.apache.org/jira/browse/MESOS-3392
> Project: Mesos
> Issue Type: Improvement
> Components: docker, slave
>Affects Versions: 0.25.0
> Environment: Docker containers
>Reporter: Vaibhav Khanduja
>Assignee: haosdent
>Priority: Minor
>
> Docker with 1.8 started to support volume plugin
> (http://blog.docker.com/2015/06/extending-docker-with-plugins/) . This
> support has enhanced cli for option "volume", where in an non-absolute name
> of the volume can be provided. The name is passed by Docker daemon to backed
> plugin in return for a mount point or absolute path of the volume.
> The code in src/docker.cpp, for each volume provided it checks for the host
> path which in above case if not starting with "/" gets prefixed with
> "sandbox" location on the host. This breaks the volume plugin integration.
> The only option now is to pass volume name as another key value parameter.
> The code in docker.cpp:
>
> if (volume.has_host_path()) {
> if (!strings::startsWith(volume.host_path(), "/")) {
> // Support mapping relative paths from the sandbox.
> volumeConfig =
> path::join(sandboxDirectory, volume.host_path()) + ":" +
> volumeConfig;
> } else {
> volumeConfig = volume.host_path() + ":" + volumeConfig;
> }
> ...
> should probably be enhanced to check if volume plugin option is provided and
> pass on the parameter provided to the plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4024) HealthCheckTest.CheckCommandTimeout flaky
[ https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-4024: Attachment: HealthCheckTest_CheckCommandTimeout.log > HealthCheckTest.CheckCommandTimeout flaky > - > > Key: MESOS-4024 > URL: https://issues.apache.org/jira/browse/MESOS-4024 > Project: Mesos > Issue Type: Bug >Reporter: haosdent >Assignee: haosdent > Attachments: HealthCheckTest_CheckCommandTimeout.log > > > https://builds.apache.org/job/Mesos/1288/COMPILER=gcc,CONFIGURATION=--verbose,OS=ubuntu:14.04,label_exp=docker%7C%7CHadoop/consoleText -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4027) Improve task-node affinity
[ https://issues.apache.org/jira/browse/MESOS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris updated MESOS-4027: - Summary: Improve task-node affinity (was: Improve task-node affinit) > Improve task-node affinity > -- > > Key: MESOS-4027 > URL: https://issues.apache.org/jira/browse/MESOS-4027 > Project: Mesos > Issue Type: Wish > Components: allocation, general >Reporter: Chris >Priority: Trivial > > Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs > on a node currently running hdfs or to avoid running Ceph on HDFS nodes). > Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a > Framework Scheduler) that can describe what a Task is running. > The Attribute would propagate to a Task at execution. The Attribute is > passed to Framework Schedulers as part of an Offer's Attributes list. > A Framework Scheduler could then filter out or accept Offers from Nodes that > are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4027) Improve task-node affinit
Chris created MESOS-4027: Summary: Improve task-node affinit Key: MESOS-4027 URL: https://issues.apache.org/jira/browse/MESOS-4027 Project: Mesos Issue Type: Wish Components: allocation, general Reporter: Chris Priority: Trivial Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs on a node currently running hdfs or to avoid running Ceph on HDFS nodes). Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a Framework Scheduler) that can describe what a Task is running. The Attribute would propagate to a Task at execution. The Attribute is passed to Framework Schedulers as part of an Offer's Attributes list. A Framework Scheduler could then filter out or accept Offers from Nodes that are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4027) Improve task-node affinity
[ https://issues.apache.org/jira/browse/MESOS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15032577#comment-15032577 ] Chris edited comment on MESOS-4027 at 11/30/15 10:04 PM: - I've developed a patch in support of this ticket (it's been pushed to my github mesos fork). The patch requires testing (among other things!) before submitting for review. was (Author: ct.clmsn): I've developed a patch in support of this ticket (it's been pushed to my github mesos fork). The patch requires testing (among other things - ie: a Shepard) before submitting for review. > Improve task-node affinity > -- > > Key: MESOS-4027 > URL: https://issues.apache.org/jira/browse/MESOS-4027 > Project: Mesos > Issue Type: Wish > Components: allocation, general >Reporter: Chris >Priority: Trivial > > Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs > on a node currently running hdfs or to avoid running Ceph on HDFS nodes). > Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a > Framework Scheduler) that can describe what a Task is running. > The Attribute would propagate to a Task at execution. The Attribute is > passed to Framework Schedulers as part of an Offer's Attributes list. > A Framework Scheduler could then filter out or accept Offers from Nodes that > are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4027) Improve task-node affinity
[ https://issues.apache.org/jira/browse/MESOS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15032577#comment-15032577 ] Chris commented on MESOS-4027: -- I've developed a patch for in support of this ticket. The patch requires testing (among other things - ie: a Shepard) before submitting for review. > Improve task-node affinity > -- > > Key: MESOS-4027 > URL: https://issues.apache.org/jira/browse/MESOS-4027 > Project: Mesos > Issue Type: Wish > Components: allocation, general >Reporter: Chris >Priority: Trivial > > Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs > on a node currently running hdfs or to avoid running Ceph on HDFS nodes). > Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a > Framework Scheduler) that can describe what a Task is running. > The Attribute would propagate to a Task at execution. The Attribute is > passed to Framework Schedulers as part of an Offer's Attributes list. > A Framework Scheduler could then filter out or accept Offers from Nodes that > are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4027) Improve task-node affinity
[ https://issues.apache.org/jira/browse/MESOS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15032577#comment-15032577 ] Chris edited comment on MESOS-4027 at 11/30/15 10:04 PM: - I've developed a patch in support of this ticket (it's been pushed to my github mesos fork). The patch requires testing (among other things - ie: a Shepard) before submitting for review. was (Author: ct.clmsn): I've developed a patch for in support of this ticket. The patch requires testing (among other things - ie: a Shepard) before submitting for review. > Improve task-node affinity > -- > > Key: MESOS-4027 > URL: https://issues.apache.org/jira/browse/MESOS-4027 > Project: Mesos > Issue Type: Wish > Components: allocation, general >Reporter: Chris >Priority: Trivial > > Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs > on a node currently running hdfs or to avoid running Ceph on HDFS nodes). > Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a > Framework Scheduler) that can describe what a Task is running. > The Attribute would propagate to a Task at execution. The Attribute is > passed to Framework Schedulers as part of an Offer's Attributes list. > A Framework Scheduler could then filter out or accept Offers from Nodes that > are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15040775#comment-15040775
]
haosdent commented on MESOS-4024:
-
Sorry for the dalay, I would try to investigate this at this weekend.
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:03:15.293392 30318 replica.cpp:674] Replica in STARTING status
> received a broadcasted recover request from (1900)@172.17.21.0:52024
> I1201 13:03:15.294251 30307 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I120
[jira] [Issue Comment Deleted] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-4024:
Comment: was deleted
(was: Sorry for the dalay, I would try to investigate this at this weekend.)
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:03:15.293392 30318 replica.cpp:674] Replica in STARTING status
> received a broadcasted recover request from (1900)@172.17.21.0:52024
> I1201 13:03:15.294251 30307 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I1201 13:03:15.2
[jira] [Commented] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15040774#comment-15040774
]
haosdent commented on MESOS-4024:
-
Sorry for the dalay, I would try to investigate this at this weekend.
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:03:15.293392 30318 replica.cpp:674] Replica in STARTING status
> received a broadcasted recover request from (1900)@172.17.21.0:52024
> I1201 13:03:15.294251 30307 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I120
[jira] [Commented] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15039716#comment-15039716
]
haosdent commented on MESOS-4024:
-
Yes, the "HealthCheckTest_CheckCommandTimeout.log" in attachments is the plain
text log I copy from jenkins at that time.
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:03:15.293392 30318 replica.cpp:674] Replica in STARTING status
> received a broadcasted recover request from (1900)@172.17.21.0:52024
> I1201 13:03:15.294251 30307 recover.cpp:193] Received a recove
[jira] [Commented] (MESOS-3738) Mesos health check is invoked incorrectly when Mesos slave is within the docker container
[
https://issues.apache.org/jira/browse/MESOS-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049014#comment-15049014
]
haosdent commented on MESOS-3738:
-
Hi, you need patch
https://issues.apache.org/jira/secure/attachment/12766990/MESOS-3738-0_23_1.patch
which I upload in attachments.
> Mesos health check is invoked incorrectly when Mesos slave is within the
> docker container
> -
>
> Key: MESOS-3738
> URL: https://issues.apache.org/jira/browse/MESOS-3738
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.25.0
> Environment: Docker 1.8.0:
> Client:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Server:
> Version: 1.8.0
> API version: 1.20
> Go version: go1.4.2
> Git commit: 0d03096
> Built:Tue Aug 11 16:48:39 UTC 2015
> OS/Arch: linux/amd64
> Host: Ubuntu 14.04
> Container: Debian 8.1 + Java-7
>Reporter: Yong Tang
>Assignee: haosdent
> Fix For: 0.26.0
>
> Attachments: MESOS-3738-0_23_1.patch, MESOS-3738-0_24_1.patch,
> MESOS-3738-0_25_0.patch
>
>
> When Mesos slave is within the container, the COMMAND health check from
> Marathon is invoked incorrectly.
> In such a scenario, the sandbox directory (instead of the
> launcher/health-check directory) is used. This result in an error with the
> container.
> Command to invoke the Mesos slave container:
> {noformat}
> sudo docker run -d -v /sys:/sys -v /usr/bin/docker:/usr/bin/docker:ro -v
> /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/usr/lib/x86_64-linux-gnu/libapparmor.so.1:ro
> -v /var/run/docker.sock:/var/run/docker.sock -v /tmp/mesos:/tmp/mesos mesos
> mesos slave --master=zk://10.2.1.2:2181/mesos --containerizers=docker,mesos
> --executor_registration_timeout=5mins --docker_stop_timeout=10secs
> --launcher=posix
> {noformat}
> Marathon JSON file:
> {code}
> {
> "id": "ubuntu",
> "container":
> {
> "type": "DOCKER",
> "docker":
> {
> "image": "ubuntu",
> "network": "BRIDGE",
> "parameters": []
> }
> },
> "args": [ "bash", "-c", "while true; do echo 1; sleep 5; done" ],
> "uris": [],
> "healthChecks":
> [
> {
> "protocol": "COMMAND",
> "command": { "value": "echo Success" },
> "gracePeriodSeconds": 3000,
> "intervalSeconds": 5,
> "timeoutSeconds": 5,
> "maxConsecutiveFailures": 300
> }
> ],
> "instances": 1
> }
> {code}
> {noformat}
> STDOUT:
> root@cea2be47d64f:/mnt/mesos/sandbox# cat stdout
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> --container="mesos-e20f8959-cd9f-40ae-987d-809401309361-S0.815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --docker="docker" --docker_socket="/var/run/docker.sock" --help="false"
> --initialize_driver_logging="true" --logbufsecs="0" --logging_level="INFO"
> --mapped_directory="/mnt/mesos/sandbox" --quiet="false"
> --sandbox_directory="/tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-809401309361-S0/frameworks/e20f8959-cd9f-40ae-987d-809401309361-/executors/ubuntu.86bca10f-72c9-11e5-b36d-02420a020106/runs/815cc886-1cd1-4f13-8f9b-54af1f127c3f"
> --stop_timeout="10secs"
> Registered docker executor on b01e2e75afcb
> Starting task ubuntu.86bca10f-72c9-11e5-b36d-02420a020106
> 1
> Launching health check process:
> /tmp/mesos/slaves/e20f8959-cd9f-40ae-987d-80940130936
[jira] [Commented] (MESOS-4106) The health checker may fail to inform the executor to kill an unhealthy task after max_consecutive_failures.
[
https://issues.apache.org/jira/browse/MESOS-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049824#comment-15049824
]
haosdent commented on MESOS-4106:
-
Does add ' os::sleep(Seconds(1));' enough?
> The health checker may fail to inform the executor to kill an unhealthy task
> after max_consecutive_failures.
>
>
> Key: MESOS-4106
> URL: https://issues.apache.org/jira/browse/MESOS-4106
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.20.0, 0.20.1, 0.21.1, 0.21.2, 0.22.1, 0.22.2, 0.23.0,
> 0.23.1, 0.24.0, 0.24.1, 0.25.0
>Reporter: Benjamin Mahler
>Priority: Blocker
>
> This was reported by [~tan] experimenting with health checks. Many tasks were
> launched with the following health check, taken from the container
> stdout/stderr:
> {code}
> Launching health check process: /usr/local/libexec/mesos/mesos-health-check
> --executor=(1)@127.0.0.1:39629
> --health_check_json={"command":{"shell":true,"value":"false"},"consecutive_failures":1,"delay_seconds":0.0,"grace_period_seconds":1.0,"interval_seconds":1.0,"timeout_seconds":1.0}
> --task_id=sleepy-2
> {code}
> This should have led to all tasks getting killed due to
> {{\-\-consecutive_failures}} being set, however, only some tasks get killed,
> while other remain running.
> It turns out that the health check binary does a {{send}} and promptly exits.
> Unfortunately, this may lead to a message drop since libprocess may not have
> sent this message over the socket by the time the process exits.
> We work around this in the command executor with a manual sleep, which has
> been around since the svn days. See
> [here|https://github.com/apache/mesos/blob/0.14.0/src/launcher/executor.cpp#L288-L290].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4027) Improve task-node affinity
[ https://issues.apache.org/jira/browse/MESOS-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052902#comment-15052902 ] Chris commented on MESOS-4027: -- [~qianzhang] just noticed that - really should have spent more time reviewing the documentation in the protobuf file. I'd like to see the Task's labels field get propogated into an Offer so customized schedulers can have some view into what is running on a Mesos Node (ie: scheduler logic may filter out Offers associated with Nodes involved in Spark processing OR maybe schedulers want to filter out Offers that are not associated with HDFS). Figured out a way to do this without added more fields into the protobuf IDL for TaskInfo. Thanks for pointing this out!!! > Improve task-node affinity > -- > > Key: MESOS-4027 > URL: https://issues.apache.org/jira/browse/MESOS-4027 > Project: Mesos > Issue Type: Wish > Components: allocation, general >Reporter: Chris >Priority: Trivial > > Improve task-to-node affinity and anti-affinity (running hadoop or spark jobs > on a node currently running hdfs or to avoid running Ceph on HDFS nodes). > Provide a user-mutable Attribute in TaskInfo (the Attribute is modified by a > Framework Scheduler) that can describe what a Task is running. > The Attribute would propagate to a Task at execution. The Attribute is > passed to Framework Schedulers as part of an Offer's Attributes list. > A Framework Scheduler could then filter out or accept Offers from Nodes that > are currently labeled with a desired set or individual Attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4173) HealthCheckTest.CheckCommandTimeout is slow
[
https://issues.apache.org/jira/browse/MESOS-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058468#comment-15058468
]
haosdent commented on MESOS-4173:
-
[~tnachen]] have a patch to fix this. https://reviews.apache.org/r/40956/
> HealthCheckTest.CheckCommandTimeout is slow
> ---
>
> Key: MESOS-4173
> URL: https://issues.apache.org/jira/browse/MESOS-4173
> Project: Mesos
> Issue Type: Improvement
> Components: technical debt, test
>Reporter: Alexander Rukletsov
>Priority: Minor
> Labels: mesosphere, newbie++, tech-debt
>
> The {{HealthCheckTest.CheckCommandTimeout}} test takes more than {{15s}}! to
> finish on my Mac OS 10.10.4:
> {code}
> HealthCheckTest.CheckCommandTimeout (15483 ms)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3709) Modulize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3709: --- Assignee: haosdent > Modulize the containerizer interface. > - > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: haosdent > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3709) Modulize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054827#comment-15054827 ] haosdent commented on MESOS-3709: - I think I could try implement this. :-) > Modulize the containerizer interface. > - > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: haosdent > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055909#comment-15055909 ] Zogg commented on MESOS-3842: - I'v ran on vagrant bento/centos 7.1 box and it still has the same issue. > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4133) User-oriented docs for containerizers + isolators
[ https://issues.apache.org/jira/browse/MESOS-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056060#comment-15056060 ] andyhu commented on MESOS-4133: --- Great, this will benefit who are not familiar with container related technology > User-oriented docs for containerizers + isolators > - > > Key: MESOS-4133 > URL: https://issues.apache.org/jira/browse/MESOS-4133 > Project: Mesos > Issue Type: Documentation > Components: containerization, documentation, isolation >Reporter: Neil Conway > Labels: documentation, mesosphere > > This should cover practical user-oriented questions, such as: > * what is a containerizer, and what problems do they solve? > * how should I choose among the available containerizer options to solve a > few typical, practical problems > * what is an isolator, and what problems do they solve? > * how should I choose among the available isolator options to solve a few > typical, practical problems > We could possibly get into the details of cgroups and other system-level > facilities for configuring resource isolation as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2210) Disallow special characters in role.
[
https://issues.apache.org/jira/browse/MESOS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055460#comment-15055460
]
haosdent commented on MESOS-2210:
-
{noformat}
if (role == ".") {
return Error("Role name '.' is invalid.");
} else if (role == "..") {
return Error("Role name '..' is invalid.");
} else if (strings::startsWith(role, "-")) {
return Error("Role name '" + role + "' is invalid "
"because it starts with a dash.");
}
// \x09 is horizontal tab (whitespace);
// \x0a is line feed (whitespace);
// \x0b is vertical tab (whitespace);
// \x0c is form feed (whitespace);
// \x0d is carriage return (whitespace);
// \x20 is space (whitespace);
// \x2f is slash ('/');
// \x7f is backspace (del);
{noformat}
> Disallow special characters in role.
>
>
> Key: MESOS-2210
> URL: https://issues.apache.org/jira/browse/MESOS-2210
> Project: Mesos
> Issue Type: Task
>Reporter: Jie Yu
>Assignee: haosdent
> Labels: mesosphere, newbie, persistent-volumes
>
> As we introduce persistent volumes in MESOS-1524, we will use roles as
> directory names on the slave (https://reviews.apache.org/r/28562/). As a
> result, the master should disallow special characters (like space and slash)
> in role.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4141) Allow DockerContainerizer log to console
haosdent created MESOS-4141: --- Summary: Allow DockerContainerizer log to console Key: MESOS-4141 URL: https://issues.apache.org/jira/browse/MESOS-4141 Project: Mesos Issue Type: Improvement Reporter: haosdent Assignee: haosdent MesosContainerizer support pass `local` parameter to make executor log to stdout/stderr. To add similar parameter to DockerContainerizer is also helpful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4113) Docker Executor should not set container IP during bridged mode
[ https://issues.apache.org/jira/browse/MESOS-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054422#comment-15054422 ] haosdent commented on MESOS-4113: - Framework should know task network mode, right? So for framework developers, could ignore it when don't need it. And I think fill ip_address in TaskStatus also necessary although container in bridge mode. In some cases, for example, if user want to add containers ip to iptables in framework, so that user could get the NAT ip of container through TaskStatus. > Docker Executor should not set container IP during bridged mode > --- > > Key: MESOS-4113 > URL: https://issues.apache.org/jira/browse/MESOS-4113 > Project: Mesos > Issue Type: Bug > Components: docker >Affects Versions: 0.25.0, 0.26.0 >Reporter: Sargun Dhillon > Labels: mesosphere > > The docker executor currently sets the IP address of the container into > ContainerStatus.NetworkInfo.IPAddresses. This isn't a good thing, because > during bridged mode execution, it makes it so that that IP address is > useless, since it's behind the Docker NAT. I would like a flag that disables > filling the IP address in, and allows it to fall back to the agent IP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2210) Disallow special characters in role.
[ https://issues.apache.org/jira/browse/MESOS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054340#comment-15054340 ] haosdent commented on MESOS-2210: - Thank you very much for you and [~greggomann] helpful reviews. Sorry update so late... > Disallow special characters in role. > > > Key: MESOS-2210 > URL: https://issues.apache.org/jira/browse/MESOS-2210 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: haosdent > Labels: mesosphere, newbie, persistent-volumes > > As we introduce persistent volumes in MESOS-1524, we will use roles as > directory names on the slave (https://reviews.apache.org/r/28562/). As a > result, the master should disallow special characters (like space and slash) > in role. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051350#comment-15051350
]
haosdent commented on MESOS-4024:
-
Could I change
{noformat}
Try<MesosContainerizer*> containerizer =
MesosContainerizer::create(flags, false, );
{noformat}
to local in HealthCheckTest.CheckCommandTimeout?
{noformat}
Try<MesosContainerizer*> containerizer =
MesosContainerizer::create(flags, true, );
{noformat}
So that it could print log to stdout.
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:
[jira] [Commented] (MESOS-4024) HealthCheckTest.CheckCommandTimeout is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051302#comment-15051302
]
haosdent commented on MESOS-4024:
-
still not idea. And health check log are located in sandbox and not display in
jenkins test log. But we could change consecutiveFailures to 2 and
timeoutSeconds to 2 to reduce test time first.
> HealthCheckTest.CheckCommandTimeout is flaky.
> -
>
> Key: MESOS-4024
> URL: https://issues.apache.org/jira/browse/MESOS-4024
> Project: Mesos
> Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
> Labels: flaky-test
> Attachments: HealthCheckTest_CheckCommandTimeout.log
>
>
> {noformat: title=Failed Run}
> [ RUN ] HealthCheckTest.CheckCommandTimeout
> I1201 13:03:15.211911 30288 leveldb.cpp:174] Opened db in 126.548747ms
> I1201 13:03:15.254041 30288 leveldb.cpp:181] Compacted db in 42.053948ms
> I1201 13:03:15.254226 30288 leveldb.cpp:196] Created db iterator in 25588ns
> I1201 13:03:15.254281 30288 leveldb.cpp:202] Seeked to beginning of db in
> 3231ns
> I1201 13:03:15.254294 30288 leveldb.cpp:271] Iterated through 0 keys in the
> db in 256ns
> I1201 13:03:15.254348 30288 replica.cpp:778] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1201 13:03:15.255162 30311 recover.cpp:447] Starting replica recovery
> I1201 13:03:15.255502 30311 recover.cpp:473] Replica is in EMPTY status
> I1201 13:03:15.257158 30311 replica.cpp:674] Replica in EMPTY status received
> a broadcasted recover request from (1898)@172.17.21.0:52024
> I1201 13:03:15.258224 30318 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I1201 13:03:15.259735 30310 recover.cpp:564] Updating replica status to
> STARTING
> I1201 13:03:15.265080 30322 master.cpp:365] Master
> dd5bff66-362f-4efc-963a-54756b2edcce (fa812f474cf4) started on
> 172.17.21.0:52024
> I1201 13:03:15.265121 30322 master.cpp:367] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/IaRntP/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/IaRntP/master" --zk_session_timeout="10secs"
> I1201 13:03:15.265487 30322 master.cpp:412] Master only allowing
> authenticated frameworks to register
> I1201 13:03:15.265504 30322 master.cpp:417] Master only allowing
> authenticated slaves to register
> I1201 13:03:15.265513 30322 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/IaRntP/credentials'
> I1201 13:03:15.265842 30322 master.cpp:456] Using default 'crammd5'
> authenticator
> I1201 13:03:15.266006 30322 master.cpp:493] Authorization enabled
> I1201 13:03:15.266464 30308 hierarchical.cpp:162] Initialized hierarchical
> allocator process
> I1201 13:03:15.267225 30321 whitelist_watcher.cpp:77] No whitelist given
> I1201 13:03:15.268847 30322 master.cpp:1637] The newly elected leader is
> master@172.17.21.0:52024 with id dd5bff66-362f-4efc-963a-54756b2edcce
> I1201 13:03:15.268887 30322 master.cpp:1650] Elected as the leading master!
> I1201 13:03:15.268905 30322 master.cpp:1395] Recovering from registrar
> I1201 13:03:15.270830 30322 registrar.cpp:307] Recovering registrar
> I1201 13:03:15.291272 30318 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 31.410668ms
> I1201 13:03:15.291363 30318 replica.cpp:321] Persisted replica status to
> STARTING
> I1201 13:03:15.291733 30318 recover.cpp:473] Replica is in STARTING status
> I1201 13:03:15.293392 30318 replica.cpp:674] Replica in STARTING status
> received a broadcasted recover request from (1900)@172.17.21.0:52024
>
[jira] [Commented] (MESOS-4025) SlaveRecoveryTest/0.GCExecutor is flaky.
[
https://issues.apache.org/jira/browse/MESOS-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052125#comment-15052125
]
haosdent commented on MESOS-4025:
-
Thank you very much for your help [~nfnt] [~greggomann]. Let me check whether
ROOT_DOCKER_DockerHealthStatusChange break SlaveRecoveryTest
> SlaveRecoveryTest/0.GCExecutor is flaky.
>
>
> Key: MESOS-4025
> URL: https://issues.apache.org/jira/browse/MESOS-4025
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.26.0
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
> Labels: flaky, flaky-test, test
>
> Build was SSL enabled (--enable-ssl, --enable-libevent). The build was based
> on 0.26.0-rc1.
> Testsuite was run as root.
> {noformat}
> sudo ./bin/mesos-tests.sh --gtest_break_on_failure --gtest_repeat=-1
> {noformat}
> {noformat}
> [ RUN ] SlaveRecoveryTest/0.GCExecutor
> I1130 16:49:16.336833 1032 exec.cpp:136] Version: 0.26.0
> I1130 16:49:16.345212 1049 exec.cpp:210] Executor registered on slave
> dde9fd4e-b016-4a99-9081-b047e9df9afa-S0
> Registered executor on ubuntu14
> Starting task 22c63bba-cbf8-46fd-b23a-5409d69e4114
> sh -c 'sleep 1000'
> Forked command at 1057
> ../../src/tests/mesos.cpp:779: Failure
> (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
> '/sys/fs/cgroup/memory/mesos_test_e5edb2a8-9af3-441f-b991-613082f264e2/slave':
> Device or resource busy
> *** Aborted at 1448902156 (unix time) try "date -d @1448902156" if you are
> using GNU date ***
> PC: @ 0x1443e9a testing::UnitTest::AddTestPartResult()
> *** SIGSEGV (@0x0) received by PID 27364 (TID 0x7f1bfdd2b800) from PID 0;
> stack trace: ***
> @ 0x7f1be92b80b7 os::Linux::chained_handler()
> @ 0x7f1be92bc219 JVM_handle_linux_signal
> @ 0x7f1bf7bbc340 (unknown)
> @ 0x1443e9a testing::UnitTest::AddTestPartResult()
> @ 0x1438b99 testing::internal::AssertHelper::operator=()
> @ 0xf0b3bb
> mesos::internal::tests::ContainerizerTest<>::TearDown()
> @ 0x1461882
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x145c6f8
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x143de4a testing::Test::Run()
> @ 0x143e584 testing::TestInfo::Run()
> @ 0x143ebca testing::TestCase::Run()
> @ 0x1445312 testing::internal::UnitTestImpl::RunAllTests()
> @ 0x14624a7
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x145d26e
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x14440ae testing::UnitTest::Run()
> @ 0xd15cd4 RUN_ALL_TESTS()
> @ 0xd158c1 main
> @ 0x7f1bf7808ec5 (unknown)
> @ 0x913009 (unknown)
> {noformat}
> My Vagrantfile generator;
> {noformat}
> #!/usr/bin/env bash
> cat << EOF > Vagrantfile
> # -*- mode: ruby -*-" >
> # vi: set ft=ruby :
> Vagrant.configure(2) do |config|
> # Disable shared folder to prevent certain kernel module dependencies.
> config.vm.synced_folder ".", "/vagrant", disabled: true
> config.vm.box = "bento/ubuntu-14.04"
> config.vm.hostname = "${PLATFORM_NAME}"
> config.vm.provider "virtualbox" do |vb|
> vb.memory = ${VAGRANT_MEM}
> vb.cpus = ${VAGRANT_CPUS}
> vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
> vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
> vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
> end
> config.vm.provider "vmware_fusion" do |vb|
> vb.memory = ${VAGRANT_MEM}
> vb.cpus = ${VAGRANT_CPUS}
> end
> config.vm.provision "file", source: "../test.sh", destination: "~/test.sh"
> config.vm.provision "shell", inline: <<-SHELL
> sudo apt-get update
> sudo apt-get -y install openjdk-7-jdk autoconf libtool
> sudo apt-get -y install build-essential python-dev python-boto \
> libcurl4-nss-dev libsasl2-dev maven \
> libapr1-dev libsvn-dev libssl-dev libevent-dev
> sudo apt-get -y install git
> sudo wget -qO- https://get.docker.com/ | sh
> SHELL
> end
> EOF
> {noformat}
> The problem is kicking in frequently in my tests - I'ld say > 10% but less
> than 50%.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2203) Old Centos 6.5 kernels/headers not sufficient for building Mesos
[ https://issues.apache.org/jira/browse/MESOS-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052163#comment-15052163 ] fhyfufangyu commented on MESOS-2203: Yes,this works. > Old Centos 6.5 kernels/headers not sufficient for building Mesos > > > Key: MESOS-2203 > URL: https://issues.apache.org/jira/browse/MESOS-2203 > Project: Mesos > Issue Type: Documentation >Affects Versions: 0.21.0 > Environment: E.g. Centos 6.5 with kernel 2.6.32-279.14.1 >Reporter: Hans van den Bogert >Priority: Minor > > Old kernels are not sufficient for building Mesos: > bq. > Error: > bq. libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" > -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"0.21.0\" > "-DPACKAGE_STRING=\"mesos 0.21.0\"" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" -DVERSION=\"0.21.0\" -DSTDC_HEADERS=1 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 > -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1 -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 > -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 > -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBSASL2=1 -DMESOS_HAS_JAVA=1 > -DHAVE_PYTHON=\"2.6\" -DMESOS_HAS_PYTHON=1 -I. -I../../src -Wall -Werror > -DLIBDIR=\"/var/scratch/vdbogert/lib\" > -DPKGLIBEXECDIR=\"/var/scratch/vdbogert/libexec/mesos\" > -DPKGDATADIR=\"/var/scratch/vdbogert/share/mesos\" -I../../include > -I../../3rdparty/libprocess/include > -I../../3rdparty/libprocess/3rdparty/stout/include -I../include > -I../include/mesos -I../3rdparty/libprocess/3rdparty/boost-1.53.0 > -I../3rdparty/libprocess/3rdparty/picojson-4f93734 > -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src > -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src > -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src > -I../3rdparty/leveldb/include -I../3rdparty/zookeeper-3.4.5/src/c/include > -I../3rdparty/zookeeper-3.4.5/src/c/generated > -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src > -I/var/scratch/vdbogert//include/subversion-1 -I/usr/include/apr-1 > -I/usr/include/apr-1.0 -pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 > -MT slave/containerizer/isolators/namespaces/libmesos_no_3rdparty_la-pid.lo > -MD -MP -MF > slave/containerizer/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Tpo > -c ../../src/slave/containerizer/isolators/namespaces/pid.cpp -fPIC -DPIC > -o > slave/containerizer/isolators/namespaces/.libs/libmesos_no_3rdparty_la-pid.o > In file included from /usr/include/sys/syscall.h:32:0, > from ../../src/linux/ns.hpp:26, > from > ../../src/slave/containerizer/isolators/namespaces/pid.cpp:31: > ../../src/linux/ns.hpp: In function 'Try ns::setns(const string&, > const string&)': > ../../src/linux/ns.hpp:167:23: error: '__NR_setns' was not declared in this > scope >int ret = ::syscall(SYS_setns, fd.get(), nstype.get()); >^ > Perhaps this should be stated on: > http://mesos.apache.org/gettingstarted/ because taking myself as example, > this has cost me a lot of time to pinpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2210) Disallow special characters in role.
[ https://issues.apache.org/jira/browse/MESOS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055485#comment-15055485 ] haosdent commented on MESOS-2210: - Use Adam's proposal. > Disallow special characters in role. > > > Key: MESOS-2210 > URL: https://issues.apache.org/jira/browse/MESOS-2210 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: haosdent > Labels: mesosphere, newbie, persistent-volumes > > As we introduce persistent volumes in MESOS-1524, we will use roles as > directory names on the slave (https://reviews.apache.org/r/28562/). As a > result, the master should disallow special characters (like space and slash) > in role. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3413:
Assignee: Zhitao Li
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker, slave
>Affects Versions: 0.23.0
>Reporter: Max Neunhöffer
>Assignee: Zhitao Li
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For the ArangoDB framework I am trying to use the persistent primitives.
> nearly all is working, but I am missing a crucial piece at the end: I have
> successfully created a persistent disk resource and have set the persistence
> and volume information in the DiskInfo message. However, I do not see any way
> to find out what directory on the host the mesos slave has reserved for us. I
> know it is ${MESOS_SLAVE_WORKDIR}/volumes/roles//_ but we
> have no way to query this information anywhere. The docker containerizer does
> not automatically mount this directory into our docker container, or symlinks
> it into our sandbox. Therefore, I have essentially no access to it. Note that
> the mesos containerizer (which I cannot use for other reasons) seems to
> create a symlink in the sandbox to the actual path for the persistent volume.
> With that, I could mount the volume into our docker container and all would
> be well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3413) Docker containerizer does not symlink persistent volumes into sandbox
[
https://issues.apache.org/jira/browse/MESOS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3413:
Assignee: (was: haosdent)
> Docker containerizer does not symlink persistent volumes into sandbox
> -
>
> Key: MESOS-3413
> URL: https://issues.apache.org/jira/browse/MESOS-3413
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker, slave
>Affects Versions: 0.23.0
>Reporter: Max Neunhöffer
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> For the ArangoDB framework I am trying to use the persistent primitives.
> nearly all is working, but I am missing a crucial piece at the end: I have
> successfully created a persistent disk resource and have set the persistence
> and volume information in the DiskInfo message. However, I do not see any way
> to find out what directory on the host the mesos slave has reserved for us. I
> know it is ${MESOS_SLAVE_WORKDIR}/volumes/roles//_ but we
> have no way to query this information anywhere. The docker containerizer does
> not automatically mount this directory into our docker container, or symlinks
> it into our sandbox. Therefore, I have essentially no access to it. Note that
> the mesos containerizer (which I cannot use for other reasons) seems to
> create a symlink in the sandbox to the actual path for the persistent volume.
> With that, I could mount the volume into our docker container and all would
> be well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3224) Create a Mesos Contributor Newbie Guide
[
https://issues.apache.org/jira/browse/MESOS-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080382#comment-15080382
]
haosdent commented on MESOS-3224:
-
{noformat}
{noformat}
is broken, are you forgot to upload image? [~darroyo]
> Create a Mesos Contributor Newbie Guide
> ---
>
> Key: MESOS-3224
> URL: https://issues.apache.org/jira/browse/MESOS-3224
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Timothy Chen
>Assignee: Diana Arroyo
>
> Currently the website doesn't have a helpful guide for community users to
> know how to start learning to contribute to Mesos, understand the concepts
> and lower the barrier to get involved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4268) Fix containerizer-internals Posix launcher TBD
haosdent created MESOS-4268: --- Summary: Fix containerizer-internals Posix launcher TBD Key: MESOS-4268 URL: https://issues.apache.org/jira/browse/MESOS-4268 Project: Mesos Issue Type: Bug Reporter: haosdent Assignee: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4247) Web UI monitor json loss timestamp
[
https://issues.apache.org/jira/browse/MESOS-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080400#comment-15080400
]
haosdent commented on MESOS-4247:
-
{noformat}
http http://xxx:5051/monitor/statistics
HTTP/1.1 200 OK
Content-Length: 364
Content-Type: application/json
Date: Sun, 03 Jan 2016 11:21:46 GMT
[
{
"executor_id": "test_sleep",
"executor_name": "Command Executor (Task: test_sleep) (Command: sh -c
'sleep 500')",
"framework_id": "1b63ee6a-4f26-45ca-b314-793fe2136fee-",
"source": "test_sleep",
"statistics": {
"cpus_limit": 1.1,
"cpus_system_time_secs": 0.23,
"cpus_user_time_secs": 0.64,
"mem_limit_bytes": 167772160,
"mem_rss_bytes": 55586816,
"timestamp": 1451820106.77759
}
}
]
{noformat}
I use latest mesos code, the return result have timestamp.
> Web UI monitor json loss timestamp
> --
>
> Key: MESOS-4247
> URL: https://issues.apache.org/jira/browse/MESOS-4247
> Project: Mesos
> Issue Type: Bug
> Components: webui
>Affects Versions: 0.26.0
> Environment: CentOS 7.0
> Mesos 0.26.0
> Marathon 0.13
>Reporter: Michael Zhang
>Priority: Minor
>
> When I use Web UI monitor CPU used for instance, found monitor json callback
> without timestamp and effect cpu used can't be display in web ui
> monitor url refresh:
> http://mesos-server:5051/monitor/statistics?jsonp=angular.callbacks._16w
> 0.22 with timestamp
> {code:xml}
> angular.callbacks._1u([{"executor_id":"x.323375c9-a94c-11e5-8fbb-86eb3605a5cc","executor_name":"Command
> Executor (Task: x.323375c9-a94c-11e5-8fbb-86eb3605a5cc) (Command: sh -c
> 'python
> start...')","framework_id":"20151009-143855-3926863626-5050-24484-","source":"x.323375c9-a94c-11e5-8fbb-86eb3605a5cc","statistics":{"cpus_limit":5.1,"cpus_system_time_secs":28.03,"cpus_user_time_secs":312.57,"mem_limit_bytes":5402263552,"mem_rss_bytes":425009152}},{"executor_id":x-test.e15fa934-a918-11e5-8fbb-86eb3605a5cc","executor_name":"Command
> Executor (Task: x-test.e15fa934-a918-11e5-8fbb-86eb3605a5cc) (Command:
> sh -c 'boinc\/boinc
> ...')","framework_id":"20151009-143855-3926863626-5050-24484-","source":"x-test.e15fa934-a918-11e5-8fbb-86eb3605a5cc","statistics":{"cpus_limit":5.1,"cpus_system_time_secs":133.11,"cpus_user_time_secs":438225.22,"mem_limit_bytes":8422162432,"mem_rss_bytes":38584320}}]);
> {code}
> 0.26 without timestamp
> {code:xml}
> angular.callbacks._46([{"executor_id":"torpedo.781bd286-97fc-11e5-bd8e-0cc47a5235cc","executor_name":"Command
> Executor (Task: xx.781bd286-97fc-11e5-bd8e-0cc47a5235cc) (Command: NO
> EXECUTABLE)","framework_id":"20150727-153101-3456970506-5050-32493-","source":"xx.781bd286-97fc-11e5-bd8e-0cc47a5235cc","statistics":{"cpus_limit":16.1,"cpus_system_time_secs":155083.63,"cpus_user_time_secs":100455.82,"mem_limit_bytes":33587986432,"mem_rss_bytes":667635712,"timestamp":1450946993.81198}},{"executor_id":"x-test.bba5aae5-97fb-11e5-bd8e-0cc47a5235cc","executor_name":"Command
> Executor (Task: x-test.bba5aae5-97fb-11e5-bd8e-0cc47a5235cc) (Command:
> sh -c 'boinc\/boinc
> ...')","framework_id":"20150727-153101-3456970506-5050-32493-","source":"boinc-test.bba5aae5-97fb-11e5-bd8e-0cc47a5235cc","statistics":{"cpus_limit":8.1,"cpus_system_time_secs":1103.55,"cpus_user_time_secs":4865.9,"mem_limit_bytes":8422162432,"mem_rss_bytes":28041216,"timestamp":1450946993.82719}}]);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2585) Use full width for mesos div.container
[ https://issues.apache.org/jira/browse/MESOS-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-2585: Attachment: github_full_width.png > Use full width for mesos div.container > -- > > Key: MESOS-2585 > URL: https://issues.apache.org/jira/browse/MESOS-2585 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Alson Kemp >Priority: Trivial > Attachments: After (patch 2).png, Narrow (current).png, Wide > (patched).png, github_full_width.png > > > I've patched our Mesos installation so that the webui takes up the full page > width and is much nicer to look at on large monitors. It's a small change. > If y'all want me to submit a PR with the update, I'll do so. > Before: > !https://issues.apache.org/jira/secure/attachment/12708818/Narrow%20%28current%29.png|width=800! > After: > !https://issues.apache.org/jira/secure/attachment/12708861/After%20%28patch%202%29.png|width=800! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
