date:20151119

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

2015-11-19 Thread Matthias Veit (JIRA)


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

Matthias Veit commented on MESOS-3793:
--

Hey Jojy,

don't know if this is related to the docker linux host os. I tried several 
different ones all with the same result. Also on Ubuntu 14.04. 

Steps to reproduce:
{noformat}
$> docker run -it java:8-jdk /bin/bash
$> apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
echo "deb http://repos.mesosphere.io/debian jessie main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
echo "deb http://dl.bintray.com/sbt/debian /" | tee -a 
/etc/apt/sources.list.d/sbt.list && \
apt-get update && \
apt-get install --no-install-recommends -y --force-yes 
mesos=0.25.0-0.2.70.debian81
$> mesos local
{noformat}
 
After doing this, you should see the very same result.

> 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

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

2015-11-19 Thread Matthias Veit (JIRA)


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

Matthias Veit edited comment on MESOS-3793 at 11/19/15 8:29 AM:


Hey Jojy,

don't know if this is related to the docker linux host os. I tried several 
different ones all with the same result. Also on Ubuntu 14.04. 

Steps to reproduce:
{noformat}
$> docker run -it java:8-jdk /bin/bash
$> apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
echo "deb http://repos.mesosphere.io/debian jessie main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
echo "deb http://dl.bintray.com/sbt/debian /" | tee -a 
/etc/apt/sources.list.d/sbt.list && \
apt-get update && \
apt-get install --no-install-recommends -y --force-yes 
mesos=0.25.0-0.2.70.debian81
$> mesos local
{noformat}
 
After doing this, you should see the very same result.
Just to be clear - this problem happens with 100% guarantee.
I do not supply any other options, env vars etc. to that process.
This is the exact same command chain used for Marathon integration tests.


was (Author: aquamatthias):
Hey Jojy,

don't know if this is related to the docker linux host os. I tried several 
different ones all with the same result. Also on Ubuntu 14.04. 

Steps to reproduce:
{noformat}
$> docker run -it java:8-jdk /bin/bash
$> apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
echo "deb http://repos.mesosphere.io/debian jessie main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
echo "deb http://dl.bintray.com/sbt/debian /" | tee -a 
/etc/apt/sources.list.d/sbt.list && \
apt-get update && \
apt-get install --no-install-recommends -y --force-yes 
mesos=0.25.0-0.2.70.debian81
$> mesos local
{noformat}
 
After doing this, you should see the very same result.

> 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, 
>

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

2015-11-19 Thread Matthias Veit (JIRA)


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

Matthias Veit commented on MESOS-3793:
--

Hey [~jojy] we can apply this workaround and it will work for our integration 
tests. Thanks.


> 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] [Updated] (MESOS-3914) Make request format consistent across endpoints

2015-11-19 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov updated MESOS-3914:
---
Epic Name: Endpoint Cleanup

> Make request format consistent across endpoints
> ---
>
> Key: MESOS-3914
> URL: https://issues.apache.org/jira/browse/MESOS-3914
> Project: Mesos
>  Issue Type: Epic
>  Components: master
>Reporter: Alexander Rukletsov
>  Labels: mesosphere, tech-debt
>
> We are inconsistent with the format of requests we expect for operator 
> endpoints. For example, dynamic reservations take a string 
> "slaveId={{}}={{}}", while maintenance 
> expects a {{JSON}} object representing {{maintenance::Schedule}} protobuf 
> directly.
> We should agree on the input: either we expect a string with key-value pairs, 
> where values can be {{JSON}} objects, or we request {{JSON}} directly.
> Once we agree on the approach, we should document the outcome and convert all 
> nonconformant endpoints via a deprecation cycle.



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

[jira] [Updated] (MESOS-3914) Make request format consistent across endpoints

2015-11-19 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov updated MESOS-3914:
---
Labels: http mesosphere tech-debt  (was: mesosphere tech-debt)

> Make request format consistent across endpoints
> ---
>
> Key: MESOS-3914
> URL: https://issues.apache.org/jira/browse/MESOS-3914
> Project: Mesos
>  Issue Type: Epic
>  Components: master
>Reporter: Alexander Rukletsov
>  Labels: http, mesosphere, tech-debt
>
> We are inconsistent with the format of requests we expect for operator 
> endpoints. For example, dynamic reservations take a string 
> "slaveId={{}}={{}}", while maintenance 
> expects a {{JSON}} object representing {{maintenance::Schedule}} protobuf 
> directly.
> We should agree on the input: either we expect a string with key-value pairs, 
> where values can be {{JSON}} objects, or we request {{JSON}} directly.
> Once we agree on the approach, we should document the outcome and convert all 
> nonconformant endpoints via a deprecation cycle.



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

[jira] [Commented] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS

2015-11-19 Thread Marco Massenzio (JIRA)


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

Marco Massenzio commented on MESOS-3928:


Agreed - I've asked [~greggomann] and [~jojy] to verify this would fail in 
{{0.25.x}} too and it's not a regression.

> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Timothy Chen
>Priority: Blocker
>  Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}} 
> privileges, causes segfaults when running Docker tests.
> Logs attached.



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

[jira] [Updated] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS

2015-11-19 Thread Marco Massenzio (JIRA)


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

Marco Massenzio updated MESOS-3928:
---
Assignee: Greg Mann  (was: Timothy Chen)

> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
>Priority: Blocker
>  Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}} 
> privileges, causes segfaults when running Docker tests.
> Logs attached.



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

[jira] [Commented] (MESOS-2000) Support libprocess tracing

2015-11-19 Thread James Peach (JIRA)


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

James Peach commented on MESOS-2000:


Is this being worked on? In 
https://github.com/tnachen/mesos/tree/libprocess_trace ?

> Support libprocess tracing 
> ---
>
> Key: MESOS-2000
> URL: https://issues.apache.org/jira/browse/MESOS-2000
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Timothy Chen
>
> Adding the ability to trace the libprocess calls adds a lot of opportunity 
> for easier debugging, help understanding how mesos work, profiling, and also 
> visualizations.
> Ideally we also want to include timing information as well.  



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

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

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske commented on MESOS-3937:
---

This is very helpful. Thanks again!

> 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
>
> {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 the leading master!
> I1117 15:08:09.296187 26399 master.cpp:1379]

[jira] [Created] (MESOS-3960) Cleanup and standardize quota endpoints

2015-11-19 Thread Alexander Rukletsov (JIRA)

Alexander Rukletsov created MESOS-3960:
--

 Summary: Cleanup and standardize quota endpoints
 Key: MESOS-3960
 URL: https://issues.apache.org/jira/browse/MESOS-3960
 Project: Mesos
  Issue Type: Improvement
  Components: master
Reporter: Alexander Rukletsov


Things I suggest to change for consistency and avoiding least surprise for 
operators. This includes:
* A single JSON object per request (with the force flag inside);
* force flag in the URL;
* Maybe introduce a schema or typed object per request.

For more background please check the corresponding epic: MESOS-3914



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

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

2015-11-19 Thread Vaibhav Khanduja (JIRA)


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

Vaibhav Khanduja commented on MESOS-3937:
-

Yes, it answers all the reasons ... another main reason was the way kernel was 
compiled with config parameters ..

Once you have the box up, try running docker with -c and -m parameters. If they 
work, the test cases ideally should also work ...

