[jira] [Updated] (MESOS-3518) Assertions that compare doubles with == can fail due to rounding issues and can crash the master.

[Marco Massenzio (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Massenzio updated MESOS-3518:
---
Description: 
mesos-0.23.0/src/common/resources.cpp has
  CHECK(result.cpus() == cpus() &&
result.mem() == mem() &&
result.disk() == disk() &&
result.ports() == ports());
at around line 869. Sometimes, rounding errors can trigger this check to fail 
because of the cpus() part. One should take the absolute value of the 
difference and compare with a small value to avoid this problem. The same 
problem could be true in various places, so far I have not yet checked.
Seems to be present in all versions I checked. I could trigger this by asking 
for some resource value of {{cpus( *):0.2}}

  was:
mesos-0.23.0/src/common/resources.cpp has
  CHECK(result.cpus() == cpus() &&
result.mem() == mem() &&
result.disk() == disk() &&
result.ports() == ports());
at around line 869. Sometimes, rounding errors can trigger this check to fail 
because of the cpus() part. One should take the absolute value of the 
difference and compare with a small value to avoid this problem. The same 
problem could be true in various places, so far I have not yet checked.
Seems to be present in all versions I checked. I could trigger this by asking 
for some resource value of {{cpus(*):0.2}}


> Assertions that compare doubles with == can fail due to rounding issues and 
> can crash the master.
> -
>
> Key: MESOS-3518
> URL: https://issues.apache.org/jira/browse/MESOS-3518
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.23.0, 0.23.1, 0.24.0, 0.24.1
>Reporter: Max Neunhöffer
>Priority: Minor
>
> mesos-0.23.0/src/common/resources.cpp has
>   CHECK(result.cpus() == cpus() &&
> result.mem() == mem() &&
> result.disk() == disk() &&
> result.ports() == ports());
> at around line 869. Sometimes, rounding errors can trigger this check to fail 
> because of the cpus() part. One should take the absolute value of the 
> difference and compare with a small value to avoid this problem. The same 
> problem could be true in various places, so far I have not yet checked.
> Seems to be present in all versions I checked. I could trigger this by asking 
> for some resource value of {{cpus( *):0.2}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3518) Assertions that compare doubles with == can fail due to rounding issues and can crash the master.

[Marco Massenzio (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Massenzio updated MESOS-3518:
---
Description: 
mesos-0.23.0/src/common/resources.cpp has
  CHECK(result.cpus() == cpus() &&
result.mem() == mem() &&
result.disk() == disk() &&
result.ports() == ports());
at around line 869. Sometimes, rounding errors can trigger this check to fail 
because of the cpus() part. One should take the absolute value of the 
difference and compare with a small value to avoid this problem. The same 
problem could be true in various places, so far I have not yet checked.
Seems to be present in all versions I checked. I could trigger this by asking 
for some resource value of {{cpus(*):0.2}}

  was:
mesos-0.23.0/src/common/resources.cpp has
  CHECK(result.cpus() == cpus() &&
result.mem() == mem() &&
result.disk() == disk() &&
result.ports() == ports());
at around line 869. Sometimes, rounding errors can trigger this check to fail 
because of the cpus() part. One should take the absolute value of the 
difference and compare with a small value to avoid this problem. The same 
problem could be true in various places, so far I have not yet checked.
Seems to be present in all versions I checked. I could trigger this by asking 
for some resource value of cpus(*):0.2


> Assertions that compare doubles with == can fail due to rounding issues and 
> can crash the master.
> -
>
> Key: MESOS-3518
> URL: https://issues.apache.org/jira/browse/MESOS-3518
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.23.0, 0.23.1, 0.24.0, 0.24.1
>Reporter: Max Neunhöffer
>Priority: Minor
>
> mesos-0.23.0/src/common/resources.cpp has
>   CHECK(result.cpus() == cpus() &&
> result.mem() == mem() &&
> result.disk() == disk() &&
> result.ports() == ports());
> at around line 869. Sometimes, rounding errors can trigger this check to fail 
> because of the cpus() part. One should take the absolute value of the 
> difference and compare with a small value to avoid this problem. The same 
> problem could be true in various places, so far I have not yet checked.
> Seems to be present in all versions I checked. I could trigger this by asking 
> for some resource value of {{cpus(*):0.2}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Marco Massenzio (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025816#comment-15025816
 ] 

Marco Massenzio commented on MESOS-3552:


As this is something that has been present in Mesos since forever, and that the 
{{0.26}} release is in process, I have removed this as a {{0.26}} blocker.
While it's not great that this slipped this release, I also believe that not 
rushing it through gives us an opportunity to address the problem "properly" 
(eg, using fixed point for resources) in time for {{0.27}}.

As a halfway, we could just remove the {{CHECK( ) }} calls that crash Mesos and 
replace them with {{LOG(ERROR)}} and return an error to the caller - this won't 
solve the issue where the cause is actually a rounding error, but at least we 
don't risk introducing regressions/bugs this close to the release.

Finally, it is my opinion that we should consolidate this ticket and MESOS-1187 
into one (probably by closing this one as a duplicate of that one, older) so 
that we don't have a "split brain" conversation, but wouldn't want to do that 
and risk losing valuable information in this one - does anyone have suggestions 
as how to do this cleanly?
(or do people feel that simply linking them and closing this one as duplicate 
would be sufficient?)

Just to be perfectly clear, I fully agree this is an important issue to 
address, I'm just suggesting here that it should not block the release.
If people feel strongly about this, please let's have a conversation either via 
hangout or email.

Thanks, everyone for looking into this!

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>  Labels: mesosphere, tech-debt
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Jojy Varghese (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025837#comment-15025837
 ] 

Jojy Varghese commented on MESOS-3793:
--

review posted: https://reviews.apache.org/r/40681

> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751   138 replica.cpp:641] Replica in EMPTY status received 
> a broadcasted recover request
> I1022 18:42:26.854856   140 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1022 18:42:26.855002   140 recover.cpp:566] Updating replica status to 
> STARTING
> I1022 18:42:26.855655   138 master.cpp:376] Master 
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on 
> 172.17.0.14:5050
> I1022 18:42:26.855680   138 master.cpp:378] Flags at startup: 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="false" 
> --authenticators="crammd5" --authorizers="local" --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="5secs" 
> --registry_strict="false" --root_submissions="true" 
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui" 
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790   138 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1022 18:42:26.855803   138 master.cpp:430] Master allowing unauthenticated 
> slaves to register
> I1022 18:42:26.855815   138 master.cpp:467] Using default 'crammd5' 
> authenticator
> W1022 18:42:26.855829   138 authenticator.cpp:505] No credentials provided, 
> authentication requests will be refused
> I1022 18:42:26.855840   138 authenticator.cpp:512] Initializing server SASL
> I1022 18:42:26.856442   136 containerizer.cpp:143] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix
> I1022 18:42:26.856943   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.888185ms
> I1022 18:42:26.856987   140 replica.cpp:323] Persisted replica status to 
> STARTING
> I1022 18:42:26.857115   140 recover.cpp:475] Replica is in STARTING status
> I1022 18:42:26.857270   140 replica.cpp:641] Replica in STARTING status 
> received a broadcasted recover request
> I1022 18:42:26.857312   140 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1022 18:42:26.857368   140 recover.cpp:566] Updating replica status to VOTING
> I1022 18:42:26.857781   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 371121ns
> I1022 18:42:26.857841   140 replica.cpp:323] Persisted replica status to 
> VOTING
> I1022 18:42:26.857895   140 recover.cpp:580] Successfully joined the Paxos 
> group
> I1022 18:42:26.857928   140 recover.cpp:464] Recover process terminated
> I1022 18:42:26.862455   137 master.cpp:1603] The newly elected leader is 
> master@172.17.0.14:5050 with id a3f39818-1bda-4710-b96b-2a60ed4d12b8
> I1022 18:42:26.862498   137 master.cpp:1616] Elected as the leading master!
> I1022 18:42:26.862511   137 master.cpp:1376] Recovering from registrar
> I1022 18:42:26.862560   137 registrar.cpp:309] Recovering registrar
> Failed to create a containerizer: Could not create MesosContainerizer: Failed 
> to create launcher: 

[jira] [Commented] (MESOS-3964) LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025901#comment-15025901
 ] 

Greg Mann commented on MESOS-3964:
--

I prepared a patch for the aforementioned solution: 
https://reviews.apache.org/r/40679/

> LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and 
> LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.
> ---
>
> Key: MESOS-3964
> URL: https://issues.apache.org/jira/browse/MESOS-3964
> Project: Mesos
>  Issue Type: Bug
>  Components: isolation, test
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile: see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Greg Mann
>Priority: Blocker
>  Labels: mesosphere
>
> sudo ./bin/mesos-test.sh 
> --gtest_filter="LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs"
> {noformat}
> ...
> F1119 14:34:52.514742 30706 isolator_tests.cpp:455] CHECK_SOME(isolator): 
> Failed to find 'cpu.cfs_quota_us'. Your kernel might be too old to use the 
> CFS cgroups feature.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4006) add a resource offers metric

[Guangya Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025974#comment-15025974
 ] 

Guangya Liu commented on MESOS-4006:


Both the /master/frameworks and /master/state endpoint can provide some info 
for offers, does this help?

> add a resource offers metric
> 
>
> Key: MESOS-4006
> URL: https://issues.apache.org/jira/browse/MESOS-4006
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: David Robinson
>
> Mesos doesn't provide a metric for monitoring offers being made, therefore 
> it's difficult to determine whether Mesos isn't making offers or if a 
> framework isn't receiving them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

[Gilbert Song (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025981#comment-15025981
 ] 

Gilbert Song commented on MESOS-3973:
-

This error is caused by not cleaning up files under the python site-package, 
because they are not uninstalled properly. I am attaching the pip log below:
{noformat}
Cannot uninstall requirement mesos.native, not installed
Exception information:
Traceback (most recent call last):
  File 
"/Users/Zebra/beginning/mesos_0.25.0/mesos/os_x_build/mesos-0.27.0/_build/sub/3rdparty/pip-1.5.6/pip/basecommand.py",
 line 122, in main
status = self.run(options, args)
  File 
"/Users/Zebra/beginning/mesos_0.25.0/mesos/os_x_build/mesos-0.27.0/_build/sub/3rdparty/pip-1.5.6/pip/commands/uninstall.py",
 line 59, in run
requirement_set.uninstall(auto_confirm=options.yes)
  File 
"/Users/Zebra/beginning/mesos_0.25.0/mesos/os_x_build/mesos-0.27.0/_build/sub/3rdparty/pip-1.5.6/pip/req.py",
 line 1035, in uninstall
req.uninstall(auto_confirm=auto_confirm)
  File 
"/Users/Zebra/beginning/mesos_0.25.0/mesos/os_x_build/mesos-0.27.0/_build/sub/3rdparty/pip-1.5.6/pip/req.py",
 line 505, in uninstall
raise UninstallationError("Cannot uninstall requirement %s, not installed" 
% (self.name,))
UninstallationError: Cannot uninstall requirement mesos.native, not installed
{noformat}

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Assignee: Gilbert Song
>  Labels: build, build-failure, mesosphere
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> 

[jira] [Commented] (MESOS-3963) Move "using mesos::fetcher::FetcherInfo" into internal namespace in "fetcher.hpp"

[Guangya Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026000#comment-15026000
 ] 

Guangya Liu commented on MESOS-3963:


Just some of my thinking: Is it possible to only put std declarations in .h 
files but not user defined declarations? I think that we should not allow end 
user to define declarations same as std declarations.

> Move "using mesos::fetcher::FetcherInfo" into internal namespace in 
> "fetcher.hpp"
> -
>
> Key: MESOS-3963
> URL: https://issues.apache.org/jira/browse/MESOS-3963
> Project: Mesos
>  Issue Type: Bug
>  Components: fetcher
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>Priority: Minor
>  Labels: newbie
>
> According to the google code style, the using should be used in internal 
> namespace in header files. Grep the header files, only fetcher.hpp deserved a 
> path.
> {quote}
> You may use a using-declaration anywhere in a .cc file (including in the 
> global namespace), and in functions, methods, classes, or within internal 
> namespaces in .h files.
> Do not use using-declarations in .h files except in explicitly marked 
> internal-only namespaces, because anything imported into a namespace in a .h 
> file becomes part of the public API exported by that file.
> {code}
> // OK in .cc files.
> // Must be in a function, method, internal namespace, or
> // class in .h files.
> using ::foo::bar;
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Timothy Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025942#comment-15025942
 ] 

Timothy Chen commented on MESOS-3966:
-

Bind doesn't work yet since we're not able to create a sandbox directory after 
it's binded.
So we need to modify the code to make it work.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025940#comment-15025940
 ] 

haosdent commented on MESOS-3966:
-

How about change image_provisioner_backend to bind in this test case?

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3978) Missing support for cpu.cfs_quota_us breaks test suite.

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025904#comment-15025904
 ] 

Greg Mann commented on MESOS-3978:
--

There is a patch containing the aforementioned solution here: 
https://reviews.apache.org/r/40679/

> Missing support for cpu.cfs_quota_us breaks test suite.
> ---
>
> Key: MESOS-3978
> URL: https://issues.apache.org/jira/browse/MESOS-3978
> Project: Mesos
>  Issue Type: Bug
> Environment: Debian 8, kernel 3.16.0-4-amd64, gcc 4.9.2
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs
> F1122 17:26:40.585412 23162 isolator_tests.cpp:455] CHECK_SOME(isolator): 
> Failed to find 'cpu.cfs_quota_us'. Your kernel might be too old to use the 
> CFS cgroups feature.
> *** Check failure stack trace: ***
> @ 0x7f81e3fc42ba  google::LogMessage::Fail()
> @ 0x7f81e3fc4216  google::LogMessage::SendToLog()
> @ 0x7f81e3fc3c0c  google::LogMessage::Flush()
> @ 0x7f81e3fc69c6  google::LogMessageFatal::~LogMessageFatal()
> @   0x962139  _CheckFatal::~_CheckFatal()
> @  0x1305e48  
> mesos::internal::tests::LimitedCpuIsolatorTest_ROOT_CGROUPS_Cfs_Test::TestBody()
> @  0x1439638  
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @  0x1434544  
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @  0x1415883  testing::Test::Run()
> @  0x1416011  testing::TestInfo::Run()
> @  0x141664c  testing::TestCase::Run()
> @  0x141cf9b  testing::internal::UnitTestImpl::RunAllTests()
> @  0x143a2c7  
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @  0x14350d0  
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @  0x141bccb  testing::UnitTest::Run()
> @   0xd324ac  RUN_ALL_TESTS()
> @   0xd3208a  main
> @ 0x7f81dde20b45  (unknown)
> @   0x92ae59  (unknown)
> {noformat}
> This hints that our kernel does not support {{cpu.cfs_quota_us}}. For 
> checking, I simply did a:
> {noformat}
> $ ls -l /sys/fs/cgroup/cpu/cpu.*
> -rw-r--r-- 1 root root 0 Nov 22 17:28 /sys/fs/cgroup/cpu/cpu.shares
> {noformat}
> So obviously this kernel won't support this feature as it is not listed. A 
> rather simple test in our test-suite could be used to dis/enable those tests.
> {noformat}
> $ ls -l /sys/fs/cgroup/cpu/cpu.cfs_quota_us
> ls: cannot access /sys/fs/cgroup/cpu/cpu.cfs_quota_us: No such file or 
> directory
> $ echo $?
> 2
> {noformat}
> We should make sure that either the test itself does not break or that it is 
> excluded in the test-runs when the system does not support this feature.
> Vagrant generator script used:
> {noformat}
> export VAGRANT_CPUS=8
> export VAGRANT_MEM=16384
> 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.hostname = "debian82"
>   config.vm.box = "bento/debian-8.2"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = ENV['VAGRANT_MEM']
> vb.cpus = ENV['VAGRANT_CPUS']
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = ENV['VAGRANT_MEM']
> vb.cpus = ENV['VAGRANT_CPUS']
>   end
>   config.vm.provision "shell", inline: <<-SHELL
> # Update the entire system.
> sudo apt-get update
> # Install Mesos dependecies.
> sudo apt-get install -y openjdk-7-jdk autoconf libtool
> sudo apt-get install -y build-essential python-dev python-boto 
> libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
> # Install latest Docker.
> sudo wget -qO- https://get.docker.com/ | sh
> # Enable memory and swap cgroups.
> sudo echo "GRUB_CMDLINE_LINUX_DEFAULT=\"cgroup_enable=memory 
> swapaccount=1\"" >>/etc/default/grub
> sudo grub-mkconfig -o /boot/grub/grub.cfg "$@"
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> sudo docker info
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure --disable-java --disable-python
> GTEST_FILTER="" make check -j$VAGRANT_CPUS
> sudo ./bin/mesos-tests.sh
> "
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3818) Line wrapping for "--help" output