> 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
>
> {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

[jira] [Updated] (MESOS-3914) Make request format consistent across endpoints

2015-11-19 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov updated MESOS-3914:
---
Story Points:   (was: 5)

> Make request format consistent across endpoints
> ---
>
> Key: MESOS-3914
> URL: https://issues.apache.org/jira/browse/MESOS-3914
> Project: Mesos
>  Issue Type: Epic
>  Components: master
>Reporter: Alexander Rukletsov
>  Labels: http, mesosphere, tech-debt
>
> We are inconsistent with the format of requests we expect for operator 
> endpoints. For example, dynamic reservations take a string 
> "slaveId={{}}={{}}", while maintenance 
> expects a {{JSON}} object representing {{maintenance::Schedule}} protobuf 
> directly.
> We should agree on the input: either we expect a string with key-value pairs, 
> where values can be {{JSON}} objects, or we request {{JSON}} directly.
> Once we agree on the approach, we should document the outcome and convert all 
> nonconformant endpoints via a deprecation cycle.



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

[jira] [Created] (MESOS-3961) Consider equality behavior for DiskInfo resource

2015-11-19 Thread Neil Conway (JIRA)

Neil Conway created MESOS-3961:
--

 Summary: Consider equality behavior for DiskInfo resource
 Key: MESOS-3961
 URL: https://issues.apache.org/jira/browse/MESOS-3961
 Project: Mesos
  Issue Type: Bug
Reporter: Neil Conway
Priority: Minor


Relevant code:

{code}
bool operator==(const Resource::DiskInfo& left, const Resource::DiskInfo& right)
{
  // NOTE: We ignore 'volume' inside DiskInfo when doing comparison
  // because it describes how this resource will be used which has
  // nothing to do with the Resource object itself. A framework can
  // use this resource and specify different 'volume' every time it
  // uses it.
  if (left.has_persistence() != right.has_persistence()) {
return false;
  }

  if (left.has_persistence()) {
return left.persistence().id() == right.persistence().id();
  }

  return true;
}
{code}

A consequence of this behavior is that if you pass the wrong path to a 
`destroy-volume` request (but there is a persistent volume that otherwise 
matches the request), the path will be ignored and the volume will be 
destroyed. Not clear if that is undesirable, but it does seem surprising.



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

[jira] [Created] (MESOS-3962) Add labels to the message Port

2015-11-19 Thread Sargun Dhillon (JIRA)

Sargun Dhillon created MESOS-3962:
-

 Summary: Add labels to the message Port
 Key: MESOS-3962
 URL: https://issues.apache.org/jira/browse/MESOS-3962
 Project: Mesos
  Issue Type: Wish
Reporter: Sargun Dhillon
Priority: Minor


I want to add arbitrary labels to the message "Port". I have a few use cases 
for this:
1) I want to use it to drive isolators to install firewall rules associated 
with the port
2) I want to use it to drive third party components to be able to specify 
advertising information
3) I want to be able to able to use this to associate a deterministic virtual 
hostname with a given port

Ideally, once the task is launched, these labels would be immutable.



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

[jira] [Commented] (MESOS-3123) DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes

2015-11-19 Thread Timothy Chen (JIRA)


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

Timothy Chen commented on MESOS-3123:
-

commit d78db0658f36c0afea8db04c148ea82fdbfc6d7b
Author: Timothy Chen 
Date:   Thu Nov 19 15:59:36 2015 -0800

Disabled docker bridge executor test.

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

> DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
> ---
>
> Key: MESOS-3123
> URL: https://issues.apache.org/jira/browse/MESOS-3123
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, test
>Affects Versions: 0.23.0
> Environment: CentOS 7.1, CentOS 6.6, or Ubuntu 14.04
> Mesos 0.23.0-rc4 or today's master
> Docker 1.9
>Reporter: Adam B
>Assignee: Timothy Chen
>  Labels: mesosphere
>
> Fails the test and then crashes while trying to shutdown the slaves.
> {code}
> [ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged
> ../../src/tests/docker_containerizer_tests.cpp:618: Failure
> Value of: statusRunning.get().state()
>   Actual: TASK_LOST
> Expected: TASK_RUNNING
> ../../src/tests/docker_containerizer_tests.cpp:619: Failure
> Failed to wait 1mins for statusFinished
> ../../src/tests/docker_containerizer_tests.cpp:610: Failure
> Actual function call count doesn't match EXPECT_CALL(sched, 
> statusUpdate(, _))...
>  Expected: to be called twice
>Actual: called once - unsatisfied and active
> F0721 21:59:54.950773 30622 logging.cpp:57] RAW: Pure virtual method called
> @ 0x7f3915347a02  google::LogMessage::Fail()
> @ 0x7f391534cee4  google::RawLog__()
> @ 0x7f3914890312  __cxa_pure_virtual
> @   0x88c3ae  mesos::internal::tests::Cluster::Slaves::shutdown()
> @   0x88c176  mesos::internal::tests::Cluster::Slaves::~Slaves()
> @   0x88dc16  mesos::internal::tests::Cluster::~Cluster()
> @   0x88dc87  mesos::internal::tests::MesosTest::~MesosTest()
> @   0xa529ab  
> mesos::internal::tests::DockerContainerizerTest::~DockerContainerizerTest()
> @   0xa8125f  
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @   0xa8128e  
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @  0x1218b4e  testing::Test::DeleteSelf_()
> @  0x1221909  
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @  0x121cb38  
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @  0x1205713  testing::TestInfo::Run()
> @  0x1205c4e  testing::TestCase::Run()
> @  0x120a9ca  testing::internal::UnitTestImpl::RunAllTests()
> @  0x122277b  
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @  0x121d81b  
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @  0x120987a  testing::UnitTest::Run()
> @   0xcfbf0c  main
> @ 0x7f391097caf5  __libc_start_main
> @   0x882089  (unknown)
> make[3]: *** [check-local] Aborted (core dumped)
> make[3]: Leaving directory `/home/me/mesos/build/src'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/home/me/mesos/build/src'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory `/home/me/mesos/build/src'
> make: *** [check-recursive] Error 1
> {code}



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

[jira] [Commented] (MESOS-3961) Consider equality behavior for DiskInfo resource

2015-11-19 Thread Jie Yu (JIRA)


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

Jie Yu commented on MESOS-3961:
---