[Shuai Lin (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026016#comment-15026016
 ] 

Shuai Lin commented on MESOS-3818:
--

Yeah, I would also like the "adjust the newlines in the existing help strings." 
solution, but the main reasons that I recommend against it is because: the line 
wrapping in the source code may not be consistent with the final line wrapping 
in the help output, because we use constant variables in the help strings. For 
example:

{code}
add(::acls,
"acls",
"The value could be a JSON-formatted string of ACLs or a file path\n"
"containing the JSON-formatted ACLs used for authorization. Path\n"
"could be of the form 'file:///path/to/file' or '/path/to/file'.\n"
"\n"
"Note that if the flag --authorizers is provided with a value\n"
"different than '" + DEFAULT_AUTHORIZER + "', the ACLs contents will be 
ignored.\n"
"\n"
"See the ACLs protobuf in mesos.proto for the expected format.\n");
{code}

It's very difficult to tell where to the wrap line that has the constant 
{{DEFAULT_AUTHORIZER}} by looking with eyes, except try-compile-check, and 
try-compile-check again, without any hint. And this case appears in a lots of 
help strings.

The same happens when deciding where to wrap the constant used as a default 
value of a flag:

{code}
add(::allocator,
"allocator",
"Allocator to use for resource allocation to frameworks.\n"
"Use the default '" + DEFAULT_ALLOCATOR + "' allocator, or\n"
"load an alternate allocator module using --modules.",
DEFAULT_ALLOCATOR);
{code}

If we take the "adjust the newlines in the existing help strings." solution 
this time, next time when someone else need to modify these help strings, e.g. 
when the usage of a flag is changed, it would be a pain for them to manually 
wrap the help string, and more likely they would ignore that completely, so 
after a while we may need to open another jira issue like this one again to fix 
the line wrapping.

On the contrary, If we let the the flags implementation code handle the the 
task of line wrapping, it would be way more easier to modify the help strings 
in the future, or when we want to make the help output wrap at a differnt line 
width.

About handling special-cases like JSON example text: maybe we can define a 
marker, e.g two consequtive newline character, and everything that follows the 
marker would not be formatted. 


> Line wrapping for "--help" output
> -
>
> Key: MESOS-3818
> URL: https://issues.apache.org/jira/browse/MESOS-3818
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>Assignee: Shuai Lin
>Priority: Trivial
>  Labels: mesosphere, newbie
>
> The output of `mesos-slave --help`, `mesos-master --help`, and perhaps other 
> programs has very inconsistent line wrapping: different help text fragments 
> are wrapped at very different column numbers, which harms readability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3818) Line wrapping for "--help" output

[Neil Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026020#comment-15026020
 ] 

Neil Conway commented on MESOS-3818:


Personally I think try-compile-check is tolerable: this text doesn't change 
very often. Making updates a little more labor-intensive seems preferable to 
introducing runtime complexity.

> Line wrapping for "--help" output
> -
>
> Key: MESOS-3818
> URL: https://issues.apache.org/jira/browse/MESOS-3818
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Neil Conway
>Assignee: Shuai Lin
>Priority: Trivial
>  Labels: mesosphere, newbie
>
> The output of `mesos-slave --help`, `mesos-master --help`, and perhaps other 
> programs has very inconsistent line wrapping: different help text fragments 
> are wrapped at very different column numbers, which harms readability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025965#comment-15025965
 ] 

haosdent commented on MESOS-3966:
-

Oh, got it.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4006) add a resource offers metric

[David Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026123#comment-15026123
 ] 

David Robinson commented on MESOS-4006:
---

Unfortunately not. All I need is a simple counter of resource offers made, 
preferable by framework. It would be great if there was a counter for all 
message types, not just offers. Neither the frameworks endpoint, nor state 
contains the info I need, and both are extremely expensive in large clusters.

> add a resource offers metric
> 
>
> Key: MESOS-4006
> URL: https://issues.apache.org/jira/browse/MESOS-4006
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: David Robinson
>
> Mesos doesn't provide a metric for monitoring offers being made, therefore 
> it's difficult to determine whether Mesos isn't making offers or if a 
> framework isn't receiving them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4006) add a resource offers metric

[Guangya Liu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026294#comment-15026294
 ] 

Guangya Liu commented on MESOS-4006:


So you mean that we need to track the number of offers that mesos offered to 
each framework? The problem is that once the framework accepted the offer, the 
offer will be removed from mesos master. Can you please show more detail for 
your requirement? Only add some counter/metrics to mesos master? Does it make 
sense if the /master/framework endpoint can show the offer numbers for the 
framework? Thanks!

> add a resource offers metric
> 
>
> Key: MESOS-4006
> URL: https://issues.apache.org/jira/browse/MESOS-4006
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: David Robinson
>
> Mesos doesn't provide a metric for monitoring offers being made, therefore 
> it's difficult to determine whether Mesos isn't making offers or if a 
> framework isn't receiving them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4004) Support default entrypoint and command runtime config in Mesos containerizer

[Timothy Chen (JIRA)]

Timothy Chen created MESOS-4004:
---

 Summary: Support default entrypoint and command runtime config in 
Mesos containerizer
 Key: MESOS-4004
 URL: https://issues.apache.org/jira/browse/MESOS-4004
 Project: Mesos
  Issue Type: Improvement
  Components: containerization
Reporter: Timothy Chen


We need to use the entrypoint and command runtime configuration returned from 
image to be used in Mesos containerizer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4005) Support workdir runtime configuration from image

[Timothy Chen (JIRA)]

Timothy Chen created MESOS-4005:
---

 Summary: Support workdir runtime configuration from image 
 Key: MESOS-4005
 URL: https://issues.apache.org/jira/browse/MESOS-4005
 Project: Mesos
  Issue Type: Improvement
  Components: containerization
Reporter: Timothy Chen


We need to support workdir runtime configuration returned from image such as 
Dockerfile.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Timothy Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025765#comment-15025765
 ] 

Timothy Chen commented on MESOS-3966:
-

commit c8ff94e557902fcd23b388c83bfe2692a71ae787
Author: haosdent huang 
Date:   Tue Nov 24 14:18:32 2015 -0800

Increased launch and wait timeout in filesystem test.

Review: https://reviews.apache.org/r/40641

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 

[jira] [Updated] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Marco Massenzio (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Massenzio updated MESOS-3552:
---
Labels: mesosphere tech-debt  (was: )

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>  Labels: mesosphere, tech-debt
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Marco Massenzio (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Massenzio updated MESOS-3552:
---
Issue Type: Improvement  (was: Bug)

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>  Labels: mesosphere, tech-debt
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Marco Massenzio (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025816#comment-15025816
 ] 

Marco Massenzio edited comment on MESOS-3552 at 11/25/15 12:28 AM:
---

As this is something that has been present in Mesos since forever, and that the 
{{0.26}} release is in process, I have removed this as a {{0.26}} blocker.
While it's not great that this slipped this release, I also believe that not 
rushing it through gives us an opportunity to address the problem "properly" 
(eg, using fixed point for resources) in time for {{0.27}}.

As a halfway, we could just remove the {{CHECK( )}} calls that crash Mesos and 
replace them with {{LOG(ERROR)}} and return an error to the caller - this won't 
solve the issue where the cause is actually a rounding error, but at least we 
don't risk introducing regressions/bugs this close to the release.

Finally, it is my opinion that we should consolidate this ticket and MESOS-1187 
into one (probably by closing this one as a duplicate of that one, older) so 
that we don't have a "split brain" conversation, but wouldn't want to do that 
and risk losing valuable information in this one - does anyone have suggestions 
as how to do this cleanly?
(or do people feel that simply linking them and closing this one as duplicate 
would be sufficient?)

Just to be perfectly clear, I fully agree this is an important issue to 
address, I'm just suggesting here that it should not block the release.
If people feel strongly about this, please let's have a conversation either via 
hangout or email.

Thanks, everyone for looking into this!


was (Author: marco-mesos):
As this is something that has been present in Mesos since forever, and that the 
{{0.26}} release is in process, I have removed this as a {{0.26}} blocker.
While it's not great that this slipped this release, I also believe that not 
rushing it through gives us an opportunity to address the problem "properly" 
(eg, using fixed point for resources) in time for {{0.27}}.

As a halfway, we could just remove the {{CHECK( ) }} calls that crash Mesos and 
replace them with {{LOG(ERROR)}} and return an error to the caller - this won't 
solve the issue where the cause is actually a rounding error, but at least we 
don't risk introducing regressions/bugs this close to the release.

Finally, it is my opinion that we should consolidate this ticket and MESOS-1187 
into one (probably by closing this one as a duplicate of that one, older) so 
that we don't have a "split brain" conversation, but wouldn't want to do that 
and risk losing valuable information in this one - does anyone have suggestions 
as how to do this cleanly?
(or do people feel that simply linking them and closing this one as duplicate 
would be sufficient?)

Just to be perfectly clear, I fully agree this is an important issue to 
address, I'm just suggesting here that it should not block the release.
If people feel strongly about this, please let's have a conversation either via 
hangout or email.

Thanks, everyone for looking into this!

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>  Labels: mesosphere, tech-debt
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Timothy Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025550#comment-15025550
 ] 

Timothy Chen commented on MESOS-3966:
-

I'll be merging Haosdent fix, but I think we should see how we can get bind to 
work with our tests so we don't copy /usr all the time.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA

[jira] [Commented] (MESOS-3024) HTTP endpoint authN is enabled merely by specifying --credentials

[Marco Massenzio (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025742#comment-15025742
 ] 

Marco Massenzio commented on MESOS-3024:


Got it, thanks!

> HTTP endpoint authN is enabled merely by specifying --credentials
> -
>
> Key: MESOS-3024
> URL: https://issues.apache.org/jira/browse/MESOS-3024
> Project: Mesos
>  Issue Type: Bug
>  Components: master, security
>Reporter: Adam B
>Assignee: Marco Massenzio
>  Labels: authentication, http, mesosphere
>
> If I set `--credentials` on the master, framework and slave authentication 
> are allowed, but not required. On the other hand, http authentication is now 
> required for authenticated endpoints (currently only `/shutdown`). That means 
> that I cannot enable framework or slave authentication without also enabling 
> http endpoint authentication. This is undesirable.
> Framework and slave authentication have separate flags (`\--authenticate` and 
> `\--authenticate_slaves`) to require authentication for each. It would be 
> great if there was also such a flag for http authentication. Or maybe we get 
> rid of these flags altogether and rely on ACLs to determine which 
> unauthenticated principals are even allowed to authenticate for each 
> endpoint/action.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-2980) Allow runtime configuration to be returned from provisioner

[Timothy Chen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Chen updated MESOS-2980:

Summary: Allow runtime configuration to be returned from provisioner  (was: 
Support execution configuration to be returned from provisioner)

> Allow runtime configuration to be returned from provisioner
> ---
>
> Key: MESOS-2980
> URL: https://issues.apache.org/jira/browse/MESOS-2980
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Timothy Chen
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> Image specs also includes execution configuration (e.g: Env, user, ports, 
> etc).
> We should support passing those information from the image provisioner back 
> to the containerizer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4006) add a resource offers metric

[David Robinson (JIRA)]

David Robinson created MESOS-4006:
-

 Summary: add a resource offers metric
 Key: MESOS-4006
 URL: https://issues.apache.org/jira/browse/MESOS-4006
 Project: Mesos
  Issue Type: Improvement
  Components: master
Reporter: David Robinson


Mesos doesn't provide a metric for monitoring offers being made, therefore it's 
difficult to determine whether Mesos isn't making offers or if a framework 
isn't receiving them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-2980) Allow runtime configuration to be returned from provisioner

[Timothy Chen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Chen updated MESOS-2980:

Assignee: Gilbert Song  (was: Timothy Chen)

> Allow runtime configuration to be returned from provisioner
> ---
>
> Key: MESOS-2980
> URL: https://issues.apache.org/jira/browse/MESOS-2980
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Timothy Chen
>Assignee: Gilbert Song
>  Labels: mesosphere
>
> Image specs also includes execution configuration (e.g: Env, user, ports, 
> etc).
> We should support passing those information from the image provisioner back 
> to the containerizer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4002) ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky

[Anand Mazumdar (JIRA)]

Anand Mazumdar created MESOS-4002:
-

 Summary: 
ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky
 Key: MESOS-4002
 URL: https://issues.apache.org/jira/browse/MESOS-4002
 Project: Mesos
  Issue Type: Bug
Reporter: Anand Mazumdar


Showed up on ASF CI: ( test kept looping on and on and ultimately failing the 
build after 300 minutes )
https://builds.apache.org/job/Mesos/COMPILER=gcc,CONFIGURATION=--verbose,OS=ubuntu%3A14.04,label_exp=docker%7C%7CHadoop/1269/changes

{code}
[ RUN  ] ReservationEndpointsTest.UnreserveAvailableAndOfferedResources
I1124 01:07:20.050729 30260 leveldb.cpp:174] Opened db in 107.434842ms
I1124 01:07:20.099630 30260 leveldb.cpp:181] Compacted db in 48.82312ms
I1124 01:07:20.099722 30260 leveldb.cpp:196] Created db iterator in 29905ns
I1124 01:07:20.099738 30260 leveldb.cpp:202] Seeked to beginning of db in 3145ns
I1124 01:07:20.099750 30260 leveldb.cpp:271] Iterated through 0 keys in the db 
in 279ns
I1124 01:07:20.099804 30260 replica.cpp:778] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I1124 01:07:20.100637 30292 recover.cpp:447] Starting replica recovery
I1124 01:07:20.100934 30292 recover.cpp:473] Replica is in EMPTY status
I1124 01:07:20.103240 30288 replica.cpp:674] Replica in EMPTY status received a 
broadcasted recover request from (6305)@172.17.18.107:37993
I1124 01:07:20.103672 30292 recover.cpp:193] Received a recover response from a 
replica in EMPTY status
I1124 01:07:20.104142 30292 recover.cpp:564] Updating replica status to STARTING
I1124 01:07:20.114534 30284 master.cpp:365] Master 
ad27bc60-16d1-4239-9a65-235a991f9600 (9f2f81738d5e) started on 
172.17.18.107:37993
I1124 01:07:20.114558 30284 master.cpp:367] Flags at startup: --acls="" 
--allocation_interval="1000secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
--authorizers="local" --credentials="/tmp/I60I5f/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" --roles="role" 
--root_submissions="true" --slave_ping_timeout="15secs" 
--slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
--webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui" 
--work_dir="/tmp/I60I5f/master" --zk_session_timeout="10secs"
I1124 01:07:20.114809 30284 master.cpp:412] Master only allowing authenticated 
frameworks to register
I1124 01:07:20.114820 30284 master.cpp:417] Master only allowing authenticated 
slaves to register
I1124 01:07:20.114825 30284 credentials.hpp:35] Loading credentials for 
authentication from '/tmp/I60I5f/credentials'
I1124 01:07:20.115067 30284 master.cpp:456] Using default 'crammd5' 
authenticator
I1124 01:07:20.115320 30284 master.cpp:493] Authorization enabled
I1124 01:07:20.115792 30285 hierarchical.cpp:162] Initialized hierarchical 
allocator process
I1124 01:07:20.115855 30285 whitelist_watcher.cpp:77] No whitelist given
I1124 01:07:20.118755 30285 master.cpp:1625] The newly elected leader is 
master@172.17.18.107:37993 with id ad27bc60-16d1-4239-9a65-235a991f9600
I1124 01:07:20.118788 30285 master.cpp:1638] Elected as the leading master!
I1124 01:07:20.118809 30285 master.cpp:1383] Recovering from registrar
I1124 01:07:20.119078 30285 registrar.cpp:307] Recovering registrar
I1124 01:07:20.143256 30292 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 38.787419ms
I1124 01:07:20.143347 30292 replica.cpp:321] Persisted replica status to 
STARTING
I1124 01:07:20.143717 30292 recover.cpp:473] Replica is in STARTING status
I1124 01:07:20.145454 30286 replica.cpp:674] Replica in STARTING status 
received a broadcasted recover request from (6307)@172.17.18.107:37993
I1124 01:07:20.145979 30292 recover.cpp:193] Received a recover response from a 
replica in STARTING status
I1124 01:07:20.146654 30292 recover.cpp:564] Updating replica status to VOTING
I1124 01:07:20.182672 30286 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 35.422256ms
I1124 01:07:20.182747 30286 replica.cpp:321] Persisted replica status to VOTING
I1124 01:07:20.182929 30286 recover.cpp:578] Successfully joined the Paxos group
I1124 01:07:20.183115 30286 recover.cpp:462] Recover process terminated
I1124 01:07:20.183831 30286 log.cpp:659] Attempting to start the writer
I1124 01:07:20.185907 30285 replica.cpp:494] Replica received implicit promise 
request from (6308)@172.17.18.107:37993 with proposal 1
I1124 01:07:20.225256 30285 leveldb.cpp:304] Persisting metadata (8 bytes) to 
leveldb took 39.291288ms
I1124 01:07:20.225344 30285 

[jira] [Commented] (MESOS-3916) MasterMaintenanceTest.InverseOffersFilters is flaky

[Neil Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025400#comment-15025400
 ] 

Neil Conway commented on MESOS-3916:


https://reviews.apache.org/r/40672/

> MasterMaintenanceTest.InverseOffersFilters is flaky
> ---
>
> Key: MESOS-3916
> URL: https://issues.apache.org/jira/browse/MESOS-3916
> Project: Mesos
>  Issue Type: Bug
> Environment: Ubuntu Wily 64 bit
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: flaky-test, maintenance, mesosphere
> Attachments: wily_maintenance_test_verbose.txt
>
>
> Verbose Logs:
> {code}
> [ RUN  ] MasterMaintenanceTest.InverseOffersFilters
> I1113 16:43:58.486469  8728 leveldb.cpp:176] Opened db in 2.360405ms
> I1113 16:43:58.486935  8728 leveldb.cpp:183] Compacted db in 407105ns
> I1113 16:43:58.486995  8728 leveldb.cpp:198] Created db iterator in 16221ns
> I1113 16:43:58.487030  8728 leveldb.cpp:204] Seeked to beginning of db in 
> 10935ns
> I1113 16:43:58.487046  8728 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 999ns
> I1113 16:43:58.487090  8728 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1113 16:43:58.487735  8747 recover.cpp:449] Starting replica recovery
> I1113 16:43:58.488047  8747 recover.cpp:475] Replica is in EMPTY status
> I1113 16:43:58.488977  8745 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (58)@10.0.2.15:45384
> I1113 16:43:58.489452  8746 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1113 16:43:58.489712  8747 recover.cpp:566] Updating replica status to 
> STARTING
> I1113 16:43:58.490706  8742 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 745443ns
> I1113 16:43:58.490739  8742 replica.cpp:323] Persisted replica status to 
> STARTING
> I1113 16:43:58.490859  8742 recover.cpp:475] Replica is in STARTING status
> I1113 16:43:58.491786  8747 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (59)@10.0.2.15:45384
> I1113 16:43:58.492542  8749 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1113 16:43:58.493221  8743 recover.cpp:566] Updating replica status to VOTING
> I1113 16:43:58.493710  8743 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 331874ns
> I1113 16:43:58.493767  8743 replica.cpp:323] Persisted replica status to 
> VOTING
> I1113 16:43:58.493868  8743 recover.cpp:580] Successfully joined the Paxos 
> group
> I1113 16:43:58.494119  8743 recover.cpp:464] Recover process terminated
> I1113 16:43:58.504369  8749 master.cpp:367] Master 
> d59449fc-5462-43c5-b935-e05563fdd4b6 (vagrant-ubuntu-wily-64) started on 
> 10.0.2.15:45384
> I1113 16:43:58.504438  8749 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/ZB7csS/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="/usr/local/share/mesos/webui" --work_dir="/tmp/ZB7csS/master" 
> --zk_session_timeout="10secs"
> I1113 16:43:58.504717  8749 master.cpp:416] Master allowing unauthenticated 
> frameworks to register
> I1113 16:43:58.504889  8749 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1113 16:43:58.504922  8749 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/ZB7csS/credentials'
> I1113 16:43:58.505497  8749 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1113 16:43:58.505759  8749 master.cpp:495] Authorization enabled
> I1113 16:43:58.507638  8746 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:45384 with id d59449fc-5462-43c5-b935-e05563fdd4b6
> I1113 16:43:58.507693  8746 master.cpp:1619] Elected as the leading master!
> I1113 16:43:58.507720  8746 master.cpp:1379] Recovering from registrar
> I1113 16:43:58.507946  8749 registrar.cpp:309] Recovering registrar
> I1113 16:43:58.508561  8749 log.cpp:661] Attempting to start the writer
> I1113 16:43:58.510282  8747 replica.cpp:496] Replica received implicit 
> promise request from (60)@10.0.2.15:45384 with proposal 1
> I1113 16:43:58.510867  8747 leveldb.cpp:306] 

[jira] [Updated] (MESOS-3916) MasterMaintenanceTest.InverseOffersFilters is flaky

[Neil Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Conway updated MESOS-3916:
---
Target Version/s:   (was: 0.26.0)

> MasterMaintenanceTest.InverseOffersFilters is flaky
> ---
>
> Key: MESOS-3916
> URL: https://issues.apache.org/jira/browse/MESOS-3916
> Project: Mesos
>  Issue Type: Bug
> Environment: Ubuntu Wily 64 bit
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: flaky-test, maintenance, mesosphere
> Attachments: wily_maintenance_test_verbose.txt
>
>
> Verbose Logs:
> {code}
> [ RUN  ] MasterMaintenanceTest.InverseOffersFilters
> I1113 16:43:58.486469  8728 leveldb.cpp:176] Opened db in 2.360405ms
> I1113 16:43:58.486935  8728 leveldb.cpp:183] Compacted db in 407105ns
> I1113 16:43:58.486995  8728 leveldb.cpp:198] Created db iterator in 16221ns
> I1113 16:43:58.487030  8728 leveldb.cpp:204] Seeked to beginning of db in 
> 10935ns
> I1113 16:43:58.487046  8728 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 999ns
> I1113 16:43:58.487090  8728 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1113 16:43:58.487735  8747 recover.cpp:449] Starting replica recovery
> I1113 16:43:58.488047  8747 recover.cpp:475] Replica is in EMPTY status
> I1113 16:43:58.488977  8745 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (58)@10.0.2.15:45384
> I1113 16:43:58.489452  8746 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1113 16:43:58.489712  8747 recover.cpp:566] Updating replica status to 
> STARTING
> I1113 16:43:58.490706  8742 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 745443ns
> I1113 16:43:58.490739  8742 replica.cpp:323] Persisted replica status to 
> STARTING
> I1113 16:43:58.490859  8742 recover.cpp:475] Replica is in STARTING status
> I1113 16:43:58.491786  8747 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (59)@10.0.2.15:45384
> I1113 16:43:58.492542  8749 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1113 16:43:58.493221  8743 recover.cpp:566] Updating replica status to VOTING
> I1113 16:43:58.493710  8743 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 331874ns
> I1113 16:43:58.493767  8743 replica.cpp:323] Persisted replica status to 
> VOTING
> I1113 16:43:58.493868  8743 recover.cpp:580] Successfully joined the Paxos 
> group
> I1113 16:43:58.494119  8743 recover.cpp:464] Recover process terminated
> I1113 16:43:58.504369  8749 master.cpp:367] Master 
> d59449fc-5462-43c5-b935-e05563fdd4b6 (vagrant-ubuntu-wily-64) started on 
> 10.0.2.15:45384
> I1113 16:43:58.504438  8749 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/ZB7csS/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="/usr/local/share/mesos/webui" --work_dir="/tmp/ZB7csS/master" 
> --zk_session_timeout="10secs"
> I1113 16:43:58.504717  8749 master.cpp:416] Master allowing unauthenticated 
> frameworks to register
> I1113 16:43:58.504889  8749 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1113 16:43:58.504922  8749 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/ZB7csS/credentials'
> I1113 16:43:58.505497  8749 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1113 16:43:58.505759  8749 master.cpp:495] Authorization enabled
> I1113 16:43:58.507638  8746 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:45384 with id d59449fc-5462-43c5-b935-e05563fdd4b6
> I1113 16:43:58.507693  8746 master.cpp:1619] Elected as the leading master!
> I1113 16:43:58.507720  8746 master.cpp:1379] Recovering from registrar
> I1113 16:43:58.507946  8749 registrar.cpp:309] Recovering registrar
> I1113 16:43:58.508561  8749 log.cpp:661] Attempting to start the writer
> I1113 16:43:58.510282  8747 replica.cpp:496] Replica received implicit 
> promise request from (60)@10.0.2.15:45384 with proposal 1
> I1113 16:43:58.510867  8747 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> 

[jira] [Commented] (MESOS-4002) ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky

[Anand Mazumdar (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025269#comment-15025269
 ] 

Anand Mazumdar commented on MESOS-4002:
---

Partial Fix: https://reviews.apache.org/r/40667/

Still does not answer why the test kept looping for 300 minutes. There might be 
some future that was never ready and we invoked a .get() blocking forever or a 
deadlock somewhere else. Would keep digging for the root cause and for future 
failures on the ASF CI leading to more clues.

> ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky
> ---
>
> Key: MESOS-4002
> URL: https://issues.apache.org/jira/browse/MESOS-4002
> Project: Mesos
>  Issue Type: Bug
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: flaky-test, mesosphere, reservations
>
> Showed up on ASF CI: ( test kept looping on and on and ultimately failing the 
> build after 300 minutes )
> https://builds.apache.org/job/Mesos/COMPILER=gcc,CONFIGURATION=--verbose,OS=ubuntu%3A14.04,label_exp=docker%7C%7CHadoop/1269/changes
> {code}
> [ RUN  ] ReservationEndpointsTest.UnreserveAvailableAndOfferedResources
> I1124 01:07:20.050729 30260 leveldb.cpp:174] Opened db in 107.434842ms
> I1124 01:07:20.099630 30260 leveldb.cpp:181] Compacted db in 48.82312ms
> I1124 01:07:20.099722 30260 leveldb.cpp:196] Created db iterator in 29905ns
> I1124 01:07:20.099738 30260 leveldb.cpp:202] Seeked to beginning of db in 
> 3145ns
> I1124 01:07:20.099750 30260 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 279ns
> I1124 01:07:20.099804 30260 replica.cpp:778] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1124 01:07:20.100637 30292 recover.cpp:447] Starting replica recovery
> I1124 01:07:20.100934 30292 recover.cpp:473] Replica is in EMPTY status
> I1124 01:07:20.103240 30288 replica.cpp:674] Replica in EMPTY status received 
> a broadcasted recover request from (6305)@172.17.18.107:37993
> I1124 01:07:20.103672 30292 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I1124 01:07:20.104142 30292 recover.cpp:564] Updating replica status to 
> STARTING
> I1124 01:07:20.114534 30284 master.cpp:365] Master 
> ad27bc60-16d1-4239-9a65-235a991f9600 (9f2f81738d5e) started on 
> 172.17.18.107:37993
> I1124 01:07:20.114558 30284 master.cpp:367] Flags at startup: --acls="" 
> --allocation_interval="1000secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/I60I5f/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" --roles="role" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/I60I5f/master" --zk_session_timeout="10secs"
> I1124 01:07:20.114809 30284 master.cpp:412] Master only allowing 
> authenticated frameworks to register
> I1124 01:07:20.114820 30284 master.cpp:417] Master only allowing 
> authenticated slaves to register
> I1124 01:07:20.114825 30284 credentials.hpp:35] Loading credentials for 
> authentication from '/tmp/I60I5f/credentials'
> I1124 01:07:20.115067 30284 master.cpp:456] Using default 'crammd5' 
> authenticator
> I1124 01:07:20.115320 30284 master.cpp:493] Authorization enabled
> I1124 01:07:20.115792 30285 hierarchical.cpp:162] Initialized hierarchical 
> allocator process
> I1124 01:07:20.115855 30285 whitelist_watcher.cpp:77] No whitelist given
> I1124 01:07:20.118755 30285 master.cpp:1625] The newly elected leader is 
> master@172.17.18.107:37993 with id ad27bc60-16d1-4239-9a65-235a991f9600
> I1124 01:07:20.118788 30285 master.cpp:1638] Elected as the leading master!
> I1124 01:07:20.118809 30285 master.cpp:1383] Recovering from registrar
> I1124 01:07:20.119078 30285 registrar.cpp:307] Recovering registrar
> I1124 01:07:20.143256 30292 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 38.787419ms
> I1124 01:07:20.143347 30292 replica.cpp:321] Persisted replica status to 
> STARTING
> I1124 01:07:20.143717 30292 recover.cpp:473] Replica is in STARTING status
> I1124 01:07:20.145454 30286 replica.cpp:674] Replica in STARTING status 
> received a broadcasted recover request from (6307)@172.17.18.107:37993
> I1124 01:07:20.145979 30292 recover.cpp:193] Received a recover response from 

[jira] [Assigned] (MESOS-4002) ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky

[Anand Mazumdar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anand Mazumdar reassigned MESOS-4002:
-

Assignee: Anand Mazumdar

> ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky
> ---
>
> Key: MESOS-4002
> URL: https://issues.apache.org/jira/browse/MESOS-4002
> Project: Mesos
>  Issue Type: Bug
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: flaky-test, mesosphere, reservations
>
> Showed up on ASF CI: ( test kept looping on and on and ultimately failing the 
> build after 300 minutes )
> https://builds.apache.org/job/Mesos/COMPILER=gcc,CONFIGURATION=--verbose,OS=ubuntu%3A14.04,label_exp=docker%7C%7CHadoop/1269/changes
> {code}
> [ RUN  ] ReservationEndpointsTest.UnreserveAvailableAndOfferedResources
> I1124 01:07:20.050729 30260 leveldb.cpp:174] Opened db in 107.434842ms
> I1124 01:07:20.099630 30260 leveldb.cpp:181] Compacted db in 48.82312ms
> I1124 01:07:20.099722 30260 leveldb.cpp:196] Created db iterator in 29905ns
> I1124 01:07:20.099738 30260 leveldb.cpp:202] Seeked to beginning of db in 
> 3145ns
> I1124 01:07:20.099750 30260 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 279ns
> I1124 01:07:20.099804 30260 replica.cpp:778] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1124 01:07:20.100637 30292 recover.cpp:447] Starting replica recovery
> I1124 01:07:20.100934 30292 recover.cpp:473] Replica is in EMPTY status
> I1124 01:07:20.103240 30288 replica.cpp:674] Replica in EMPTY status received 
> a broadcasted recover request from (6305)@172.17.18.107:37993
> I1124 01:07:20.103672 30292 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I1124 01:07:20.104142 30292 recover.cpp:564] Updating replica status to 
> STARTING
> I1124 01:07:20.114534 30284 master.cpp:365] Master 
> ad27bc60-16d1-4239-9a65-235a991f9600 (9f2f81738d5e) started on 
> 172.17.18.107:37993
> I1124 01:07:20.114558 30284 master.cpp:367] Flags at startup: --acls="" 
> --allocation_interval="1000secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/I60I5f/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" --roles="role" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/I60I5f/master" --zk_session_timeout="10secs"
> I1124 01:07:20.114809 30284 master.cpp:412] Master only allowing 
> authenticated frameworks to register
> I1124 01:07:20.114820 30284 master.cpp:417] Master only allowing 
> authenticated slaves to register
> I1124 01:07:20.114825 30284 credentials.hpp:35] Loading credentials for 
> authentication from '/tmp/I60I5f/credentials'
> I1124 01:07:20.115067 30284 master.cpp:456] Using default 'crammd5' 
> authenticator
> I1124 01:07:20.115320 30284 master.cpp:493] Authorization enabled
> I1124 01:07:20.115792 30285 hierarchical.cpp:162] Initialized hierarchical 
> allocator process
> I1124 01:07:20.115855 30285 whitelist_watcher.cpp:77] No whitelist given
> I1124 01:07:20.118755 30285 master.cpp:1625] The newly elected leader is 
> master@172.17.18.107:37993 with id ad27bc60-16d1-4239-9a65-235a991f9600
> I1124 01:07:20.118788 30285 master.cpp:1638] Elected as the leading master!
> I1124 01:07:20.118809 30285 master.cpp:1383] Recovering from registrar
> I1124 01:07:20.119078 30285 registrar.cpp:307] Recovering registrar
> I1124 01:07:20.143256 30292 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 38.787419ms
> I1124 01:07:20.143347 30292 replica.cpp:321] Persisted replica status to 
> STARTING
> I1124 01:07:20.143717 30292 recover.cpp:473] Replica is in STARTING status
> I1124 01:07:20.145454 30286 replica.cpp:674] Replica in STARTING status 
> received a broadcasted recover request from (6307)@172.17.18.107:37993
> I1124 01:07:20.145979 30292 recover.cpp:193] Received a recover response from 
> a replica in STARTING status
> I1124 01:07:20.146654 30292 recover.cpp:564] Updating replica status to VOTING
> I1124 01:07:20.182672 30286 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 35.422256ms
> I1124 01:07:20.182747 30286 replica.cpp:321] Persisted replica status to 
> VOTING
> I1124 01:07:20.182929 30286 