The container path in the volume will be ignored because, as the note stated, 
how this resource is used has nothing to do with the Resource object itself 
(and it's equality check). We'll still check if persistence id matches or not 
before deleting the disk resource with persistent volume.

> Consider equality behavior for DiskInfo resource
> 
>
> Key: MESOS-3961
> URL: https://issues.apache.org/jira/browse/MESOS-3961
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Priority: Minor
>  Labels: mesosphere, persistent-volumes
>
> Relevant code:
> {code}
> bool operator==(const Resource::DiskInfo& left, const Resource::DiskInfo& 
> right)
> {
>   // NOTE: We ignore 'volume' inside DiskInfo when doing comparison
>   // because it describes how this resource will be used which has
>   // nothing to do with the Resource object itself. A framework can
>   // use this resource and specify different 'volume' every time it
>   // uses it.
>   if (left.has_persistence() != right.has_persistence()) {
> return false;
>   }
>   if (left.has_persistence()) {
> return left.persistence().id() == right.persistence().id();
>   }
>   return true;
> }
> {code}
> A consequence of this behavior is that if you pass the wrong path to a 
> `destroy-volume` request (but there is a persistent volume that otherwise 
> matches the request), the path will be ignored and the volume will be 
> destroyed. Not clear if that is undesirable, but it does seem surprising.



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

[jira] [Commented] (MESOS-3961) Consider equality behavior for DiskInfo resource

2015-11-19 Thread Neil Conway (JIRA)


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

Neil Conway commented on MESOS-3961:


This just seems like surprising behavior: if I create a PV with  and try to delete the PV with , there is a 
reasonably good chance I've made a mistake and I was actually trying to delete 
a different volume.

Put another way, it seems confusing to *require* that a user specifies 
container_path when deleting a PV, but then to ignore the path when we actually 
evaluate the deletion operation.

> Consider equality behavior for DiskInfo resource
> 
>
> Key: MESOS-3961
> URL: https://issues.apache.org/jira/browse/MESOS-3961
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Priority: Minor
>  Labels: mesosphere, persistent-volumes
>
> Relevant code:
> {code}
> bool operator==(const Resource::DiskInfo& left, const Resource::DiskInfo& 
> right)
> {
>   // NOTE: We ignore 'volume' inside DiskInfo when doing comparison
>   // because it describes how this resource will be used which has
>   // nothing to do with the Resource object itself. A framework can
>   // use this resource and specify different 'volume' every time it
>   // uses it.
>   if (left.has_persistence() != right.has_persistence()) {
> return false;
>   }
>   if (left.has_persistence()) {
> return left.persistence().id() == right.persistence().id();
>   }
>   return true;
> }
> {code}
> A consequence of this behavior is that if you pass the wrong path to a 
> `destroy-volume` request (but there is a persistent volume that otherwise 
> matches the request), the path will be ignored and the volume will be 
> destroyed. Not clear if that is undesirable, but it does seem surprising.



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

[jira] [Updated] (MESOS-3914) Make request format consistent across endpoints

2015-11-19 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov updated MESOS-3914:
---
Issue Type: Epic  (was: Improvement)

> Make request format consistent across endpoints
> ---
>
> Key: MESOS-3914
> URL: https://issues.apache.org/jira/browse/MESOS-3914
> Project: Mesos
>  Issue Type: Epic
>  Components: master
>Reporter: Alexander Rukletsov
>  Labels: mesosphere, tech-debt
>
> We are inconsistent with the format of requests we expect for operator 
> endpoints. For example, dynamic reservations take a string 
> "slaveId={{}}={{}}", while maintenance 
> expects a {{JSON}} object representing {{maintenance::Schedule}} protobuf 
> directly.
> We should agree on the input: either we expect a string with key-value pairs, 
> where values can be {{JSON}} objects, or we request {{JSON}} directly.
> Once we agree on the approach, we should document the outcome and convert all 
> nonconformant endpoints via a deprecation cycle.



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

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

2015-11-19 Thread Vaibhav Khanduja (JIRA)


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

Vaibhav Khanduja commented on MESOS-3937:
-

Can this bug be taken as documentation issue? With contribution page 
recommending right Ubuntu (vagrant) images.

> 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
>
> {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

[jira] [Assigned] (MESOS-3476) Refactor Status Update method on Agent to handle HTTP based Executors

2015-11-19 Thread Anand Mazumdar (JIRA)


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

Anand Mazumdar reassigned MESOS-3476:
-

Assignee: Anand Mazumdar  (was: Isabel Jimenez)

> Refactor Status Update method on Agent to handle HTTP based Executors
> -
>
> Key: MESOS-3476
> URL: https://issues.apache.org/jira/browse/MESOS-3476
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Anand Mazumdar
>  Labels: mesosphere
>
> Currently, receiving a status update sent from slave to itself , {{runTask}} 
> , {{killTask}} and status updates from executors are handled by the 
> {{Slave::statusUpdate}} method on Slave. The signature of the method is 
> {{void Slave::statusUpdate(StatusUpdate update, const UPID& pid)}}. 
> We need to create another overload of it that can also handle HTTP based 
> executors which the previous PID based function can also call into. The 
> signature of the new function could be:
> {{void Slave::statusUpdate(StatusUpdate update, Executor* executor)}}
> The HTTP Executor would also call into this new function via 
> {{src/slave/http.cpp}}



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

[jira] [Commented] (MESOS-3961) Consider equality behavior for DiskInfo resource

2015-11-19 Thread Jie Yu (JIRA)


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

Jie Yu commented on MESOS-3961:
---

Yeah, I agree that's an unfortunate situation. Also, I've got questions like 
why the user has to specify a 'volume' when creating a persistent disk resource 
(but not yet launching a task). I think we need to re-think those problems. 
Thanks for filing the ticket.

>From the implementation perspective, we did that because the master will 
>perform 'contains' check to make sure a task is not using resources that are 
>not offered to it. If we don't ignore 'volume', that means the framework 
>cannot change 'container_path' once the volume is created. That's a bit 
>unfortunate as well.

> Consider equality behavior for DiskInfo resource
> 
>
> Key: MESOS-3961
> URL: https://issues.apache.org/jira/browse/MESOS-3961
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Priority: Minor
>  Labels: mesosphere, persistent-volumes
>
> Relevant code:
> {code}
> bool operator==(const Resource::DiskInfo& left, const Resource::DiskInfo& 
> right)
> {
>   // NOTE: We ignore 'volume' inside DiskInfo when doing comparison
>   // because it describes how this resource will be used which has
>   // nothing to do with the Resource object itself. A framework can
>   // use this resource and specify different 'volume' every time it
>   // uses it.
>   if (left.has_persistence() != right.has_persistence()) {
> return false;
>   }
>   if (left.has_persistence()) {
> return left.persistence().id() == right.persistence().id();
>   }
>   return true;
> }
> {code}
> A consequence of this behavior is that if you pass the wrong path to a 
> `destroy-volume` request (but there is a persistent volume that otherwise 
> matches the request), the path will be ignored and the volume will be 
> destroyed. Not clear if that is undesirable, but it does seem surprising.



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

[jira] [Commented] (MESOS-3753) Test the HTTP Scheduler library with SSL enabled

2015-11-19 Thread Joseph Wu (JIRA)


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

Joseph Wu commented on MESOS-3753:
--

More test cleanup, discovered while prototyping {{libprocess::finalize}}:
https://reviews.apache.org/r/40501/

> Test the HTTP Scheduler library with SSL enabled
> 
>
> Key: MESOS-3753
> URL: https://issues.apache.org/jira/browse/MESOS-3753
> Project: Mesos
>  Issue Type: Story
>  Components: framework, HTTP API, test
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere, security
>
> Currently, the HTTP Scheduler library does not support SSL-enabled Mesos.  
> (You can manually test this by spinning up an SSL-enabled master and attempt 
> to run the event-call framework example against it.)
> We need to add tests that check the HTTP Scheduler library against 
> SSL-enabled Mesos:
> * with downgrade support,
> * with required framework/client-side certifications,
> * with/without verification of certificates (master-side),
> * with/without verification of certificates (framework-side),
> * with a custom certificate authority (CA)
> These options should be controlled by the same environment variables found on 
> the [SSL user doc|http://mesos.apache.org/documentation/latest/ssl/].
> Note: This issue will be broken down into smaller sub-issues as bugs/problems 
> are discovered.



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

[jira] [Commented] (MESOS-3753) Test the HTTP Scheduler library with SSL enabled

2015-11-19 Thread Joseph Wu (JIRA)


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

Joseph Wu commented on MESOS-3753:
--

More test cleanup.  This time discovered by cleaning up every process managed 
by libprocess between every test:
https://reviews.apache.org/r/40507/

> Test the HTTP Scheduler library with SSL enabled
> 
>
> Key: MESOS-3753
> URL: https://issues.apache.org/jira/browse/MESOS-3753
> Project: Mesos
>  Issue Type: Story
>  Components: framework, HTTP API, test
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere, security
>
> Currently, the HTTP Scheduler library does not support SSL-enabled Mesos.  
> (You can manually test this by spinning up an SSL-enabled master and attempt 
> to run the event-call framework example against it.)
> We need to add tests that check the HTTP Scheduler library against 
> SSL-enabled Mesos:
> * with downgrade support,
> * with required framework/client-side certifications,
> * with/without verification of certificates (master-side),
> * with/without verification of certificates (framework-side),
> * with a custom certificate authority (CA)
> These options should be controlled by the same environment variables found on 
> the [SSL user doc|http://mesos.apache.org/documentation/latest/ssl/].
> Note: This issue will be broken down into smaller sub-issues as bugs/problems 
> are discovered.



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

[jira] [Comment Edited] (MESOS-3957) Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske edited comment on MESOS-3957 at 11/19/15 3:14 PM:
-

Vagrantfile used for the above run:

{noformat}
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "debian/jessie64"
  config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
  end
  config.vm.provision "shell", inline: <<-SHELL
sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
docker.list
sudo mv docker.list /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install -y openjdk-7-jdk autoconf libtool
sudo apt-get -y install build-essential python-dev python-boto 
libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
sudo apt-get install -y docker.io

#enable memory cgroup:
sudo sed -i "s/quiet/quiet cgroup_enable=memory/g" /etc/default/grub
sudo update-grub
  SHELL
end
{noformat}
Reboot once to make the above grub change take affect!



was (Author: bernd-mesos):
Vagrantfile used for the above run:

{noformat}
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "debian/jessie64"
  config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
  end
  config.vm.provision "shell", inline: <<-SHELL
sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
docker.list
sudo mv docker.list /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install -y openjdk-7-jdk autoconf libtool
sudo apt-get -y install build-essential python-dev python-boto 
libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
sudo apt-get install -y docker.io
  SHELL
end
{noformat}

> Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.
> -
>
> Key: MESOS-3957
> URL: https://issues.apache.org/jira/browse/MESOS-3957
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, test
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
>Reporter: Bernd Mathiske
>  Labels: mesosphere
>
> Running sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Usage" --verbose, we get:
> {noformat}
> [ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Usage
> I1119 13:52:58.323119 25447 leveldb.cpp:176] Opened db in 45.2273ms
> I1119 13:52:58.333658 25447 leveldb.cpp:183] Compacted db in 10.355657ms
> I1119 13:52:58.333791 25447 leveldb.cpp:198] Created db iterator in 61701ns
> I1119 13:52:58.333822 25447 leveldb.cpp:204] Seeked to beginning of db in 
> 4251ns
> I1119 13:52:58.333837 25447 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 442ns
> I1119 13:52:58.333982 25447 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1119 13:52:58.336284 25462 recover.cpp:449] Starting replica recovery
> I1119 13:52:58.337008 25462 recover.cpp:475] Replica is in EMPTY status
> I1119 13:52:58.339164 25465 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@127.0.1.1:40834
> I1119 13:52:58.340235 25466 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1119 13:52:58.341146 25461 recover.cpp:566] Updating replica status to 
> STARTING
> I1119 13:52:58.342461 25465 master.cpp:367] Master 
> f78e3b28-c45c-4b5b-b6d9-2734247272ee (debian-jessie.vagrantup.com) started on 
> 127.0.1.1:40834
> I1119 13:52:58.342586 25465 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/3OqRd1/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/3OqRd1/master" 
> --zk_session_timeout="10secs"
> I1119 13:52:58.343490 25465 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1119 13:52:58.343511 25465 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1119 13:52:58.343523 25465 credentials.hpp:37] Loading credentials for 
> authentication from

[jira] [Created] (MESOS-3959) Executor page of mesos ui does not show slave hostname

2015-11-19 Thread Ian Babrou (JIRA)

Ian Babrou created MESOS-3959:
-

 Summary: Executor page of mesos ui does not show slave hostname
 Key: MESOS-3959
 URL: https://issues.apache.org/jira/browse/MESOS-3959
 Project: Mesos
  Issue Type: Bug
  Components: webui
Reporter: Ian Babrou


This is not really convenient.



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

[jira] [Commented] (MESOS-3959) Executor page of mesos ui does not show slave hostname

2015-11-19 Thread Ian Babrou (JIRA)


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

Ian Babrou commented on MESOS-3959:
---

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

> Executor page of mesos ui does not show slave hostname
> --
>
> Key: MESOS-3959
> URL: https://issues.apache.org/jira/browse/MESOS-3959
> Project: Mesos
>  Issue Type: Bug
>  Components: webui
>Reporter: Ian Babrou
>
> This is not really convenient.



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

[jira] [Updated] (MESOS-2081) Add safety constraints for maintenance primitives.

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-2081:

Assignee: (was: Klaus Ma)

> Add safety constraints for maintenance primitives.
> --
>
> Key: MESOS-2081
> URL: https://issues.apache.org/jira/browse/MESOS-2081
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Benjamin Mahler
>  Labels: twitter
>
> In order to ensure that the maintenance primitives can be used safely by 
> operators, we want to put a few safety mechanisms in place. Some ideas from 
> the [design 
> doc|https://docs.google.com/a/twitter.com/document/d/16k0lVwpSGVOyxPSyXKmGC-gbNmRlisNEe4p-fAUSojk/]:
> # Prevent bad schedules from being constructed: schedules with more than x% 
> overlap in slaves are rejected.
> # Prevent bad maintenance from proceeding unchecked: if x% of the slaves are 
> not being unscheduled, or are not re-registering, cancel the schedule.
> These will likely be configurable via flags.



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

[jira] [Updated] (MESOS-3420) Resolve shutdown semantics for Machine/Down

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-3420:

Assignee: (was: Klaus Ma)

> Resolve shutdown semantics for Machine/Down
> ---
>
> Key: MESOS-3420
> URL: https://issues.apache.org/jira/browse/MESOS-3420
> Project: Mesos
>  Issue Type: Task
>Reporter: Joris Van Remoortere
>  Labels: maintenance, mesosphere
>
> When an operator uses the {{machine/down}} endpoint, the master sends a 
> shutdown message to the agent.
> We need to discuss and resolve the semantics that we want regarding the 
> operators and frameworks knowing when their tasks are terminated.
> One option is to explicitly remove the agent from the master which will send 
> the {{TASK_LOST}} updates and {{SlaveLostMessage}} directly from the master. 
> The concern around this is that during a network partition, or if the agent 
> was down at the time, that these tasks could still be running.
> This is a general problem related to task life-times being dissociated with 
> that life-time of the agent.



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

[jira] [Updated] (MESOS-3472) RegistryTokenTest.ExpiredToken test is flaky

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-3472:

Assignee: (was: Klaus Ma)

> RegistryTokenTest.ExpiredToken test is flaky
> 
>
> Key: MESOS-3472
> URL: https://issues.apache.org/jira/browse/MESOS-3472
> Project: Mesos
>  Issue Type: Bug
>Reporter: Artem Harutyunyan
>  Labels: flaky, mesosphere
>
> RegistryTokenTest.ExpiredToken test is flaky. Here is the error I got on OSX 
> after running it for several times:
> {noformat}
> [ RUN  ] RegistryTokenTest.ExpiredToken
> ../../src/tests/containerizer/provisioner_docker_tests.cpp:167: Failure
> Value of: token.isError()
>   Actual: false
> Expected: true
> libc++abi.dylib: terminating with uncaught exception of type 
> testing::internal::GoogleTestFailureException: 
> ../../src/tests/containerizer/provisioner_docker_tests.cpp:167: Failure
> Value of: token.isError()
>   Actual: false
> Expected: true
> *** Aborted at 1442708631 (unix time) try "date -d @1442708631" if you are 
> using GNU date ***
> PC: @ 0x7fff925fd286 __pthread_kill
> *** SIGABRT (@0x7fff925fd286) received by PID 7082 (TID 0x7fff7d7ad300) stack 
> trace: ***
> @ 0x7fff9041af1a _sigtramp
> @ 0x7fff59759968 (unknown)
> @ 0x7fff9bb429b3 abort
> @ 0x7fff90ce1a21 abort_message
> @ 0x7fff90d099b9 default_terminate_handler()
> @ 0x7fff994767eb _objc_terminate()
> @ 0x7fff90d070a1 std::__terminate()
> @ 0x7fff90d06d48 __cxa_rethrow
> @0x10781bb16 
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @0x1077e9d30 testing::UnitTest::Run()
> @0x106d59a91 RUN_ALL_TESTS()
> @0x106d55d47 main
> @ 0x7fff8fc395c9 start
> @0x3 (unknown)
> Abort trap: 6
> ~/src/mesos/build ((3ee82e3...)) $
> {noformat}



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

[jira] [Updated] (MESOS-2941) Add a benchmark for task reconciliation.

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-2941:

Assignee: (was: Klaus Ma)

> Add a benchmark for task reconciliation.
> 
>
> Key: MESOS-2941
> URL: https://issues.apache.org/jira/browse/MESOS-2941
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Benjamin Mahler
>  Labels: twitter
>
> Per MESOS-2940, it would be great to have a benchmark for task 
> reconciliation, given large numbers of tasks.
> This can guide attempts at improving performance.



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

[jira] [Updated] (MESOS-3580) Refactor 'protobuf' to accept project function

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-3580:

Assignee: (was: Klaus Ma)

> Refactor 'protobuf' to accept project function
> --
>
> Key: MESOS-3580
> URL: https://issues.apache.org/jira/browse/MESOS-3580
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Klaus Ma
>  Labels: refactor, stout
>
> During the code review of MESOS-3405, [~alex-mesos] realized that we use the 
> same pattern again and again, for example:
> {code}
> JSON::Array array;
> array.values.reserve(status.network_infos().size()); // MESOS-2353.
> foreach (const NetworkInfo& info, status.network_infos()) {
>   array.values.push_back(model(info));
> }
> object.values["network_infos"] = std::move(array);
> {code}
> We cannot use newly added {{JSON::protobuf()}} here, because a different way 
> for rendering JSON from protobuf is used. Without digging deep inside, I know 
> three ways how we create a JSON out of a proto in our codebase:
> - wrap in {{JSON::Protobuf()}} for individual messages;
> - wrap in one of the model() family functions;
> - pass as it is for built-in types.
> The proposed conversion function covers one of the possible ways. How about 
> add one more convertion? Something like:
> {code}
> template 
> Array protobuf(const google::protobuf::RepeatedPtrField& repeated,
> const lambda::function(const T&)>& converter)
> {
>   static_assert(std::is_convertible::value,
> "T must be a google::protobuf::Message");
>   JSON::Array array;
>   array.values.reserve(repeated.size());
>   foreach (const T& elem, repeated) {
> array.values.push_back(converter(elem));
>   }
>   return array;
> }
> {code}
> Then the snippet above could be rewritten as:
> {code}
> object.values["network_infos"] = 
> std::move(JSON::protobuf(status.network_infos(),
> [](const NetworkInfo& info) { return model(info); });
> {code}



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

[jira] [Updated] (MESOS-3750) ContentType/SchedulerTest.ShutdownExecutor/0 is flaky

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma updated MESOS-3750:

Assignee: (was: Klaus Ma)

> ContentType/SchedulerTest.ShutdownExecutor/0 is flaky
> -
>
> Key: MESOS-3750
> URL: https://issues.apache.org/jira/browse/MESOS-3750
> Project: Mesos
>  Issue Type: Bug
>Reporter: Anand Mazumdar
>  Labels: flaky-test
>
> Showed up on ASF CI:
> https://builds.apache.org/job/Mesos/942/COMPILER=gcc,CONFIGURATION=--verbose,OS=centos:7,label_exp=docker%7C%7CHadoop/consoleFull
> {code}
> [ RUN  ] ContentType/SchedulerTest.ShutdownExecutor/0
> Using temporary directory 
> '/tmp/ContentType_SchedulerTest_ShutdownExecutor_0_AEwZqa'
> I1016 12:51:41.421211 30336 leveldb.cpp:176] Opened db in 131.548926ms
> I1016 12:51:41.480257 30336 leveldb.cpp:183] Compacted db in 58.993935ms
> I1016 12:51:41.480355 30336 leveldb.cpp:198] Created db iterator in 28351ns
> I1016 12:51:41.480376 30336 leveldb.cpp:204] Seeked to beginning of db in 
> 2740ns
> I1016 12:51:41.480388 30336 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 493ns
> I1016 12:51:41.480445 30336 replica.cpp:746] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1016 12:51:41.481050 30359 recover.cpp:449] Starting replica recovery
> I1016 12:51:41.481324 30359 recover.cpp:475] Replica is in EMPTY status
> I1016 12:51:41.482493 30360 replica.cpp:642] Replica in EMPTY status received 
> a broadcasted recover request from (9945)@172.17.7.238:34368
> I1016 12:51:41.482924 30363 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1016 12:51:41.483568 30361 recover.cpp:566] Updating replica status to 
> STARTING
> I1016 12:51:41.485028 30365 master.cpp:376] Master 
> 3684704c-615f-4f62-b45c-b7ae0cb8176f (635f798fc895) started on 
> 172.17.7.238:34368
> I1016 12:51:41.485051 30365 master.cpp:378] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/ContentType_SchedulerTest_ShutdownExecutor_0_AEwZqa/credentials"
>  --framework_sorter="drf" --help="false" --hostname_lookup="true" 
> --initialize_driver_logging="true" --log_auto_initialize="true" 
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5" 
> --quiet="false" --recovery_slave_removal_limit="100%" 
> --registry="replicated_log" --registry_fetch_timeout="1mins" 
> --registry_store_timeout="25secs" --registry_strict="true" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/ContentType_SchedulerTest_ShutdownExecutor_0_AEwZqa/master" 
> --zk_session_timeout="10secs"
> I1016 12:51:41.485404 30365 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1016 12:51:41.485419 30365 master.cpp:428] Master only allowing 
> authenticated slaves to register
> I1016 12:51:41.485429 30365 credentials.hpp:37] Loading credentials for 
> authentication from 
> '/tmp/ContentType_SchedulerTest_ShutdownExecutor_0_AEwZqa/credentials'
> I1016 12:51:41.485692 30365 master.cpp:467] Using default 'crammd5' 
> authenticator
> I1016 12:51:41.485827 30365 master.cpp:504] Authorization enabled
> I1016 12:51:41.486111 30360 whitelist_watcher.cpp:79] No whitelist given
> I1016 12:51:41.486193 30358 hierarchical.cpp:140] Initialized hierarchical 
> allocator process
> I1016 12:51:41.487990 30356 master.cpp:1609] The newly elected leader is 
> master@172.17.7.238:34368 with id 3684704c-615f-4f62-b45c-b7ae0cb8176f
> I1016 12:51:41.488039 30356 master.cpp:1622] Elected as the leading master!
> I1016 12:51:41.488068 30356 master.cpp:1382] Recovering from registrar
> I1016 12:51:41.488278 30359 registrar.cpp:309] Recovering registrar
> I1016 12:51:41.524139 30368 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 40.300862ms
> I1016 12:51:41.524193 30368 replica.cpp:323] Persisted replica status to 
> STARTING
> I1016 12:51:41.524440 30368 recover.cpp:475] Replica is in STARTING status
> I1016 12:51:41.525777 30364 replica.cpp:642] Replica in STARTING status 
> received a broadcasted recover request from (9946)@172.17.7.238:34368
> I1016 12:51:41.526093 30357 recover.cpp:195] Received a recover response from 
> a replica in STARTING status
> I1016 12:51:41.526592 30365 recover.cpp:566] Updating replica status to VOTING
> I1016 12:51:41.582528 30361 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 55.827311ms
> I1016 12:51:41.582567 30361 replica.cpp:323] Persisted replica status to 
> VOTING
> I1016 12:51:41.582695 30361

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