[jira] [Updated] (MESOS-4002) ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky

[Anand Mazumdar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anand Mazumdar updated MESOS-4002:
--
Shepherd: Michael Park

> ReservationEndpointsTest.UnreserveAvailableAndOfferedResources is flaky
> ---
>
> Key: MESOS-4002
> URL: https://issues.apache.org/jira/browse/MESOS-4002
> Project: Mesos
>  Issue Type: Bug
>Reporter: Anand Mazumdar
>  Labels: flaky-test, mesosphere, reservations
>
> Showed up on ASF CI: ( test kept looping on and on and ultimately failing the 
> build after 300 minutes )
> https://builds.apache.org/job/Mesos/COMPILER=gcc,CONFIGURATION=--verbose,OS=ubuntu%3A14.04,label_exp=docker%7C%7CHadoop/1269/changes
> {code}
> [ RUN  ] ReservationEndpointsTest.UnreserveAvailableAndOfferedResources
> I1124 01:07:20.050729 30260 leveldb.cpp:174] Opened db in 107.434842ms
> I1124 01:07:20.099630 30260 leveldb.cpp:181] Compacted db in 48.82312ms
> I1124 01:07:20.099722 30260 leveldb.cpp:196] Created db iterator in 29905ns
> I1124 01:07:20.099738 30260 leveldb.cpp:202] Seeked to beginning of db in 
> 3145ns
> I1124 01:07:20.099750 30260 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 279ns
> I1124 01:07:20.099804 30260 replica.cpp:778] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1124 01:07:20.100637 30292 recover.cpp:447] Starting replica recovery
> I1124 01:07:20.100934 30292 recover.cpp:473] Replica is in EMPTY status
> I1124 01:07:20.103240 30288 replica.cpp:674] Replica in EMPTY status received 
> a broadcasted recover request from (6305)@172.17.18.107:37993
> I1124 01:07:20.103672 30292 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I1124 01:07:20.104142 30292 recover.cpp:564] Updating replica status to 
> STARTING
> I1124 01:07:20.114534 30284 master.cpp:365] Master 
> ad27bc60-16d1-4239-9a65-235a991f9600 (9f2f81738d5e) started on 
> 172.17.18.107:37993
> I1124 01:07:20.114558 30284 master.cpp:367] Flags at startup: --acls="" 
> --allocation_interval="1000secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/I60I5f/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" --roles="role" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/I60I5f/master" --zk_session_timeout="10secs"
> I1124 01:07:20.114809 30284 master.cpp:412] Master only allowing 
> authenticated frameworks to register
> I1124 01:07:20.114820 30284 master.cpp:417] Master only allowing 
> authenticated slaves to register
> I1124 01:07:20.114825 30284 credentials.hpp:35] Loading credentials for 
> authentication from '/tmp/I60I5f/credentials'
> I1124 01:07:20.115067 30284 master.cpp:456] Using default 'crammd5' 
> authenticator
> I1124 01:07:20.115320 30284 master.cpp:493] Authorization enabled
> I1124 01:07:20.115792 30285 hierarchical.cpp:162] Initialized hierarchical 
> allocator process
> I1124 01:07:20.115855 30285 whitelist_watcher.cpp:77] No whitelist given
> I1124 01:07:20.118755 30285 master.cpp:1625] The newly elected leader is 
> master@172.17.18.107:37993 with id ad27bc60-16d1-4239-9a65-235a991f9600
> I1124 01:07:20.118788 30285 master.cpp:1638] Elected as the leading master!
> I1124 01:07:20.118809 30285 master.cpp:1383] Recovering from registrar
> I1124 01:07:20.119078 30285 registrar.cpp:307] Recovering registrar
> I1124 01:07:20.143256 30292 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 38.787419ms
> I1124 01:07:20.143347 30292 replica.cpp:321] Persisted replica status to 
> STARTING
> I1124 01:07:20.143717 30292 recover.cpp:473] Replica is in STARTING status
> I1124 01:07:20.145454 30286 replica.cpp:674] Replica in STARTING status 
> received a broadcasted recover request from (6307)@172.17.18.107:37993
> I1124 01:07:20.145979 30292 recover.cpp:193] Received a recover response from 
> a replica in STARTING status
> I1124 01:07:20.146654 30292 recover.cpp:564] Updating replica status to VOTING
> I1124 01:07:20.182672 30286 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 35.422256ms
> I1124 01:07:20.182747 30286 replica.cpp:321] Persisted replica status to 
> VOTING
> I1124 01:07:20.182929 30286 recover.cpp:578] Successfully joined the Paxos 
> 

[jira] [Commented] (MESOS-3916) MasterMaintenanceTest.InverseOffersFilters is flaky

[Neil Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025385#comment-15025385
 ] 

Neil Conway commented on MESOS-3916:


FYI, this is just a flakey test (not a feature bug), so it shouldn't be a 
release blocker.

> MasterMaintenanceTest.InverseOffersFilters is flaky
> ---
>
> Key: MESOS-3916
> URL: https://issues.apache.org/jira/browse/MESOS-3916
> Project: Mesos
>  Issue Type: Bug
> Environment: Ubuntu Wily 64 bit
>Reporter: Neil Conway
>Assignee: Neil Conway
>  Labels: flaky-test, maintenance, mesosphere
> Attachments: wily_maintenance_test_verbose.txt
>
>
> Verbose Logs:
> {code}
> [ RUN  ] MasterMaintenanceTest.InverseOffersFilters
> I1113 16:43:58.486469  8728 leveldb.cpp:176] Opened db in 2.360405ms
> I1113 16:43:58.486935  8728 leveldb.cpp:183] Compacted db in 407105ns
> I1113 16:43:58.486995  8728 leveldb.cpp:198] Created db iterator in 16221ns
> I1113 16:43:58.487030  8728 leveldb.cpp:204] Seeked to beginning of db in 
> 10935ns
> I1113 16:43:58.487046  8728 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 999ns
> I1113 16:43:58.487090  8728 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1113 16:43:58.487735  8747 recover.cpp:449] Starting replica recovery
> I1113 16:43:58.488047  8747 recover.cpp:475] Replica is in EMPTY status
> I1113 16:43:58.488977  8745 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (58)@10.0.2.15:45384
> I1113 16:43:58.489452  8746 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1113 16:43:58.489712  8747 recover.cpp:566] Updating replica status to 
> STARTING
> I1113 16:43:58.490706  8742 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 745443ns
> I1113 16:43:58.490739  8742 replica.cpp:323] Persisted replica status to 
> STARTING
> I1113 16:43:58.490859  8742 recover.cpp:475] Replica is in STARTING status
> I1113 16:43:58.491786  8747 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (59)@10.0.2.15:45384
> I1113 16:43:58.492542  8749 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1113 16:43:58.493221  8743 recover.cpp:566] Updating replica status to VOTING
> I1113 16:43:58.493710  8743 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 331874ns
> I1113 16:43:58.493767  8743 replica.cpp:323] Persisted replica status to 
> VOTING
> I1113 16:43:58.493868  8743 recover.cpp:580] Successfully joined the Paxos 
> group
> I1113 16:43:58.494119  8743 recover.cpp:464] Recover process terminated
> I1113 16:43:58.504369  8749 master.cpp:367] Master 
> d59449fc-5462-43c5-b935-e05563fdd4b6 (vagrant-ubuntu-wily-64) started on 
> 10.0.2.15:45384
> I1113 16:43:58.504438  8749 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/ZB7csS/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="/usr/local/share/mesos/webui" --work_dir="/tmp/ZB7csS/master" 
> --zk_session_timeout="10secs"
> I1113 16:43:58.504717  8749 master.cpp:416] Master allowing unauthenticated 
> frameworks to register
> I1113 16:43:58.504889  8749 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1113 16:43:58.504922  8749 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/ZB7csS/credentials'
> I1113 16:43:58.505497  8749 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1113 16:43:58.505759  8749 master.cpp:495] Authorization enabled
> I1113 16:43:58.507638  8746 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:45384 with id d59449fc-5462-43c5-b935-e05563fdd4b6
> I1113 16:43:58.507693  8746 master.cpp:1619] Elected as the leading master!
> I1113 16:43:58.507720  8746 master.cpp:1379] Recovering from registrar
> I1113 16:43:58.507946  8749 registrar.cpp:309] Recovering registrar
> I1113 16:43:58.508561  8749 log.cpp:661] Attempting to start the writer
> I1113 16:43:58.510282  8747 replica.cpp:496] Replica received implicit 
> promise request from (60)@10.0.2.15:45384 with 

[jira] [Assigned] (MESOS-2044) Use one IP address per container for network isolation

[Marco Massenzio (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Massenzio reassigned MESOS-2044:
--

Assignee: Marco Massenzio  (was: Kapil Arya)

> Use one IP address per container for network isolation
> --
>
> Key: MESOS-2044
> URL: https://issues.apache.org/jira/browse/MESOS-2044
> Project: Mesos
>  Issue Type: Epic
>Reporter: Cong Wang
>Assignee: Marco Massenzio
>  Labels: mesosphere
>
> If there are enough IP addresses, either IPv4 or IPv6, we should use one IP 
> address per container, instead of the ugly port range based solution. One 
> problem with this is the IP address management, usually it is managed by a 
> DHCP server, maybe we need to manage them in mesos master/slave.
> Also, maybe use macvlan instead of veth for better isolation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4003) Pass agent flags to isolator modules

[Greg Mann (JIRA)]

Greg Mann created MESOS-4003:


 Summary: Pass agent flags to isolator modules
 Key: MESOS-4003
 URL: https://issues.apache.org/jira/browse/MESOS-4003
 Project: Mesos
  Issue Type: Bug
Reporter: Greg Mann
Assignee: Greg Mann


Some isolator modules can benefit from access to the agent's command-line 
flags. For example, the DVD isolator 
(https://github.com/emccode/mesos-module-dvdi) is currently forced to mount 
external volumes in a hard-coded directory. Making the agent flags accessible 
to the isolator via {{Isolator::recover()}} would allow the isolator to mount 
volumes within the agent's {{work_dir}}. This can be accomplished by simply 
adding an overloaded signature for {{Isolator::recover()}} which includes the 
agent flags as a parameter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024956#comment-15024956
 ] 

haosdent commented on MESOS-3966:
-

Inject code replace "cp" command with "time cp", keep in mind 
"LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_5AZYMc" is a 
mount point here.
{noformat}
I1125 01:45:53.912705 19272 copy.cpp:127] Copying layer path 
'/tmp/LJCtOi/test_image_rootfs' to rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_5AZYMc/provisioner/containers$1e939edf-b1da-45e1-9877-dd0cd9e087b8/backends/copy/rootfses/67986c8a-3f70-402c-b09b-1984cf71a6e7'

real0m27.930s
user0m0.187s
sys 0m1.934s
{noformat}


> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024901#comment-15024901
 ] 

haosdent commented on MESOS-3966:
-

because /usr is 1.4G. So I think copy so slow is normal

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024903#comment-15024903
 ] 

Bernd Mathiske commented on MESOS-3793:
---

[~jojy] I like #2 better also for the reasons you have stated, with the 
addition that we can check first if the var is already set and not overwrite it 
if it is.

> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751   138 replica.cpp:641] Replica in EMPTY status received 
> a broadcasted recover request
> I1022 18:42:26.854856   140 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1022 18:42:26.855002   140 recover.cpp:566] Updating replica status to 
> STARTING
> I1022 18:42:26.855655   138 master.cpp:376] Master 
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on 
> 172.17.0.14:5050
> I1022 18:42:26.855680   138 master.cpp:378] Flags at startup: 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="false" 
> --authenticators="crammd5" --authorizers="local" --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="5secs" 
> --registry_strict="false" --root_submissions="true" 
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui" 
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790   138 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1022 18:42:26.855803   138 master.cpp:430] Master allowing unauthenticated 
> slaves to register
> I1022 18:42:26.855815   138 master.cpp:467] Using default 'crammd5' 
> authenticator
> W1022 18:42:26.855829   138 authenticator.cpp:505] No credentials provided, 
> authentication requests will be refused
> I1022 18:42:26.855840   138 authenticator.cpp:512] Initializing server SASL
> I1022 18:42:26.856442   136 containerizer.cpp:143] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix
> I1022 18:42:26.856943   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.888185ms
> I1022 18:42:26.856987   140 replica.cpp:323] Persisted replica status to 
> STARTING
> I1022 18:42:26.857115   140 recover.cpp:475] Replica is in STARTING status
> I1022 18:42:26.857270   140 replica.cpp:641] Replica in STARTING status 
> received a broadcasted recover request
> I1022 18:42:26.857312   140 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1022 18:42:26.857368   140 recover.cpp:566] Updating replica status to VOTING
> I1022 18:42:26.857781   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 371121ns
> I1022 18:42:26.857841   140 replica.cpp:323] Persisted replica status to 
> VOTING
> I1022 18:42:26.857895   140 recover.cpp:580] Successfully joined the Paxos 
> group
> I1022 18:42:26.857928   140 recover.cpp:464] Recover process terminated
> I1022 18:42:26.862455   137 master.cpp:1603] The newly elected leader is 
> master@172.17.0.14:5050 with id a3f39818-1bda-4710-b96b-2a60ed4d12b8
> I1022 18:42:26.862498   137 master.cpp:1616] Elected as the leading master!
> I1022 18:42:26.862511   137 master.cpp:1376] Recovering from registrar
> I1022 18:42:26.862560   137 registrar.cpp:309] 

[jira] [Commented] (MESOS-1563) Failed to configure on FreeBSD

[Ian Downes (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025025#comment-15025025
 ] 

Ian Downes commented on MESOS-1563:
---

Sorry the delay. Yes, I'll build and test your patches on FreeBSD over the long 
weekend and will likely give ShipIts then. I can commit them next week assuming 
all okay.

> Failed to configure on FreeBSD
> --
>
> Key: MESOS-1563
> URL: https://issues.apache.org/jira/browse/MESOS-1563
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.19.0
> Environment: FreeBSD-10/stable
>Reporter: Dmitry Sivachenko
>
> When trying to configure mesos on FreeBSD, I get the following error:
> configure: Setting up build environment for x86_64 freebsd10.0
> configure: error: "Mesos is currently unsupported on your platform."
> Why? Is there anything really Linux-specific inside? It's written in Java 
> after all.
> And MacOS is supported, but it is rather close to FreeBSD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-1563) Failed to configure on FreeBSD

[Ian Downes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Downes updated MESOS-1563:
--
Assignee: David Forsythe

> Failed to configure on FreeBSD
> --
>
> Key: MESOS-1563
> URL: https://issues.apache.org/jira/browse/MESOS-1563
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.19.0
> Environment: FreeBSD-10/stable
>Reporter: Dmitry Sivachenko
>Assignee: David Forsythe
>
> When trying to configure mesos on FreeBSD, I get the following error:
> configure: Setting up build environment for x86_64 freebsd10.0
> configure: error: "Mesos is currently unsupported on your platform."
> Why? Is there anything really Linux-specific inside? It's written in Java 
> after all.
> And MacOS is supported, but it is rather close to FreeBSD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3994) Refactor registry client/puller to avoid JSON and struct.

[Gilbert Song (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilbert Song updated MESOS-3994:

Labels: mesosphere  (was: )

> Refactor registry client/puller to avoid JSON and struct.
> -
>
> Key: MESOS-3994
> URL: https://issues.apache.org/jira/browse/MESOS-3994
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: Gilbert Song
>Assignee: Gilbert Song
>  Labels: mesosphere
>
> We should get rid of all JSON and struct for message passing as function 
> returned type. By using the methods provided by spec.hpp to refactor all 
> unnecessary JSON message and struct in registry client and registry puller. 
> Also, remove all redundant check in registry client that are already checked 
> by spec validation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-1739) Allow slave reconfiguration on restart

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-1739:
-
Assignee: (was: Greg Mann)

> Allow slave reconfiguration on restart
> --
>
> Key: MESOS-1739
> URL: https://issues.apache.org/jira/browse/MESOS-1739
> Project: Mesos
>  Issue Type: Epic
>Reporter: Patrick Reilly
>  Labels: external-volumes, mesosphere, myriad
>
> Make it so that either via a slave restart or a out of process "reconfigure" 
> ping, the attributes and resources of a slave can be updated to be a superset 
> of what they used to be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024765#comment-15024765
 ] 

haosdent commented on MESOS-3937:
-

Yes, change /etc/hosts to 
{noformat}
127.0.0.1 localhost vagrant-ubuntu-trusty-64
{noformat}
could pass the test. :-)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 with id 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024747#comment-15024747
 ] 

haosdent commented on MESOS-3937:
-

Haha, could reproduce through Vagrantfile.

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a
> I1117 15:08:09.296115 26399 master.cpp:1619] Elected as 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024769#comment-15024769
 ] 

haosdent commented on MESOS-3937:
-

Also, [~tnachen] If you could open source the executor code would be nice. I 
could not found this in your github. :-)
{noformat}
/home/tnachen/go/src/github.com/mesos/mesos-go/examples/example_executor.go
{noformat}

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 

[jira] [Commented] (MESOS-1739) Allow slave reconfiguration on restart

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024853#comment-15024853
 ] 

Greg Mann commented on MESOS-1739:
--

I'm removing myself from this ticket for now, since I've gotten caught up in 
other work.

> Allow slave reconfiguration on restart
> --
>
> Key: MESOS-1739
> URL: https://issues.apache.org/jira/browse/MESOS-1739
> Project: Mesos
>  Issue Type: Epic
>Reporter: Patrick Reilly
>Assignee: Greg Mann
>  Labels: external-volumes, mesosphere, myriad
>
> Make it so that either via a slave restart or a out of process "reconfigure" 
> ping, the attributes and resources of a slave can be updated to be a superset 
> of what they used to be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.

[Joseph Wu (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025147#comment-15025147
 ] 

Joseph Wu commented on MESOS-3969:
--

Thanks!

I'll test this on a few systems to double-check we don't have any odd 
{{distcheck}} dependency on this particular {{pip}} version.

> Failing 'make distcheck' on Debian 8, somehow SSL-related.
> --
>
> Key: MESOS-3969
> URL: https://issues.apache.org/jira/browse/MESOS-3969
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Joseph Wu
>  Labels: build, build-failure, mesosphere
>
> As non-root: make distcheck.
> {noformat}
> /bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> /bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log 
> mesos mesos-execute mesos-resolve 
> '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> libtool: install: /usr/bin/install -c .libs/mesos-local 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
> libtool: install: /usr/bin/install -c .libs/mesos-log 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
> libtool: install: /usr/bin/install -c .libs/mesos 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
> libtool: install: /usr/bin/install -c .libs/mesos-execute 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
> libtool: install: /usr/bin/install -c .libs/mesos-resolve 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
> Traceback (most recent call last):
> File "", line 1, in 
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
>  line 11, in 
> from pip.vcs import git, mercurial, subversion, bazaar # noqa
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
>  line 9, in 
> from pip.download import path_to_url
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
>  line 22, in 
> from pip._vendor import requests, six
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
>  line 53, in 
> from .packages.urllib3.contrib import pyopenssl
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
>  line 70, in 
> ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
> Traceback (most recent call last):
> File "", line 1, in 
> File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3974) CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.

[Benjamin Bannier (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023985#comment-15023985
 ] 

Benjamin Bannier commented on MESOS-3974:
-

Yes, this counter first appeared with linux' {{v3.10}} tag, so it will not work 
with any earlier kernel (like the default one from centos6.7).

This also means that {{cgroups::CgroupsMemIsolatorProcess}} will not be able to 
get pressure readings on older kernels, and return {{Failures}} for these. 
Right now this isolator process is used only in the {{MesosContainerizer}} 
under {{__linux__}}, so I think selectively disabling this set of tests in the 
stock centos6.7 CI makes sense. Any thoughts [~tillt]?

> CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.
> ---
>
> Key: MESOS-3974
> URL: https://issues.apache.org/jira/browse/MESOS-3974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 6.7, kernel 2.6.32-573.el6.x86_64, gcc 4.8.2, 
> docker 1.7.1
>Reporter: Till Toenshoff
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> GLOG_v=2 sudo ./bin/mesos-tests.sh 
> --gtest_filter="CgroupsAnyHierarchyMemoryPressureTest.*" --verbose
> {noformat}
> {noformat}
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I1120 17:40:40.410383  2467 process.cpp:2426] Spawned process 
> __gc__@127.0.0.1:45300
> I1120 17:40:40.410909  2467 process.cpp:2426] Spawned process 
> help@127.0.0.1:45300
> I1120 17:40:40.410845  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410562048+00:00
> I1120 17:40:40.410970  2467 process.cpp:2426] Spawned process 
> logging@127.0.0.1:45300
> I1120 17:40:40.410995  2467 process.cpp:2426] Spawned process 
> profiler@127.0.0.1:45300
> I1120 17:40:40.411015  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410989056+00:00
> I1120 17:40:40.411063  2467 process.cpp:2426] Spawned process 
> system@127.0.0.1:45300
> I1120 17:40:40.411160  2482 process.cpp:2436] Resuming 
> profiler@127.0.0.1:45300 at 2015-11-20 17:40:40.411155968+00:00
> I1120 17:40:40.411206  2467 process.cpp:2426] Spawned process 
> __limiter__(1)@127.0.0.1:45300
> I1120 17:40:40.411223  2467 process.cpp:2426] Spawned process 
> metrics@127.0.0.1:45300
> I1120 17:40:40.411268  2482 process.cpp:2436] Resuming system@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411266048+00:00
> I1120 17:40:40.411378  2483 process.cpp:2436] Resuming 
> __limiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.411374080+00:00
> I1120 17:40:40.411388  2467 process.cpp:2426] Spawned process 
> __processes__@127.0.0.1:45300
> I1120 17:40:40.411399  2483 process.cpp:2436] Resuming 
> __processes__@127.0.0.1:45300 at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411402  2467 process.cpp:965] libprocess is initialized on 
> 127.0.0.1:45300 for 8 cpus
> I1120 17:40:40.411415  2488 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411432  2467 logging.cpp:177] Logging to STDERR
> I1120 17:40:40.411384  2482 process.cpp:2436] Resuming 
> metrics@127.0.0.1:45300 at 2015-11-20 17:40:40.411379200+00:00
> I1120 17:40:40.411717  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411710976+00:00
> I1120 17:40:40.411813  2487 process.cpp:2436] Resuming 
> logging@127.0.0.1:45300 at 2015-11-20 17:40:40.411789056+00:00
> I1120 17:40:40.411989  2487 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411983872+00:00
> Source directory: /home/vagrant/mesos
> Build directory: /home/vagrant/mesos/build
> -
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /cgroup/blkio, /cgroup/cpu, /cgroup/cpuacct, /cgroup/cpuset, /cgroup/devices, 
> /cgroup/freezer, /cgroup/memory, /cgroup/net_cls
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
> -
> I1120 17:40:40.414676  2467 process.cpp:2426] Spawned process 
> reaper(1)@127.0.0.1:45300
> I1120 17:40:40.414728  2482 process.cpp:2436] Resuming 
> reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.414701824+00:00
> I1120 17:40:40.415870  2467 process.cpp:2426] Spawned process 
> __latch__(1)@127.0.0.1:45300
> I1120 17:40:40.415913  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.415889920+00:00
> I1120 17:40:40.415966  2467 process.cpp:2426] Spawned process 
> __waiter__(1)@127.0.0.1:45300
> I1120 17:40:40.416054  2483 process.cpp:2436] Resuming 
> __latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416045056+00:00
> I1120 17:40:40.416070  2467 

[jira] [Commented] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023988#comment-15023988
 ] 

haosdent commented on MESOS-3969:
-

pip 7.1.2 fix this problem, we could update pip tarball to a newer version.
{noformat}
try:
_openssl_versions.update({ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD})
except AttributeError:
pass
{noformat}

> Failing 'make distcheck' on Debian 8, somehow SSL-related.
> --
>
> Key: MESOS-3969
> URL: https://issues.apache.org/jira/browse/MESOS-3969
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Joseph Wu
>  Labels: build, build-failure, mesosphere
>
> As non-root: make distcheck.
> {noformat}
> /bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> /bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log 
> mesos mesos-execute mesos-resolve 
> '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> libtool: install: /usr/bin/install -c .libs/mesos-local 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
> libtool: install: /usr/bin/install -c .libs/mesos-log 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
> libtool: install: /usr/bin/install -c .libs/mesos 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
> libtool: install: /usr/bin/install -c .libs/mesos-execute 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
> libtool: install: /usr/bin/install -c .libs/mesos-resolve 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
> Traceback (most recent call last):
> File "", line 1, in 
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
>  line 11, in 
> from pip.vcs import git, mercurial, subversion, bazaar # noqa
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
>  line 9, in 
> from pip.download import path_to_url
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
>  line 22, in 
> from pip._vendor import requests, six
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
>  line 53, in 
> from .packages.urllib3.contrib import pyopenssl
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
>  line 70, in 
> ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
> Traceback (most recent call last):
> File "", line 1, in 
> File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-4001) Revisit usage of raw cout and cerr

[Benjamin Bannier (JIRA)]

Benjamin Bannier created MESOS-4001:
---

 Summary: Revisit usage of raw cout and cerr
 Key: MESOS-4001
 URL: https://issues.apache.org/jira/browse/MESOS-4001
 Project: Mesos
  Issue Type: Improvement
Reporter: Benjamin Bannier
Priority: Minor


In many instances in mesos and libprocess raw {{std::cout}} and {{std::cerr}} 
is used. This leads to inconsistent logging style, and e.g., missing time 
stamps in log output which can make debugging harder.

Only a few really do need out-of-band logging, since they e.g., display help 
strings.

We should revisit these sites and whenever possible replace with appropriate 
logging macros ({{LOG(\[INFO, WARNING], ..)}}.

Note: ATM none of this applies to code in {{stout}} where we cannot assume that 
glog is available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024013#comment-15024013
 ] 

haosdent commented on MESOS-3969:
-

The patch to upgrade pip to solve this: https://reviews.apache.org/r/40630/

> Failing 'make distcheck' on Debian 8, somehow SSL-related.
> --
>
> Key: MESOS-3969
> URL: https://issues.apache.org/jira/browse/MESOS-3969
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Joseph Wu
>  Labels: build, build-failure, mesosphere
>
> As non-root: make distcheck.
> {noformat}
> /bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> /bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log 
> mesos mesos-execute mesos-resolve 
> '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> libtool: install: /usr/bin/install -c .libs/mesos-local 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
> libtool: install: /usr/bin/install -c .libs/mesos-log 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
> libtool: install: /usr/bin/install -c .libs/mesos 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
> libtool: install: /usr/bin/install -c .libs/mesos-execute 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
> libtool: install: /usr/bin/install -c .libs/mesos-resolve 
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
> Traceback (most recent call last):
> File "", line 1, in 
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
>  line 11, in 
> from pip.vcs import git, mercurial, subversion, bazaar # noqa
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
>  line 9, in 
> from pip.download import path_to_url
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
>  line 22, in 
> from pip._vendor import requests, six
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
>  line 53, in 
> from .packages.urllib3.contrib import pyopenssl
> File 
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
>  line 70, in 
> ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
> Traceback (most recent call last):
> File "", line 1, in 
> File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Jan Schlicht (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024032#comment-15024032
 ] 

Jan Schlicht commented on MESOS-3966:
-

Thanks for the info! I will try to get it to fail with my setup.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3552:
--
Target Version/s: 0.26.0

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3024) HTTP endpoint authN is enabled merely by specifying --credentials

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024132#comment-15024132
 ] 

Adam B commented on MESOS-3024:
---

Sorry, that was a typo. Should have been "a flag for http authentication". 
Fixed now.

As for the code block you quote, that's for the new scheduler HTTP API, which 
doesn't yet support authentication (see MESOS-2297), so if the master requires 
framework authentication, we disable the scheduler HTTP API.

This ticket is not about the new HTTP API, but rather about the existing 
operator endpoints like `/teardown`

> HTTP endpoint authN is enabled merely by specifying --credentials
> -
>
> Key: MESOS-3024
> URL: https://issues.apache.org/jira/browse/MESOS-3024
> Project: Mesos
>  Issue Type: Bug
>  Components: master, security
>Reporter: Adam B
>Assignee: Marco Massenzio
>  Labels: authentication, http, mesosphere
>
> If I set `--credentials` on the master, framework and slave authentication 
> are allowed, but not required. On the other hand, http authentication is now 
> required for authenticated endpoints (currently only `/shutdown`). That means 
> that I cannot enable framework or slave authentication without also enabling 
> http endpoint authentication. This is undesirable.
> Framework and slave authentication have separate flags (`\--authenticate` and 
> `\--authenticate_slaves`) to require authentication for each. It would be 
> great if there was also such a flag for http authentication. Or maybe we get 
> rid of these flags altogether and rely on ACLs to determine which 
> unauthenticated principals are even allowed to authenticate for each 
> endpoint/action.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3991) CHECK shouldn't be an assert in a production environment.

[Klaus Ma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Klaus Ma updated MESOS-3991:

Labels: tech-debt  (was: )

> CHECK shouldn't be an assert in a production environment.
> -
>
> Key: MESOS-3991
> URL: https://issues.apache.org/jira/browse/MESOS-3991
> Project: Mesos
>  Issue Type: Bug
>Reporter: Gabriel Hartmann
>  Labels: tech-debt
>
> For example:
> In this issue some very error-prone double math causes Mesos master to crash 
> when presented with a resource RESERVE Operation of the right form.  
> On-demand DOS!
> https://issues.apache.org/jira/browse/MESOS-3552



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3024) HTTP endpoint authN is enabled merely by specifying --credentials