2015-11-19 Thread Klaus Ma (JIRA)

Klaus Ma created MESOS-3963:
---

 Summary: 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
Priority: Minor


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-3963) Move "using mesos::fetcher::FetcherInfo" into internal namespace in "fetcher.hpp"

2015-11-19 Thread Klaus Ma (JIRA)


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

Klaus Ma commented on MESOS-3963:
-

{code}
./src/tests/mesos.hpp:using ::testing::_;
./src/tests/mesos.hpp:using ::testing::An;
./src/tests/mesos.hpp:using ::testing::DoDefault;
./src/tests/mesos.hpp:using ::testing::Invoke;
./src/tests/mesos.hpp:using ::testing::Return;
./src/tests/allocator.hpp:using ::testing::_;
./src/tests/allocator.hpp:using ::testing::An;
./src/tests/allocator.hpp:using ::testing::DoDefault;
./src/tests/allocator.hpp:using ::testing::Invoke;
./src/tests/allocator.hpp:using ::testing::Return;

./src/slave/containerizer/fetcher.hpp:using mesos::fetcher::FetcherInfo; // in 
global scope

./src/slave/slave.hpp:using namespace process; // in an internal namespace.

./3rdparty/libprocess/3rdparty/stout/include/stout/uuid.hpp:using id::UUID; // 
in namespace id, should be also addressed.