[Adam B (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam B updated MESOS-3024:
--
Description: 
If I set `--credentials` on the master, framework and slave authentication are 
allowed, but not required. On the other hand, http authentication is now 
required for authenticated endpoints (currently only `/shutdown`). That means 
that I cannot enable framework or slave authentication without also enabling 
http endpoint authentication. This is undesirable.

Framework and slave authentication have separate flags (`\--authenticate` and 
`\--authenticate_slaves`) to require authentication for each. It would be great 
if there was also such a flag for http authentication. Or maybe we get rid of 
these flags altogether and rely on ACLs to determine which unauthenticated 
principals are even allowed to authenticate for each endpoint/action.

  was:
If I set `--credentials` on the master, framework and slave authentication are 
allowed, but not required. On the other hand, http authentication is now 
required for authenticated endpoints (currently only `/shutdown`). That means 
that I cannot enable framework or slave authentication without also enabling 
http endpoint authentication. This is undesirable.

Framework and slave authentication have separate flags (`\--authenticate` and 
`\--authenticate_slaves`) to require authentication for each. It would be great 
if there was also such a flag for framework authentication. Or maybe we get rid 
of these flags altogether and rely on ACLs to determine which unauthenticated 
principals are even allowed to authenticate for each endpoint/action.


> HTTP endpoint authN is enabled merely by specifying --credentials
> -
>
> Key: MESOS-3024
> URL: https://issues.apache.org/jira/browse/MESOS-3024
> Project: Mesos
>  Issue Type: Bug
>  Components: master, security
>Reporter: Adam B
>Assignee: Marco Massenzio
>  Labels: authentication, http, mesosphere
>
> If I set `--credentials` on the master, framework and slave authentication 
> are allowed, but not required. On the other hand, http authentication is now 
> required for authenticated endpoints (currently only `/shutdown`). That means 
> that I cannot enable framework or slave authentication without also enabling 
> http endpoint authentication. This is undesirable.
> Framework and slave authentication have separate flags (`\--authenticate` and 
> `\--authenticate_slaves`) to require authentication for each. It would be 
> great if there was also such a flag for http authentication. Or maybe we get 
> rid of these flags altogether and rely on ACLs to determine which 
> unauthenticated principals are even allowed to authenticate for each 
> endpoint/action.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024242#comment-15024242
 ] 

Bernd Mathiske commented on MESOS-3793:
---

[~jojy] Can you please implement the solution proposed by Jie and file a patch?

> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751   138 replica.cpp:641] Replica in EMPTY status received 
> a broadcasted recover request
> I1022 18:42:26.854856   140 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1022 18:42:26.855002   140 recover.cpp:566] Updating replica status to 
> STARTING
> I1022 18:42:26.855655   138 master.cpp:376] Master 
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on 
> 172.17.0.14:5050
> I1022 18:42:26.855680   138 master.cpp:378] Flags at startup: 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="false" 
> --authenticators="crammd5" --authorizers="local" --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="5secs" 
> --registry_strict="false" --root_submissions="true" 
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui" 
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790   138 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1022 18:42:26.855803   138 master.cpp:430] Master allowing unauthenticated 
> slaves to register
> I1022 18:42:26.855815   138 master.cpp:467] Using default 'crammd5' 
> authenticator
> W1022 18:42:26.855829   138 authenticator.cpp:505] No credentials provided, 
> authentication requests will be refused
> I1022 18:42:26.855840   138 authenticator.cpp:512] Initializing server SASL
> I1022 18:42:26.856442   136 containerizer.cpp:143] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix
> I1022 18:42:26.856943   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.888185ms
> I1022 18:42:26.856987   140 replica.cpp:323] Persisted replica status to 
> STARTING
> I1022 18:42:26.857115   140 recover.cpp:475] Replica is in STARTING status
> I1022 18:42:26.857270   140 replica.cpp:641] Replica in STARTING status 
> received a broadcasted recover request
> I1022 18:42:26.857312   140 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1022 18:42:26.857368   140 recover.cpp:566] Updating replica status to VOTING
> I1022 18:42:26.857781   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 371121ns
> I1022 18:42:26.857841   140 replica.cpp:323] Persisted replica status to 
> VOTING
> I1022 18:42:26.857895   140 recover.cpp:580] Successfully joined the Paxos 
> group
> I1022 18:42:26.857928   140 recover.cpp:464] Recover process terminated
> I1022 18:42:26.862455   137 master.cpp:1603] The newly elected leader is 
> master@172.17.0.14:5050 with id a3f39818-1bda-4710-b96b-2a60ed4d12b8
> I1022 18:42:26.862498   137 master.cpp:1616] Elected as the leading master!
> I1022 18:42:26.862511   137 master.cpp:1376] Recovering from registrar
> I1022 18:42:26.862560   137 registrar.cpp:309] Recovering registrar
> Failed to create a containerizer: Could not create 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024254#comment-15024254
 ] 

Bernd Mathiske commented on MESOS-3937:
---

[~vaibhavkhanduja] What does your setup look like? Do you use the same vagrant 
file as I do? (see above) What needs to be changed?

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 

[jira] [Updated] (MESOS-3552) CHECK failure due to floating point precision on reservation request

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3552:
--
Shepherd: Bernd Mathiske

> CHECK failure due to floating point precision on reservation request
> 
>
> Key: MESOS-3552
> URL: https://issues.apache.org/jira/browse/MESOS-3552
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Mandeep Chadha
>Assignee: Mandeep Chadha
>
> result.cpus() == cpus() check is failing due to ( double == double ) 
> comparison problem. 
> Root Cause : 
> Framework requested 0.1 cpu reservation for the first task. So far so good. 
> Next Reserve operation — lead to double operations resulting in following 
> double values :
>  results.cpus() : 23.9964472863211995 cpus() : 24
> And the check ( result.cpus() == cpus() ) failed. 
>  The double arithmetic operations caused results.cpus() value to be :  
> 23.9964472863211995 and hence ( 23.9964472863211995 
> == 24 ) failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3991) CHECK shouldn't be an assert in a production environment.

[Klaus Ma (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024112#comment-15024112
 ] 

Klaus Ma commented on MESOS-3991:
-

For the CHECK, I think it's because the daemon (master or slave) did not how to 
correct the issue; so it has to abort. One option is to control it by flag, but 
the risk is that the behaviour is undefined if it continue to run after CHECK 
failed.

> CHECK shouldn't be an assert in a production environment.
> -
>
> Key: MESOS-3991
> URL: https://issues.apache.org/jira/browse/MESOS-3991
> Project: Mesos
>  Issue Type: Bug
>Reporter: Gabriel Hartmann
>  Labels: tech-debt
>
> For example:
> In this issue some very error-prone double math causes Mesos master to crash 
> when presented with a resource RESERVE Operation of the right form.  
> On-demand DOS!
> https://issues.apache.org/jira/browse/MESOS-3552



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3963) Move "using mesos::fetcher::FetcherInfo" into internal namespace in "fetcher.hpp"

[Klaus Ma (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024078#comment-15024078
 ] 

Klaus Ma commented on MESOS-3963:
-

RR: https://reviews.apache.org/r/40631/

> Move "using mesos::fetcher::FetcherInfo" into internal namespace in 
> "fetcher.hpp"
> -
>
> Key: MESOS-3963
> URL: https://issues.apache.org/jira/browse/MESOS-3963
> Project: Mesos
>  Issue Type: Bug
>  Components: fetcher
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>Priority: Minor
>  Labels: newbie
>
> According to the google code style, the using should be used in internal 
> namespace in header files. Grep the header files, only fetcher.hpp deserved a 
> path.
> {quote}
> You may use a using-declaration anywhere in a .cc file (including in the 
> global namespace), and in functions, methods, classes, or within internal 
> namespaces in .h files.
> Do not use using-declarations in .h files except in explicitly marked 
> internal-only namespaces, because anything imported into a namespace in a .h 
> file becomes part of the public API exported by that file.
> {code}
> // OK in .cc files.
> // Must be in a function, method, internal namespace, or
> // class in .h files.
> using ::foo::bar;
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3024) HTTP endpoint authN is enabled merely by specifying --credentials

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024134#comment-15024134
 ] 

Adam B commented on MESOS-3024:
---

Try /teardown on the old HTTP API, not v1

> HTTP endpoint authN is enabled merely by specifying --credentials
> -
>
> Key: MESOS-3024
> URL: https://issues.apache.org/jira/browse/MESOS-3024
> Project: Mesos
>  Issue Type: Bug
>  Components: master, security
>Reporter: Adam B
>Assignee: Marco Massenzio
>  Labels: authentication, http, mesosphere
>
> If I set `--credentials` on the master, framework and slave authentication 
> are allowed, but not required. On the other hand, http authentication is now 
> required for authenticated endpoints (currently only `/shutdown`). That means 
> that I cannot enable framework or slave authentication without also enabling 
> http endpoint authentication. This is undesirable.
> Framework and slave authentication have separate flags (`\--authenticate` and 
> `\--authenticate_slaves`) to require authentication for each. It would be 
> great if there was also such a flag for http authentication. Or maybe we get 
> rid of these flags altogether and rely on ACLs to determine which 
> unauthenticated principals are even allowed to authenticate for each 
> endpoint/action.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3989) Add missing DiscoveryInfo field to v1/mesos.proto

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3989:
--
 Shepherd: Bernd Mathiske
Affects Version/s: 0.26.0
 Target Version/s: 0.26.0
Fix Version/s: (was: 0.26.0)
  Component/s: master
   framework

> Add missing DiscoveryInfo field to v1/mesos.proto
> -
>
> Key: MESOS-3989
> URL: https://issues.apache.org/jira/browse/MESOS-3989
> Project: Mesos
>  Issue Type: Bug
>  Components: framework, master
>Affects Versions: 0.26.0
>Reporter: haosdent
>Assignee: haosdent
>
> In https://reviews.apache.org/r/37022/ , we missed add 
> DiscoveryInfo.Visibility to v1/mesos.proto.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024253#comment-15024253
 ] 

Bernd Mathiske commented on MESOS-3937:
---

[~vaibhavkhanduja] What does your setup look like? Do you use the same vagrant 
file as I do? (see above) What needs to be changed?

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 

[jira] [Commented] (MESOS-3974) CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024271#comment-15024271
 ] 

Bernd Mathiske commented on MESOS-3974:
---

[~bbannier] Aside from MesosContainerizer the only other frequently used one is 
DockerContainerizer and today's Docker also requires kernel 3.1. I suggest we 
mention the overall kernel requirement in our documentation and the web page. 
Then whoever installs kernel 3.1 can pass all tests and who does not gets a 
hint that something is not right when running tests. But ideally our configure 
script would flag this already.


> CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.
> ---
>
> Key: MESOS-3974
> URL: https://issues.apache.org/jira/browse/MESOS-3974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 6.7, kernel 2.6.32-573.el6.x86_64, gcc 4.8.2, 
> docker 1.7.1
>Reporter: Till Toenshoff
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> GLOG_v=2 sudo ./bin/mesos-tests.sh 
> --gtest_filter="CgroupsAnyHierarchyMemoryPressureTest.*" --verbose
> {noformat}
> {noformat}
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I1120 17:40:40.410383  2467 process.cpp:2426] Spawned process 
> __gc__@127.0.0.1:45300
> I1120 17:40:40.410909  2467 process.cpp:2426] Spawned process 
> help@127.0.0.1:45300
> I1120 17:40:40.410845  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410562048+00:00
> I1120 17:40:40.410970  2467 process.cpp:2426] Spawned process 
> logging@127.0.0.1:45300
> I1120 17:40:40.410995  2467 process.cpp:2426] Spawned process 
> profiler@127.0.0.1:45300
> I1120 17:40:40.411015  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410989056+00:00
> I1120 17:40:40.411063  2467 process.cpp:2426] Spawned process 
> system@127.0.0.1:45300
> I1120 17:40:40.411160  2482 process.cpp:2436] Resuming 
> profiler@127.0.0.1:45300 at 2015-11-20 17:40:40.411155968+00:00
> I1120 17:40:40.411206  2467 process.cpp:2426] Spawned process 
> __limiter__(1)@127.0.0.1:45300
> I1120 17:40:40.411223  2467 process.cpp:2426] Spawned process 
> metrics@127.0.0.1:45300
> I1120 17:40:40.411268  2482 process.cpp:2436] Resuming system@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411266048+00:00
> I1120 17:40:40.411378  2483 process.cpp:2436] Resuming 
> __limiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.411374080+00:00
> I1120 17:40:40.411388  2467 process.cpp:2426] Spawned process 
> __processes__@127.0.0.1:45300
> I1120 17:40:40.411399  2483 process.cpp:2436] Resuming 
> __processes__@127.0.0.1:45300 at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411402  2467 process.cpp:965] libprocess is initialized on 
> 127.0.0.1:45300 for 8 cpus
> I1120 17:40:40.411415  2488 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411432  2467 logging.cpp:177] Logging to STDERR
> I1120 17:40:40.411384  2482 process.cpp:2436] Resuming 
> metrics@127.0.0.1:45300 at 2015-11-20 17:40:40.411379200+00:00
> I1120 17:40:40.411717  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411710976+00:00
> I1120 17:40:40.411813  2487 process.cpp:2436] Resuming 
> logging@127.0.0.1:45300 at 2015-11-20 17:40:40.411789056+00:00
> I1120 17:40:40.411989  2487 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411983872+00:00
> Source directory: /home/vagrant/mesos
> Build directory: /home/vagrant/mesos/build
> -
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /cgroup/blkio, /cgroup/cpu, /cgroup/cpuacct, /cgroup/cpuset, /cgroup/devices, 
> /cgroup/freezer, /cgroup/memory, /cgroup/net_cls
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
> -
> I1120 17:40:40.414676  2467 process.cpp:2426] Spawned process 
> reaper(1)@127.0.0.1:45300
> I1120 17:40:40.414728  2482 process.cpp:2436] Resuming 
> reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.414701824+00:00
> I1120 17:40:40.415870  2467 process.cpp:2426] Spawned process 
> __latch__(1)@127.0.0.1:45300
> I1120 17:40:40.415913  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.415889920+00:00
> I1120 17:40:40.415966  2467 process.cpp:2426] Spawned process 
> __waiter__(1)@127.0.0.1:45300
> I1120 17:40:40.416054  2483 process.cpp:2436] Resuming 
> __latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416045056+00:00
> I1120 17:40:40.416070  2467 process.cpp:2734] Donating thread to 
> __waiter__(1)@127.0.0.1:45300 while waiting
> I1120 

[jira] [Comment Edited] (MESOS-3975) SSL build of mesos causes flaky testsuite.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024570#comment-15024570
 ] 

haosdent edited comment on MESOS-3975 at 11/24/15 2:21 PM:
---

Could not reproduce in CentOS 7.1 both "--enable-libevent --enable-ssl" or 
default option.
Test with "--enable-libevent  --enable-ssl" 100 iteration.


was (Author: haosd...@gmail.com):
Could not reproduce in CentOS 7.1 both "--enable-libevent --enable-ssl" or 
default option.

> SSL build of mesos causes flaky testsuite.
> --
>
> Key: MESOS-3975
> URL: https://issues.apache.org/jira/browse/MESOS-3975
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 7.1, Kernel 3.10.0-229.20.1.el7.x86_64, gcc 
> 4.8.3, Docker 1.9
>Reporter: Till Toenshoff
>Assignee: Joris Van Remoortere
>  Labels: mesosphere
>
> When running the tests of an SSL build of Mesos on CentOS 7.1, I see spurious 
> test failures that are, so far, not reproducible.
> The following tests did fail for me in complete runs but did seem fine when 
> running them individually, in repetition.  
> {noformat}
> DockerTest.ROOT_DOCKER_CheckPortResource
> {noformat}
> {noformat}
> ContainerizerTest.ROOT_CGROUPS_BalloonFramework
> {noformat}
> {noformat}
> [ RUN  ] 
> LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystemCommandExecutor
> 2015-11-20 
> 19:08:38,826:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> + /home/vagrant/mesos/build/src/mesos-containerizer mount --help=false 
> --operation=make-rslave --path=/
> + grep -E 
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/.+
>  /proc/self/mountinfo
> + grep -v 2b98025c-74f1-41d2-b35a-ce2cdfae347e
> + cut '-d ' -f5
> + xargs --no-run-if-empty umount -l
> + mount -n --rbind 
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/provisioner/containers/2b98025c-74f1-41d2-b35a-ce2cdfae347e/backends/copy/rootfses/bed11080-474b-4c69-8e7f-0ab85e895b0d
>  
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/slaves/830e842e-c36a-4e4c-bff4-5b9568d7df12-S0/frameworks/830e842e-c36a-4e4c-bff4-5b9568d7df12-/executors/c735be54-c47f-4645-bfc1-2f4647e2cddb/runs/2b98025c-74f1-41d2-b35a-ce2cdfae347e/.rootfs
> Could not load cert file
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:354: Failure
> Value of: statusRunning.get().state()
>   Actual: TASK_FAILED
> Expected: TASK_RUNNING
> 2015-11-20 
> 19:08:42,164:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:45,501:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:48,837:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:52,174:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:355: Failure
> Failed to wait 15secs for statusFinished
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:349: Failure
> Actual function call count doesn't match EXPECT_CALL(sched, 
> statusUpdate(, _))...
>  Expected: to be called twice
>Actual: called once - unsatisfied and active
> 2015-11-20 
> 19:08:55,511:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> *** Aborted at 1448046536 (unix time) try "date -d @1448046536" if you are 
> using GNU date ***
> PC: @0x0 (unknown)
> *** SIGSEGV (@0x0) received by PID 21380 (TID 0x7fa1549e68c0) from PID 0; 
> stack trace: ***
> @ 0x7fa141796fbb (unknown)
> @ 0x7fa14179b341 (unknown)
> @ 0x7fa14f096130 (unknown)
> {noformat}
> Vagrantfile generator:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
> 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024594#comment-15024594
 ] 

Bernd Mathiske commented on MESOS-3937:
---

This may very well be a config mistake. But then I'd like to know and document 
it. :-)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a
> 

[jira] [Commented] (MESOS-3975) SSL build of mesos causes flaky testsuite.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024570#comment-15024570
 ] 

haosdent commented on MESOS-3975:
-

Could not reproduce in CentOS 7.1 both "--enable-libevent --enable-ssl" or 
default option.