./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using std::bind;
./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using std::cref;
./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using 
std::function;
./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using std::ref;
./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using 
std::result_of;
./3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp:using namespace 
std::placeholders;
{code}

> 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
>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] [Updated] (MESOS-3955) Add helper function to get stateless resources.

2015-11-19 Thread Guangya Liu (JIRA)


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

Guangya Liu updated MESOS-3955:
---
Summary: Add helper function to get stateless resources.  (was: Identify 
optimistic offer revocable resources)

> Add helper function to get stateless resources.
> ---
>
> Key: MESOS-3955
> URL: https://issues.apache.org/jira/browse/MESOS-3955
> Project: Mesos
>  Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Guangya Liu
>




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

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

2015-11-19 Thread Jan Schlicht (JIRA)


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

Jan Schlicht commented on MESOS-3916:
-

It also happens on Fedora 23.
Compiled with {{--enable-optimized --enable-libevent --enable-ssl}}

> 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
>  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

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

2015-11-19 Thread Neil Conway (JIRA)


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

Neil Conway reassigned MESOS-3916:
--

Assignee: Neil Conway

> 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 
> leveldb

[jira] [Commented] (MESOS-3957) Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske commented on MESOS-3957:
---

Vagrantfile used for the above run:

{noformat}
> # -*- mode: ruby -*-" >
> # vi: set ft=ruby :
> Vagrant.configure(2) do |config|
>   config.vm.box = "debian/jessie64"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provision "shell", inline: <<-SHELL
> sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
> docker.list
> sudo mv docker.list /etc/apt/sources.list.d/
> sudo apt-get update
> sudo apt-get install -y openjdk-7-jdk autoconf libtool
> sudo apt-get -y install build-essential python-dev python-boto 
> libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
> sudo apt-get install -y docker.io
>   SHELL
> end
> EOF
rune-2:debian-8 bernd$ more Vagrantfile 
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "debian/jessie64"
  config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
  end
  config.vm.provision "shell", inline: <<-SHELL
sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
docker.list
sudo mv docker.list /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install -y openjdk-7-jdk autoconf libtool
sudo apt-get -y install build-essential python-dev python-boto 
libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
sudo apt-get install -y docker.io
  SHELL
end
{noformat}

> Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.
> -
>
> Key: MESOS-3957
> URL: https://issues.apache.org/jira/browse/MESOS-3957
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, test
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
>Reporter: Bernd Mathiske
>  Labels: mesosphere
>
> Running sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Usage" --verbose, we get:
> {noformat}
> [ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Usage
> I1119 13:52:58.323119 25447 leveldb.cpp:176] Opened db in 45.2273ms
> I1119 13:52:58.333658 25447 leveldb.cpp:183] Compacted db in 10.355657ms
> I1119 13:52:58.333791 25447 leveldb.cpp:198] Created db iterator in 61701ns
> I1119 13:52:58.333822 25447 leveldb.cpp:204] Seeked to beginning of db in 
> 4251ns
> I1119 13:52:58.333837 25447 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 442ns
> I1119 13:52:58.333982 25447 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1119 13:52:58.336284 25462 recover.cpp:449] Starting replica recovery
> I1119 13:52:58.337008 25462 recover.cpp:475] Replica is in EMPTY status
> I1119 13:52:58.339164 25465 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@127.0.1.1:40834
> I1119 13:52:58.340235 25466 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1119 13:52:58.341146 25461 recover.cpp:566] Updating replica status to 
> STARTING
> I1119 13:52:58.342461 25465 master.cpp:367] Master 
> f78e3b28-c45c-4b5b-b6d9-2734247272ee (debian-jessie.vagrantup.com) started on 
> 127.0.1.1:40834
> I1119 13:52:58.342586 25465 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/3OqRd1/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/3OqRd1/master" 
> --zk_session_timeout="10secs"
> I1119 13:52:58.343490 25465 master.cpp:414] Master only allowing 
> authenticated frameworks to register
> I1119 13:52:58.343511 25465 master.cpp:419] Master only allowing 
> authenticated slaves to register
> I1119 13:52:58.343523 25465 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/3OqRd1/credentials'
> I1119 13:52:58.353895 25466 leveldb.cpp:306] Persisting metadata (8 bytes) to 
> leveldb took 12.443751ms
> I1119 13:52:58.353961 25466 replica.cpp:323] Persisted replica status to 
> STARTING
> I1119

[jira] [Comment Edited] (MESOS-3957) Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske edited comment on MESOS-3957 at 11/19/15 2:02 PM:
-

Vagrantfile used for the above run:

{noformat}
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "debian/jessie64"
  config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
  end
  config.vm.provision "shell", inline: <<-SHELL
sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
docker.list
sudo mv docker.list /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install -y openjdk-7-jdk autoconf libtool
sudo apt-get -y install build-essential python-dev python-boto 
libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
sudo apt-get install -y docker.io
  SHELL
end
{noformat}


was (Author: bernd-mesos):
Vagrantfile used for the above run:

{noformat}
> # -*- mode: ruby -*-" >
> # vi: set ft=ruby :
> Vagrant.configure(2) do |config|
>   config.vm.box = "debian/jessie64"
>   config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
>   end
>   config.vm.provision "shell", inline: <<-SHELL
> sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
> docker.list
> sudo mv docker.list /etc/apt/sources.list.d/
> sudo apt-get update
> sudo apt-get install -y openjdk-7-jdk autoconf libtool
> sudo apt-get -y install build-essential python-dev python-boto 
> libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
> sudo apt-get install -y docker.io
>   SHELL
> end
> EOF
rune-2:debian-8 bernd$ more Vagrantfile 
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "debian/jessie64"
  config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
  end
  config.vm.provision "shell", inline: <<-SHELL
sudo echo "deb http://http.debian.net/debian jessie-backports main" > 
docker.list
sudo mv docker.list /etc/apt/sources.list.d/
sudo apt-get update
sudo apt-get install -y openjdk-7-jdk autoconf libtool
sudo apt-get -y install build-essential python-dev python-boto 
libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev
sudo apt-get install -y docker.io
  SHELL
end
{noformat}

> Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.
> -
>
> Key: MESOS-3957
> URL: https://issues.apache.org/jira/browse/MESOS-3957
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, test
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
>Reporter: Bernd Mathiske
>  Labels: mesosphere
>
> Running sudo ./bin/mesos-tests.sh 
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Usage" --verbose, we get:
> {noformat}
> [ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Usage
> I1119 13:52:58.323119 25447 leveldb.cpp:176] Opened db in 45.2273ms
> I1119 13:52:58.333658 25447 leveldb.cpp:183] Compacted db in 10.355657ms
> I1119 13:52:58.333791 25447 leveldb.cpp:198] Created db iterator in 61701ns
> I1119 13:52:58.333822 25447 leveldb.cpp:204] Seeked to beginning of db in 
> 4251ns
> I1119 13:52:58.333837 25447 leveldb.cpp:273] Iterated through 0 keys in the 
> db in 442ns
> I1119 13:52:58.333982 25447 replica.cpp:780] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1119 13:52:58.336284 25462 recover.cpp:449] Starting replica recovery
> I1119 13:52:58.337008 25462 recover.cpp:475] Replica is in EMPTY status
> I1119 13:52:58.339164 25465 replica.cpp:676] Replica in EMPTY status received 
> a broadcasted recover request from (4)@127.0.1.1:40834
> I1119 13:52:58.340235 25466 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1119 13:52:58.341146 25461 recover.cpp:566] Updating replica status to 
> STARTING
> I1119 13:52:58.342461 25465 master.cpp:367] Master 
> f78e3b28-c45c-4b5b-b6d9-2734247272ee (debian-jessie.vagrantup.com) started on 
> 127.0.1.1:40834
> I1119 13:52:58.342586 25465 master.cpp:369] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
> --authorizers="local" --credentials="/tmp/3OqRd1/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" 
>

[jira] [Created] (MESOS-3957) Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on Debian 8.

2015-11-19 Thread Bernd Mathiske (JIRA)

Bernd Mathiske created MESOS-3957:
-

 Summary: Test DockerContainerizerTest.ROOT_DOCKER_Usage fails on 
Debian 8.
 Key: MESOS-3957
 URL: https://issues.apache.org/jira/browse/MESOS-3957
 Project: Mesos
  Issue Type: Bug
  Components: docker, test
Affects Versions: 0.26.0
 Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
Reporter: Bernd Mathiske


Running sudo ./bin/mesos-tests.sh 
--gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Usage" --verbose, we get:

{noformat}
[ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Usage
I1119 13:52:58.323119 25447 leveldb.cpp:176] Opened db in 45.2273ms
I1119 13:52:58.333658 25447 leveldb.cpp:183] Compacted db in 10.355657ms
I1119 13:52:58.333791 25447 leveldb.cpp:198] Created db iterator in 61701ns
I1119 13:52:58.333822 25447 leveldb.cpp:204] Seeked to beginning of db in 4251ns
I1119 13:52:58.333837 25447 leveldb.cpp:273] Iterated through 0 keys in the db 
in 442ns
I1119 13:52:58.333982 25447 replica.cpp:780] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I1119 13:52:58.336284 25462 recover.cpp:449] Starting replica recovery
I1119 13:52:58.337008 25462 recover.cpp:475] Replica is in EMPTY status
I1119 13:52:58.339164 25465 replica.cpp:676] Replica in EMPTY status received a 
broadcasted recover request from (4)@127.0.1.1:40834
I1119 13:52:58.340235 25466 recover.cpp:195] Received a recover response from a 
replica in EMPTY status
I1119 13:52:58.341146 25461 recover.cpp:566] Updating replica status to STARTING
I1119 13:52:58.342461 25465 master.cpp:367] Master 
f78e3b28-c45c-4b5b-b6d9-2734247272ee (debian-jessie.vagrantup.com) started on 
127.0.1.1:40834
I1119 13:52:58.342586 25465 master.cpp:369] Flags at startup: --acls="" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
--authorizers="local" --credentials="/tmp/3OqRd1/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/3OqRd1/master" 
--zk_session_timeout="10secs"
I1119 13:52:58.343490 25465 master.cpp:414] Master only allowing authenticated 
frameworks to register
I1119 13:52:58.343511 25465 master.cpp:419] Master only allowing authenticated 
slaves to register
I1119 13:52:58.343523 25465 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/3OqRd1/credentials'
I1119 13:52:58.353895 25466 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 12.443751ms
I1119 13:52:58.353961 25466 replica.cpp:323] Persisted replica status to 
STARTING
I1119 13:52:58.354204 25465 master.cpp:458] Using default 'crammd5' 
authenticator
I1119 13:52:58.354315 25466 recover.cpp:475] Replica is in STARTING status
I1119 13:52:58.354368 25465 authenticator.cpp:520] Initializing server SASL
I1119 13:52:58.355571 25464 replica.cpp:676] Replica in STARTING status 
received a broadcasted recover request from (5)@127.0.1.1:40834
I1119 13:52:58.356163 25466 recover.cpp:195] Received a recover response from a 
replica in STARTING status
I1119 13:52:58.356730 25464 recover.cpp:566] Updating replica status to VOTING
I1119 13:52:58.360151 25465 master.cpp:495] Authorization enabled
I1119 13:52:58.366266 25467 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 9.00668ms
I1119 13:52:58.366329 25467 replica.cpp:323] Persisted replica status to VOTING
I1119 13:52:58.366459 25467 recover.cpp:580] Successfully joined the Paxos group
I1119 13:52:58.32 25467 recover.cpp:464] Recover process terminated
I1119 13:52:58.367223 25463 master.cpp:1606] The newly elected leader is 
master@127.0.1.1:40834 with id f78e3b28-c45c-4b5b-b6d9-2734247272ee
I1119 13:52:58.367322 25463 master.cpp:1619] Elected as the leading master!
I1119 13:52:58.367359 25463 master.cpp:1379] Recovering from registrar
I1119 13:52:58.367661 25462 registrar.cpp:309] Recovering registrar
I1119 13:52:58.368773 25461 log.cpp:661] Attempting to start the writer
I1119 13:52:58.371237 25468 replica.cpp:496] Replica received implicit promise 
request from (6)@127.0.1.1:40834 with proposal 1
I1119 13:52:58.371743 25468 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 444953ns
I1119 13:52:58.371793 25468 replica.cpp:345] Persisted promised to 1
I1119 13:52:58.373045 25465 coordinator.cpp:240] Coordinator attempting to fill 
missing positions
I1119

[jira] [Created] (MESOS-3958) Test DockerContainerizerTest.ROOT_DOCKER_Update fails on Debian 8.

2015-11-19 Thread Bernd Mathiske (JIRA)

Bernd Mathiske created MESOS-3958:
-

 Summary: Test DockerContainerizerTest.ROOT_DOCKER_Update fails on 
Debian 8.
 Key: MESOS-3958
 URL: https://issues.apache.org/jira/browse/MESOS-3958
 Project: Mesos
  Issue Type: Bug
  Components: docker, 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


Running sudo ./bin/mesos-tests.sh 
--gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Update" --verbose, we get:

{noformat}
[ RUN  ] DockerContainerizerTest.ROOT_DOCKER_Update
I1119 14:25:33.490622 30568 leveldb.cpp:176] Opened db in 40.034383ms
I1119 14:25:33.498376 30568 leveldb.cpp:183] Compacted db in 7.599708ms
I1119 14:25:33.498545 30568 leveldb.cpp:198] Created db iterator in 73294ns
I1119 14:25:33.498579 30568 leveldb.cpp:204] Seeked to beginning of db in 5930ns
I1119 14:25:33.498594 30568 leveldb.cpp:273] Iterated through 0 keys in the db 
in 388ns
I1119 14:25:33.498731 30568 replica.cpp:780] Replica recovered with log 
positions 0 -> 0 with 1 holes and 0 unlearned
I1119 14:25:33.500977 30589 recover.cpp:449] Starting replica recovery
I1119 14:25:33.502004 30583 recover.cpp:475] Replica is in EMPTY status
I1119 14:25:33.505199 30582 replica.cpp:676] Replica in EMPTY status received a 
broadcasted recover request from (4)@127.0.1.1:53940
I1119 14:25:33.506701 30583 recover.cpp:195] Received a recover response from a 
replica in EMPTY status
I1119 14:25:33.508040 30587 recover.cpp:566] Updating replica status to STARTING
I1119 14:25:33.509750 30589 master.cpp:367] Master 
d5a4b793-6ed8-42a4-89f9-f481f4576e36 (debian-jessie.vagrantup.com) started on 
127.0.1.1:53940
I1119 14:25:33.509860 30589 master.cpp:369] Flags at startup: --acls="" 
--allocation_interval="1secs" --allocator="HierarchicalDRF" 
--authenticate="true" --authenticate_slaves="true" --authenticators="crammd5" 
--authorizers="local" --credentials="/tmp/2ng8OG/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/2ng8OG/master" 
--zk_session_timeout="10secs"
I1119 14:25:33.511498 30589 master.cpp:414] Master only allowing authenticated 
frameworks to register
I1119 14:25:33.511533 30589 master.cpp:419] Master only allowing authenticated 
slaves to register
I1119 14:25:33.511560 30589 credentials.hpp:37] Loading credentials for 
authentication from '/tmp/2ng8OG/credentials'
I1119 14:25:33.514281 30582 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 5.914377ms
I1119 14:25:33.514616 30582 replica.cpp:323] Persisted replica status to 
STARTING
I1119 14:25:33.515270 30586 recover.cpp:475] Replica is in STARTING status
I1119 14:25:33.515537 30589 master.cpp:458] Using default 'crammd5' 
authenticator
I1119 14:25:33.516177 30589 authenticator.cpp:520] Initializing server SASL
I1119 14:25:33.517812 30584 replica.cpp:676] Replica in STARTING status 
received a broadcasted recover request from (5)@127.0.1.1:53940
I1119 14:25:33.518755 30588 recover.cpp:195] Received a recover response from a 
replica in STARTING status
I1119 14:25:33.519742 30583 recover.cpp:566] Updating replica status to VOTING
I1119 14:25:33.524073 30589 master.cpp:495] Authorization enabled
I1119 14:25:33.525710 30588 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 5.247917ms
I1119 14:25:33.526275 30588 replica.cpp:323] Persisted replica status to VOTING
I1119 14:25:33.526548 30585 recover.cpp:580] Successfully joined the Paxos group
I1119 14:25:33.526851 30585 recover.cpp:464] Recover process terminated
I1119 14:25:33.533421 30582 master.cpp:1606] The newly elected leader is 
master@127.0.1.1:53940 with id d5a4b793-6ed8-42a4-89f9-f481f4576e36
I1119 14:25:33.533522 30582 master.cpp:1619] Elected as the leading master!
I1119 14:25:33.533579 30582 master.cpp:1379] Recovering from registrar
I1119 14:25:33.534111 30582 registrar.cpp:309] Recovering registrar
I1119 14:25:33.535789 30584 log.cpp:661] Attempting to start the writer
I1119 14:25:33.538920 30587 replica.cpp:496] Replica received implicit promise 
request from (6)@127.0.1.1:53940 with proposal 1
I1119 14:25:33.539789 30587 leveldb.cpp:306] Persisting metadata (8 bytes) to 
leveldb took 755133ns
I1119 14:25:33.539873 30587 replica.cpp:345] Persisted promised to 1
I1119 14:25:33.541929 30587 coordinator.cpp:240] Coordinator attempting to fill

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

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske commented on MESOS-3937:
---

This did nothing for me on Ubuntu. The test failure is still there.

> 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
>
> {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 the leading master!
> I1117

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

2015-11-19 Thread Vaibhav Khanduja (JIRA)


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

Vaibhav Khanduja commented on MESOS-3937:
-

You should try with docker friendly vagrant ubuntu image:

http://old.blog.phusion.nl/2013/11/08/docker-friendly-vagrant-boxes/

I believe 'trusty" is not. Moving to phusion I do not see this issue. 

> 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
>
> {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-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

2015-11-19 Thread Jojy Varghese (JIRA)


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

Jojy Varghese commented on MESOS-3793:
--

Hi [~aquamatthias]
  Thanks for the repro steps. I could reproduce the issue on my ubuntu 14.14 
with your steps. I added env variable MESOS_LAUNCHER=posix and the issue went 
away. Did you try this ? 
  


-Jojy

> 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

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

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske commented on MESOS-3937:
---

Thanks! I'll try this. I wonder though what is needed to make Ubuntu 
"docker-friendly" beyond the instructions here: 
https://docs.docker.com/engine/installation/ubuntulinux/
 
Ideas?

> 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
>
> {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] [Comment Edited] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.

2015-11-19 Thread Bernd Mathiske (JIRA)


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

Bernd Mathiske edited comment on MESOS-3937 at 11/19/15 5:48 PM:
-

Thanks! I'll try this. I wonder though what is needed to make Ubuntu 
"docker-friendly" beyond the instructions here: 
https://docs.docker.com/engine/installation/ubuntulinux/
 
OK, this is answered here:
https://github.com/phusion/baseimage-docker


was (Author: bernd-mesos):
Thanks! I'll try this. I wonder though what is needed to make Ubuntu 
"docker-friendly" beyond the instructions here: 
https://docs.docker.com/engine/installation/ubuntulinux/
 
Ideas?

> 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
>
> {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

46 matches

Mail list logo