> SSL build of mesos causes flaky testsuite.
> --
>
> Key: MESOS-3975
> URL: https://issues.apache.org/jira/browse/MESOS-3975
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 7.1, Kernel 3.10.0-229.20.1.el7.x86_64, gcc 
> 4.8.3, Docker 1.9
>Reporter: Till Toenshoff
>Assignee: Joris Van Remoortere
>  Labels: mesosphere
>
> When running the tests of an SSL build of Mesos on CentOS 7.1, I see spurious 
> test failures that are, so far, not reproducible.
> The following tests did fail for me in complete runs but did seem fine when 
> running them individually, in repetition.  
> {noformat}
> DockerTest.ROOT_DOCKER_CheckPortResource
> {noformat}
> {noformat}
> ContainerizerTest.ROOT_CGROUPS_BalloonFramework
> {noformat}
> {noformat}
> [ RUN  ] 
> LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystemCommandExecutor
> 2015-11-20 
> 19:08:38,826:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> + /home/vagrant/mesos/build/src/mesos-containerizer mount --help=false 
> --operation=make-rslave --path=/
> + grep -E 
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/.+
>  /proc/self/mountinfo
> + grep -v 2b98025c-74f1-41d2-b35a-ce2cdfae347e
> + cut '-d ' -f5
> + xargs --no-run-if-empty umount -l
> + mount -n --rbind 
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/provisioner/containers/2b98025c-74f1-41d2-b35a-ce2cdfae347e/backends/copy/rootfses/bed11080-474b-4c69-8e7f-0ab85e895b0d
>  
> /tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/slaves/830e842e-c36a-4e4c-bff4-5b9568d7df12-S0/frameworks/830e842e-c36a-4e4c-bff4-5b9568d7df12-/executors/c735be54-c47f-4645-bfc1-2f4647e2cddb/runs/2b98025c-74f1-41d2-b35a-ce2cdfae347e/.rootfs
> Could not load cert file
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:354: Failure
> Value of: statusRunning.get().state()
>   Actual: TASK_FAILED
> Expected: TASK_RUNNING
> 2015-11-20 
> 19:08:42,164:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:45,501:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:48,837:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> 2015-11-20 
> 19:08:52,174:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:355: Failure
> Failed to wait 15secs for statusFinished
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:349: Failure
> Actual function call count doesn't match EXPECT_CALL(sched, 
> statusUpdate(, _))...
>  Expected: to be called twice
>Actual: called once - unsatisfied and active
> 2015-11-20 
> 19:08:55,511:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697: 
> Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server 
> refused to accept the client
> *** Aborted at 1448046536 (unix time) try "date -d @1448046536" if you are 
> using GNU date ***
> PC: @0x0 (unknown)
> *** SIGSEGV (@0x0) received by PID 21380 (TID 0x7fa1549e68c0) from PID 0; 
> stack trace: ***
> @ 0x7fa141796fbb (unknown)
> @ 0x7fa14179b341 (unknown)
> @ 0x7fa14f096130 (unknown)
> {noformat}
> Vagrantfile generator:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo 

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024580#comment-15024580
 ] 

haosdent commented on MESOS-3966:
-

Could you check this flag image_provisioner_backend. Generally, the default 
value for it is "copy", and it would execute "copy" when 
LinuxFilesystemIsolatorProcess::prepare->ProvisionerProcess::_provision->CopyBackendProcess::_provision.
 I think maybe GLOG_v not setting correctly. I run with
 sudo GLOG_v=1 ./bin/mesos-tests.sh --gtest_filter="xxx" --verbose

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost 

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Jan Schlicht (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024589#comment-15024589
 ] 

Jan Schlicht commented on MESOS-3966:
-

Scratch that, the test is using the {{copy}} provisioner as well. Though I 
still can't see the "Copying layer path..." message.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[Jan Schlicht (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024617#comment-15024617
 ] 

Jan Schlicht commented on MESOS-3966:
-

Yep, this seems to be the issue. The {{copy}} provisioner starts a {{cp}} 
subprocess. For whatever reasons, this subprocess takes longer than we expect, 
therefore the {{AWAIT_READY()}} fails after 15 seconds. The question is, why it 
is taking so long and why this is only happening for 
{{ROOT_ImageInVolumeWithRootFilesystem}}. I.e. if there's anything special in 
this test that is triggering the behaviour.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor 

[jira] [Updated] (MESOS-3851) Investigate recent crashes in Command Executor

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3851:
--
Target Version/s: 0.27.0  (was: 0.26.0)
Priority: Major  (was: Blocker)

> Investigate recent crashes in Command Executor
> --
>
> Key: MESOS-3851
> URL: https://issues.apache.org/jira/browse/MESOS-3851
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: mesosphere
>
> Post https://reviews.apache.org/r/38900 i.e. updating CommandExecutor to 
> support rootfs. There seem to be some tests showing frequent crashes due to 
> assert violations.
> {{FetcherCacheTest.SimpleEviction}} failed due to the following log:
> {code}
> I1107 19:36:46.360908 30657 slave.cpp:1793] Sending queued task '3' to 
> executor ''3' of framework 7d94c7fb-8950-4bcf-80c1-46112292dcd6- at 
> executor(1)@172.17.5.200:33871'
> I1107 19:36:46.363682  1236 exec.cpp:297] 
> I1107 19:36:46.373569  1245 exec.cpp:210] Executor registered on slave 
> 7d94c7fb-8950-4bcf-80c1-46112292dcd6-S0
> @ 0x7f9f5a7db3fa  google::LogMessage::Fail()
> I1107 19:36:46.394081  1245 exec.cpp:222] Executor::registered took 395411ns
> @ 0x7f9f5a7db359  google::LogMessage::SendToLog()
> @ 0x7f9f5a7dad6a  google::LogMessage::Flush()
> @ 0x7f9f5a7dda9e  google::LogMessageFatal::~LogMessageFatal()
> @   0x48d00a  _CheckFatal::~_CheckFatal()
> @   0x49c99d  
> mesos::internal::CommandExecutorProcess::launchTask()
> @   0x4b3dd7  
> _ZZN7process8dispatchIN5mesos8internal22CommandExecutorProcessEPNS1_14ExecutorDriverERKNS1_8TaskInfoES5_S6_EEvRKNS_3PIDIT_EEMSA_FvT0_T1_ET2_T3_ENKUlPNS_11ProcessBaseEE_clESL_
> @   0x4c470c  
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal22CommandExecutorProcessEPNS5_14ExecutorDriverERKNS5_8TaskInfoES9_SA_EEvRKNS0_3PIDIT_EEMSE_FvT0_T1_ET2_T3_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x7f9f5a761b1b  std::function<>::operator()()
> @ 0x7f9f5a749935  process::ProcessBase::visit()
> @ 0x7f9f5a74d700  process::DispatchEvent::visit()
> @   0x48e004  process::ProcessBase::serve()
> @ 0x7f9f5a745d21  process::ProcessManager::resume()
> @ 0x7f9f5a742f52  
> _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
> @ 0x7f9f5a74cf2c  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
> @ 0x7f9f5a74cedc  
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
> @ 0x7f9f5a74ce6e  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
> @ 0x7f9f5a74cdc5  
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
> @ 0x7f9f5a74cd5e  
> _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
> @ 0x7f9f5624f1e0  (unknown)
> @ 0x7f9f564a8df5  start_thread
> @ 0x7f9f559b71ad  __clone
> I1107 19:36:46.551370 30656 containerizer.cpp:1257] Executor for container 
> '6553a617-6b4a-418d-9759-5681f45ff854' has exited
> I1107 19:36:46.551429 30656 containerizer.cpp:1074] Destroying container 
> '6553a617-6b4a-418d-9759-5681f45ff854'
> I1107 19:36:46.553869 30656 containerizer.cpp:1257] Executor for container 
> 'd2c1f924-c92a-453e-82b1-c294d09c4873' has exited
> {code}
> The reason seems to be a race between the executor receiving a 
> {{RunTaskMessage}} before {{ExecutorRegisteredMessage}} leading to the 
> {{CHECK_SOME(executorInfo)}} failure.
> Link to complete log: 
> https://issues.apache.org/jira/browse/MESOS-2831?focusedCommentId=14995535=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14995535
> Another related failure from {{ExamplesTest.PersistentVolumeFramework}}
> {code}
> @ 0x7f4f71529cbd  google::LogMessage::SendToLog()
> I1107 13:15:09.949987 31573 slave.cpp:2337] Status update manager 
> successfully handled status update acknowledgement (UUID: 
> 721c7316-5580-4636-a83a-098e3bd4ed1f) for task 
> ad90531f-d3d8-43f6-96f2-c81c4548a12d of framework 
> ac4ea54a-7d19-4e41-9ee3-1a761f8e5b0f-
> @ 0x7f4f715296ce  google::LogMessage::Flush()
> @ 0x7f4f7152c402  google::LogMessageFatal::~LogMessageFatal()
> @   0x48d00a  

[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Jojy Varghese (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024670#comment-15024670
 ] 

Jojy Varghese commented on MESOS-3793:
--

[~bernd-mesos], [~jieyu]
Since there are 2 ways proposed, here is my take on both:

1. We change the ``` bin/mesos-local-flags.sh.in ``` file to add ```export 
MESOS_LAUNCHER=posix```

- Adding the new env variable along with MESOS_WORK_DIR looks out of place.
- mesos-slave is an executable that can be launched by itself. If launched by 
itself, it will bypass the shell script and the issue will surface

2. Change local/main.cpp to add the line ```os::setenv("MESOS_LAUNCHER", 
"posix");```. 
- We set LIBPROCESS_IP and LIbPROCESS_PORT this way in that file. So the new 
env variable could be added along with the existing ones.
- This approach will make sure that the code path of setting the new env 
variable is called in all cases.

I like #2 approach. Please let me know if that sounds ok.


> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751   138 replica.cpp:641] Replica in EMPTY status received 
> a broadcasted recover request
> I1022 18:42:26.854856   140 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1022 18:42:26.855002   140 recover.cpp:566] Updating replica status to 
> STARTING
> I1022 18:42:26.855655   138 master.cpp:376] Master 
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on 
> 172.17.0.14:5050
> I1022 18:42:26.855680   138 master.cpp:378] Flags at startup: 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="false" 
> --authenticators="crammd5" --authorizers="local" --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="5secs" 
> --registry_strict="false" --root_submissions="true" 
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui" 
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790   138 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1022 18:42:26.855803   138 master.cpp:430] Master allowing unauthenticated 
> slaves to register
> I1022 18:42:26.855815   138 master.cpp:467] Using default 'crammd5' 
> authenticator
> W1022 18:42:26.855829   138 authenticator.cpp:505] No credentials provided, 
> authentication requests will be refused
> I1022 18:42:26.855840   138 authenticator.cpp:512] Initializing server SASL
> I1022 18:42:26.856442   136 containerizer.cpp:143] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix
> I1022 18:42:26.856943   140 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.888185ms
> I1022 18:42:26.856987   140 replica.cpp:323] Persisted replica status to 
> STARTING
> I1022 18:42:26.857115   140 recover.cpp:475] Replica is in STARTING status
> I1022 18:42:26.857270   140 replica.cpp:641] Replica in STARTING status 
> received a broadcasted recover request
> I1022 18:42:26.857312   140 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1022 18:42:26.857368   140 recover.cpp:566] Updating replica status to VOTING
> I1022 18:42:26.857781   140 leveldb.cpp:306] Persisting metadata (8 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024375#comment-15024375
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024373#comment-15024373
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024379#comment-15024379
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024372#comment-15024372
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024378#comment-15024378
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024377#comment-15024377
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024371#comment-15024371
 ] 

Vaibhav Khanduja commented on MESOS-3937:
-

[~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover 

[jira] [Commented] (MESOS-3974) CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024272#comment-15024272
 ] 

Bernd Mathiske commented on MESOS-3974:
---

[~bbannier] Aside from MesosContainerizer the only other frequently used one is 
DockerContainerizer and today's Docker also requires kernel 3.1. I suggest we 
mention the overall kernel requirement in our documentation and the web page. 
Then whoever installs kernel 3.1 can pass all tests and who does not gets a 
hint that something is not right when running tests. But ideally our configure 
script would flag this already.


> CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.
> ---
>
> Key: MESOS-3974
> URL: https://issues.apache.org/jira/browse/MESOS-3974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 6.7, kernel 2.6.32-573.el6.x86_64, gcc 4.8.2, 
> docker 1.7.1
>Reporter: Till Toenshoff
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> GLOG_v=2 sudo ./bin/mesos-tests.sh 
> --gtest_filter="CgroupsAnyHierarchyMemoryPressureTest.*" --verbose
> {noformat}
> {noformat}
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I1120 17:40:40.410383  2467 process.cpp:2426] Spawned process 
> __gc__@127.0.0.1:45300
> I1120 17:40:40.410909  2467 process.cpp:2426] Spawned process 
> help@127.0.0.1:45300
> I1120 17:40:40.410845  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410562048+00:00
> I1120 17:40:40.410970  2467 process.cpp:2426] Spawned process 
> logging@127.0.0.1:45300
> I1120 17:40:40.410995  2467 process.cpp:2426] Spawned process 
> profiler@127.0.0.1:45300
> I1120 17:40:40.411015  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410989056+00:00
> I1120 17:40:40.411063  2467 process.cpp:2426] Spawned process 
> system@127.0.0.1:45300
> I1120 17:40:40.411160  2482 process.cpp:2436] Resuming 
> profiler@127.0.0.1:45300 at 2015-11-20 17:40:40.411155968+00:00
> I1120 17:40:40.411206  2467 process.cpp:2426] Spawned process 
> __limiter__(1)@127.0.0.1:45300
> I1120 17:40:40.411223  2467 process.cpp:2426] Spawned process 
> metrics@127.0.0.1:45300
> I1120 17:40:40.411268  2482 process.cpp:2436] Resuming system@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411266048+00:00
> I1120 17:40:40.411378  2483 process.cpp:2436] Resuming 
> __limiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.411374080+00:00
> I1120 17:40:40.411388  2467 process.cpp:2426] Spawned process 
> __processes__@127.0.0.1:45300
> I1120 17:40:40.411399  2483 process.cpp:2436] Resuming 
> __processes__@127.0.0.1:45300 at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411402  2467 process.cpp:965] libprocess is initialized on 
> 127.0.0.1:45300 for 8 cpus
> I1120 17:40:40.411415  2488 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411432  2467 logging.cpp:177] Logging to STDERR
> I1120 17:40:40.411384  2482 process.cpp:2436] Resuming 
> metrics@127.0.0.1:45300 at 2015-11-20 17:40:40.411379200+00:00
> I1120 17:40:40.411717  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411710976+00:00
> I1120 17:40:40.411813  2487 process.cpp:2436] Resuming 
> logging@127.0.0.1:45300 at 2015-11-20 17:40:40.411789056+00:00
> I1120 17:40:40.411989  2487 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411983872+00:00
> Source directory: /home/vagrant/mesos
> Build directory: /home/vagrant/mesos/build
> -
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /cgroup/blkio, /cgroup/cpu, /cgroup/cpuacct, /cgroup/cpuset, /cgroup/devices, 
> /cgroup/freezer, /cgroup/memory, /cgroup/net_cls
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
> -
> I1120 17:40:40.414676  2467 process.cpp:2426] Spawned process 
> reaper(1)@127.0.0.1:45300
> I1120 17:40:40.414728  2482 process.cpp:2436] Resuming 
> reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.414701824+00:00
> I1120 17:40:40.415870  2467 process.cpp:2426] Spawned process 
> __latch__(1)@127.0.0.1:45300
> I1120 17:40:40.415913  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.415889920+00:00
> I1120 17:40:40.415966  2467 process.cpp:2426] Spawned process 
> __waiter__(1)@127.0.0.1:45300
> I1120 17:40:40.416054  2483 process.cpp:2436] Resuming 
> __latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416045056+00:00
> I1120 17:40:40.416070  2467 process.cpp:2734] Donating thread to 
> __waiter__(1)@127.0.0.1:45300 while waiting
> I1120 

[jira] [Issue Comment Deleted] (MESOS-3974) CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3974:
--
Comment: was deleted

(was: [~bbannier] Aside from MesosContainerizer the only other frequently used 
one is DockerContainerizer and today's Docker also requires kernel 3.1. I 
suggest we mention the overall kernel requirement in our documentation and the 
web page. Then whoever installs kernel 3.1 can pass all tests and who does not 
gets a hint that something is not right when running tests. But ideally our 
configure script would flag this already.
)

> CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.
> ---
>
> Key: MESOS-3974
> URL: https://issues.apache.org/jira/browse/MESOS-3974
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: CentOS 6.7, kernel 2.6.32-573.el6.x86_64, gcc 4.8.2, 
> docker 1.7.1
>Reporter: Till Toenshoff
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> {noformat}
> GLOG_v=2 sudo ./bin/mesos-tests.sh 
> --gtest_filter="CgroupsAnyHierarchyMemoryPressureTest.*" --verbose
> {noformat}
> {noformat}
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I1120 17:40:40.410383  2467 process.cpp:2426] Spawned process 
> __gc__@127.0.0.1:45300
> I1120 17:40:40.410909  2467 process.cpp:2426] Spawned process 
> help@127.0.0.1:45300
> I1120 17:40:40.410845  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410562048+00:00
> I1120 17:40:40.410970  2467 process.cpp:2426] Spawned process 
> logging@127.0.0.1:45300
> I1120 17:40:40.410995  2467 process.cpp:2426] Spawned process 
> profiler@127.0.0.1:45300
> I1120 17:40:40.411015  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.410989056+00:00
> I1120 17:40:40.411063  2467 process.cpp:2426] Spawned process 
> system@127.0.0.1:45300
> I1120 17:40:40.411160  2482 process.cpp:2436] Resuming 
> profiler@127.0.0.1:45300 at 2015-11-20 17:40:40.411155968+00:00
> I1120 17:40:40.411206  2467 process.cpp:2426] Spawned process 
> __limiter__(1)@127.0.0.1:45300
> I1120 17:40:40.411223  2467 process.cpp:2426] Spawned process 
> metrics@127.0.0.1:45300
> I1120 17:40:40.411268  2482 process.cpp:2436] Resuming system@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411266048+00:00
> I1120 17:40:40.411378  2483 process.cpp:2436] Resuming 
> __limiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.411374080+00:00
> I1120 17:40:40.411388  2467 process.cpp:2426] Spawned process 
> __processes__@127.0.0.1:45300
> I1120 17:40:40.411399  2483 process.cpp:2436] Resuming 
> __processes__@127.0.0.1:45300 at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411402  2467 process.cpp:965] libprocess is initialized on 
> 127.0.0.1:45300 for 8 cpus
> I1120 17:40:40.411415  2488 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411397888+00:00
> I1120 17:40:40.411432  2467 logging.cpp:177] Logging to STDERR
> I1120 17:40:40.411384  2482 process.cpp:2436] Resuming 
> metrics@127.0.0.1:45300 at 2015-11-20 17:40:40.411379200+00:00
> I1120 17:40:40.411717  2482 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411710976+00:00
> I1120 17:40:40.411813  2487 process.cpp:2436] Resuming 
> logging@127.0.0.1:45300 at 2015-11-20 17:40:40.411789056+00:00
> I1120 17:40:40.411989  2487 process.cpp:2436] Resuming help@127.0.0.1:45300 
> at 2015-11-20 17:40:40.411983872+00:00
> Source directory: /home/vagrant/mesos
> Build directory: /home/vagrant/mesos/build
> -
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /cgroup/blkio, /cgroup/cpu, /cgroup/cpuacct, /cgroup/cpuset, /cgroup/devices, 
> /cgroup/freezer, /cgroup/memory, /cgroup/net_cls
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
> -
> I1120 17:40:40.414676  2467 process.cpp:2426] Spawned process 
> reaper(1)@127.0.0.1:45300
> I1120 17:40:40.414728  2482 process.cpp:2436] Resuming 
> reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.414701824+00:00
> I1120 17:40:40.415870  2467 process.cpp:2426] Spawned process 
> __latch__(1)@127.0.0.1:45300
> I1120 17:40:40.415913  2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300 
> at 2015-11-20 17:40:40.415889920+00:00
> I1120 17:40:40.415966  2467 process.cpp:2426] Spawned process 
> __waiter__(1)@127.0.0.1:45300
> I1120 17:40:40.416054  2483 process.cpp:2436] Resuming 
> __latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416045056+00:00
> I1120 17:40:40.416070  2467 process.cpp:2734] Donating thread to 
> __waiter__(1)@127.0.0.1:45300 while waiting
> I1120 17:40:40.416093  

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Issue Comment Deleted] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[Vaibhav Khanduja (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vaibhav Khanduja updated MESOS-3937:

Comment: was deleted

(was: [~bernd-mesos]
My environment seems to be same as your :) ... My vagrant file points to 
"config.vm.box = "phusion/ubuntu-14.04-amd64"". The vagrant provisioned using 
virtual box, with 4096 memory and 4 processors. I run this on my Mac book pro, 
with source checked out from github. The source code is checked out on my mac, 
mounted it under /vagrant. All build happens under /vagrant.
HTH)

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process 

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024488#comment-15024488
 ] 

haosdent commented on MESOS-3966:
-

The success log after increase await_ready timeout
{noformat}
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from LinuxFilesystemIsolatorTest
[ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
I1124 21:14:11.123080  4974 linux.cpp:81] Making 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w' 
a shared mount
I1124 21:14:11.136381  4974 linux_launcher.cpp:101] Using 
/sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
I1124 21:14:11.140123  4974 systemd.cpp:126] systemd version `208` detected
W1124 21:14:11.140149  4974 systemd.cpp:134] Required functionality `Delegate` 
was introduced in Version `218`. Your system may not function properly; however 
since some distributions have patched systemd packages, your system may still 
be functional. This is why we keep running. See MESOS-3352 for more information
I1124 21:14:11.146225  4974 systemd.cpp:208] Started systemd slice 
`mesos_executors.slice`
I1124 21:14:11.147725  4992 containerizer.cpp:617] Starting container 
'a5645a24-5c3f-4108-9292-5aaea1957415' for executor 'test_executor' of 
framework ''
I1124 21:14:11.150281  4989 provisioner.cpp:287] Provisioning image rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6'
 for container a5645a24-5c3f-4108-9292-5aaea1957415
I1124 21:14:11.151124  4993 copy.cpp:127] Copying layer path 
'/tmp/9rIY9c/test_image_rootfs' to rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6'
I1124 21:14:39.070953  4991 provisioner.cpp:287] Provisioning image rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e2f98f17-269c-49f5-85e3-54bef736852a'
 for container a5645a24-5c3f-4108-9292-5aaea1957415
I1124 21:14:39.071646  4994 copy.cpp:127] Copying layer path 
'/tmp/9rIY9c/test_image_volume' to rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e2f98f17-269c-49f5-85e3-54bef736852a'
I1124 21:14:41.280971  4991 linux.cpp:390] Bind mounting work directory from 
'/tmp/9rIY9c/sandbox' to 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6/mnt/mesos/sandbox'
 for container a5645a24-5c3f-4108-9292-5aaea1957415
I1124 21:14:41.286027  4988 linux_launcher.cpp:363] Cloning child process with 
flags = CLONE_NEWNS
I1124 21:14:41.289008  4988 linux_launcher.cpp:420] Assigned child process 
'5053' to 'mesos_executors.slice'
+ /home/ld-sgdev/huangh/mesos/build/src/mesos-containerizer mount --help=false 
--operation=make-rslave --path=/
+ grep -E 
/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/.+ 
/proc/self/mountinfo
+ grep -v a5645a24-5c3f-4108-9292-5aaea1957415
+ cut '-d ' -f5
+ xargs --no-run-if-empty umount -l
+ mount -n --rbind 
/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e2f98f17-269c-49f5-85e3-54bef736852a
 
/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6/mnt/mesos/sandbox/rootfs
Changing root to 
/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6
I1124 21:14:42.789233  4988 containerizer.cpp:1256] Executor for container 
'a5645a24-5c3f-4108-9292-5aaea1957415' has exited
I1124 21:14:42.789325  4988 containerizer.cpp:1073] Destroying container 
'a5645a24-5c3f-4108-9292-5aaea1957415'
I1124 21:14:42.793495  4993 cgroups.cpp:2427] Freezing cgroup 
/sys/fs/cgroup/freezer/mesos/a5645a24-5c3f-4108-9292-5aaea1957415
I1124 21:14:42.796504  4989 cgroups.cpp:1409] Successfully froze cgroup 
/sys/fs/cgroup/freezer/mesos/a5645a24-5c3f-4108-9292-5aaea1957415 after 
2.916864ms
I1124 21:14:42.800067  4994 cgroups.cpp:2444] Thawing cgroup 
/sys/fs/cgroup/freezer/mesos/a5645a24-5c3f-4108-9292-5aaea1957415
I1124 21:14:42.803014  4988 cgroups.cpp:1438] Successfullly thawed cgroup 

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024491#comment-15024491
 ] 

haosdent commented on MESOS-3966:
-

The copy spents 28 seconds. So await_ready(15 seconds) timeout then failed.
{noformat}
I1124 21:14:11.151124  4993 copy.cpp:127] Copying layer path 
'/tmp/9rIY9c/test_image_rootfs' to rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e831d1fe-d204-4970-9b77-dd8fdb29bcb6'
I1124 21:14:39.070953  4991 provisioner.cpp:287] Provisioning image rootfs 
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_NvYS1w/provisioner/containers/a5645a24-5c3f-4108-9292-5aaea1957415/backends/copy/rootfses/e2f98f17-269c-49f5-85e3-54bef736852a'
 for container a5645a24-5c3f-4108-9292-5aaea1957415

{noformat}

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 

[jira] [Updated] (MESOS-3470) UserCgroupIsolatorTest failed on CentOS 6.6

[Bernd Mathiske (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Mathiske updated MESOS-3470:
--
Target Version/s: 0.26.0

> UserCgroupIsolatorTest failed on CentOS 6.6
> ---
>
> Key: MESOS-3470
> URL: https://issues.apache.org/jira/browse/MESOS-3470
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
>
> UserCgroupIsolatorTest use /sys/fs/cgroup as cgroups_hierarchy. But CentOS 
> 6.6 cgroups_hierarchy is /cgroup. Need change to follow the way in 
> ContainerizerTest.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3989) Add missing DiscoveryInfo field to v1/mesos.proto

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024536#comment-15024536
 ] 

Bernd Mathiske commented on MESOS-3989:
---

v1 is the first major version of the HTTP API. Its version number (v1) can stay 
the same across multiple Mesos releases provided no incompatible change is 
introduced. Then we'd move on to v2, but still support v1. You can also regard 
the original non-v protos as v0.


> Add missing DiscoveryInfo field to v1/mesos.proto
> -
>
> Key: MESOS-3989
> URL: https://issues.apache.org/jira/browse/MESOS-3989
> Project: Mesos
>  Issue Type: Bug
>  Components: framework, master
>Affects Versions: 0.26.0
>Reporter: haosdent
>Assignee: haosdent
>
> In https://reviews.apache.org/r/37022/ , we missed add 
> DiscoveryInfo.Visibility to v1/mesos.proto.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3177) Dynamic roles/weights configuration at runtime

[Yong Qiao Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024538#comment-15024538
 ] 

Yong Qiao Wang commented on MESOS-3177:
---

[~adam-mesos], can you help review the related patches with REVIEWABLE status? 
Thanks!

> Dynamic roles/weights configuration at runtime
> --
>
> Key: MESOS-3177
> URL: https://issues.apache.org/jira/browse/MESOS-3177
> Project: Mesos
>  Issue Type: Epic
>  Components: master, slave
>Reporter: Cody Maloney
>Assignee: Yong Qiao Wang
>  Labels: mesosphere
>
> All roles and weights must currently be specified up-front when starting 
> Mesos masters currently. In addition, they should be consistent on every 
> master, otherwise unexpected behavior could occur (You can have them be 
> inconsistent for some upgrade paths / changing the set).
> This makes it hard to introduce new groups of machines under new roles 
> dynamically (Have to generate a new master configuration, deploy that, before 
> we can connect slaves with a new role to the cluster).
> Ideally an administrator can manually add / remove / edit roles and have the 
> settings replicated / passed to all masters in the cluster by Mesos. 
> Effectively Mesos takes ownership of the setting, rather than requiring it to 
> be done externally.
> In addition, if a new slave joins the cluster with an unexpected / new role 
> that should just work, making it much easier to introduce machines with new 
> roles. (Policy around whether or not a slave can cause creation of a new 
> role, a given slave can register with a given role, etc. is out of scope, and 
> would be controls in the general registration process).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3470) UserCgroupIsolatorTest failed on CentOS 6.6

[Bernd Mathiske (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024550#comment-15024550
 ] 

Bernd Mathiske commented on MESOS-3470:
---

[~haosd...@gmail.com] Thanks for finding the fix! As discussed with you, we are 
going to apply [~arojas] patch which is based on yours, with minor edits.

https://reviews.apache.org/r/40643/


> UserCgroupIsolatorTest failed on CentOS 6.6
> ---
>
> Key: MESOS-3470
> URL: https://issues.apache.org/jira/browse/MESOS-3470
> Project: Mesos
>  Issue Type: Bug
>Reporter: haosdent
>Assignee: haosdent
>
> UserCgroupIsolatorTest use /sys/fs/cgroup as cgroups_hierarchy. But CentOS 
> 6.6 cgroups_hierarchy is /cgroup. Need change to follow the way in 
> ContainerizerTest.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024564#comment-15024564
 ] 

haosdent commented on MESOS-3937:
-

Could not reproduce this in physical machine. Going to try vagrant. Maybe this 
is a flaky test case?

> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
>  Issue Type: Bug
>  Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in 
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to 
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to 
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status 
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master 
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on 
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/40AlT8/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="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master" 
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5' 
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to 
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos 
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is 
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a

[jira] [Commented] (MESOS-3989) Add missing DiscoveryInfo field to v1/mesos.proto

[Klaus Ma (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024529#comment-15024529
 ] 

Klaus Ma commented on MESOS-3989:
-

Just one question about {{v1}} API: what's the scope of {{v1}} API? Does it 
mean we should add new version in new release?

> Add missing DiscoveryInfo field to v1/mesos.proto
> -
>
> Key: MESOS-3989
> URL: https://issues.apache.org/jira/browse/MESOS-3989
> Project: Mesos
>  Issue Type: Bug
>  Components: framework, master
>Affects Versions: 0.26.0
>Reporter: haosdent
>Assignee: haosdent
>
> In https://reviews.apache.org/r/37022/ , we missed add 
> DiscoveryInfo.Visibility to v1/mesos.proto.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3963) Move "using mesos::fetcher::FetcherInfo" into internal namespace in "fetcher.hpp"

[Klaus Ma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Klaus Ma updated MESOS-3963:

Shepherd: Michael Park

> Move "using mesos::fetcher::FetcherInfo" into internal namespace in 
> "fetcher.hpp"
> -
>
> Key: MESOS-3963
> URL: https://issues.apache.org/jira/browse/MESOS-3963
> Project: Mesos
>  Issue Type: Bug
>  Components: fetcher
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>Priority: Minor
>  Labels: newbie
>
> According to the google code style, the using should be used in internal 
> namespace in header files. Grep the header files, only fetcher.hpp deserved a 
> path.
> {quote}
> You may use a using-declaration anywhere in a .cc file (including in the 
> global namespace), and in functions, methods, classes, or within internal 
> namespaces in .h files.
> Do not use using-declarations in .h files except in explicitly marked 
> internal-only namespaces, because anything imported into a namespace in a .h 
> file becomes part of the public API exported by that file.
> {code}
> // OK in .cc files.
> // Must be in a function, method, internal namespace, or
> // class in .h files.
> using ::foo::bar;
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15024560#comment-15024560
 ] 

haosdent commented on MESOS-3966:
-

Maybe because you don't use sudo when test? I remember 
LinuxFilesystemIsolatorProcess only used when sudo and linux.

> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on 
> Centos 7.1
> 
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Jan Schlicht
>  Labels: mesosphere
>
> {noformat}
> [ RUN  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
>  a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality 
> `Delegate` was introduced in Version `218`. Your system may not function 
> properly; however since some distributions have patched systemd packages, 
> your system may still be functional. This is why we keep running. See 
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice 
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container 
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of 
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs 
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
>  for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem 
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> 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.hostname = "centos71"
>   config.vm.box = "bento/centos-7.1"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
>   end
>   config.vm.provision "shell", inline: <<-SHELL
>  sudo yum -y update systemd
>  sudo yum install -y tar wget
>  sudo wget 
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo 
> -O /etc/yum.repos.d/epel-apache-maven.repo
>  sudo yum groupinstall -y "Development Tools"
>  sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel 
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 
> apr-devel subversion-devel apr-util-devel
>  sudo yum install -y git
>  sudo yum install -y docker
>  sudo service docker start
>  sudo docker info
>  #sudo wget -qO- https://get.docker.com/ | sh
>   SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone  https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing 
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)