[jira] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-3932:
---

andschwa closed pull request #104: MESOS-3932 Suppressed boost auto_ptr compile 
warnings.
URL: https://github.com/apache/mesos/pull/104
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index e0c538d9e6..cfb05475e6 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -388,7 +388,7 @@ add_definitions(-DUSE_STATIC_LIB -DBUILD_DATE=0 
-DBUILD_TIME=0 -DBUILD_USER="fra
 # INCLUDE DIRECTIVES FOR MESOS LIBRARY (generates, e.g., -I/path/to/thing
 # on Linux).
 #
-include_directories(${AGENT_INCLUDE_DIRS})
+include_directories(SYSTEM ${AGENT_INCLUDE_DIRS})
 
 # LINKING LIBRARIES BY DIRECTORY (might generate, e.g., -L/path/to/thing on
 # Linux).


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Silence Boost compiler warnings with CMake
> --
>
> Key: MESOS-3932
> URL: https://issues.apache.org/jira/browse/MESOS-3932
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Alex Clemmer
>Priority: Minor
>  Labels: cmake, mesosphere, microsoft
> Fix For: 1.2.0
>
>
> Per MESOS-3799, we should silence at least two kinds of compiler warning 
> fixes when including the Boost headers:
> * Add -Wno-unused-local-typedefs to CXXFLAGS
> * Use -isystem when including Boost to avoid deprecation warnings for use of 
> auto_ptr
> I believe we technically need both, IIRC because some other depedencies pull 
> in Boost using their own -I flag.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-3932:
---

andschwa commented on issue #104: MESOS-3932 Suppressed boost auto_ptr compile 
warnings.
URL: https://github.com/apache/mesos/pull/104#issuecomment-416309788
 
 
   Thanks @frankscholten! I am closing this as the whole CMake build has been 
pretty much rewritten since this was opened. Sorry we didn't get to it in time!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Silence Boost compiler warnings with CMake
> --
>
> Key: MESOS-3932
> URL: https://issues.apache.org/jira/browse/MESOS-3932
> Project: Mesos
>  Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Alex Clemmer
>Priority: Minor
>  Labels: cmake, mesosphere, microsoft
> Fix For: 1.2.0
>
>
> Per MESOS-3799, we should silence at least two kinds of compiler warning 
> fixes when including the Boost headers:
> * Add -Wno-unused-local-typedefs to CXXFLAGS
> * Use -isystem when including Boost to avoid deprecation warnings for use of 
> auto_ptr
> I believe we technically need both, IIRC because some other depedencies pull 
> in Boost using their own -I flag.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-3139:
---

greggomann closed pull request #105: MESOS-3139 Added first draft CMake build 
docs.
URL: https://github.com/apache/mesos/pull/105
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/docs/cmake.md b/docs/cmake.md
new file mode 100644
index 00..eac94da76a
--- /dev/null
+++ b/docs/cmake.md
@@ -0,0 +1,59 @@
+---
+title: Apache Mesos - CMake
+layout: documentation
+---
+
+# CMake
+
+## Downloading Mesos
+
+There are different ways you can get Mesos:
+
+1\. Download the latest stable release from 
[Apache](http://mesos.apache.org/downloads/) (***Recommended***)
+
+$ wget http://www.apache.org/dist/mesos/0.28.1/mesos-0.28.1.tar.gz
+$ tar -zxf mesos-0.28.1.tar.gz
+
+2\. Clone the Mesos git 
[repository](https://git-wip-us.apache.org/repos/asf/mesos.git) (***Advanced 
Users Only***)
+
+$ git clone https://git-wip-us.apache.org/repos/asf/mesos.git
+
+*NOTE: If you have problems running the above commands, you may need to first 
run through the ***System Requirements*** section below to install the `wget`, 
`tar`, and `git` utilities for your system.*
+
+## System Requirements
+
+Mesos runs on Linux (64 Bit) and Mac OS X (64 Bit). To build Mesos from 
source, GCC 4.8.1+ or Clang 3.5+ and CMake 3.5.1 is required.
+
+For full support of process isolation under Linux a recent kernel >=3.10 is 
required.
+
+Make sure your hostname is resolvable via DNS or via `/etc/hosts` to allow 
full support of Docker's host-networking capabilities, needed for some of the 
Mesos tests. When in doubt, please validate that `/etc/hosts` contains your 
hostname.
+
+### Ubuntu 16.04
+
+Following are the instructions for stock Ubuntu 16.04. If you are using a 
different OS, please install the packages accordingly.
+
+# Update the packages.
+$ sudo apt-get update
+
+# Install a few utility tools.
+$ sudo apt-get install -y tar wget git
+
+# Install the latest OpenJDK.
+$ sudo apt-get install -y openjdk-7-jdk
+
+# Install autotools (Only necessary if building from git repository).
+$ sudo apt-get install -y autoconf libtool
+
+# Install other Mesos dependencies.
+$ sudo apt-get -y install build-essential python-dev libcurl4-nss-dev 
libsasl2-dev libsasl2-modules maven libapr1-dev libsvn-dev
+
+## Building Mesos with CMake
+
+# Change working directory.
+$ cd mesos
+
+# Configure and build.
+$ mkdir build
+$ cd build
+$ cmake ..
+$ make
diff --git a/docs/home.md b/docs/home.md
index 16a77da437..75d659a1e8 100644
--- a/docs/home.md
+++ b/docs/home.md
@@ -13,6 +13,7 @@ layout: documentation
 ## Running Mesos
 
 * [Getting Started](getting-started.md) for basic instructions on compiling 
and installing Mesos.
+* [CMake](cmake.md) for building Mesos with CMake.
 * [Upgrades](upgrades.md) for upgrading a Mesos cluster.
 * [Configuration](configuration.md) for command-line arguments.
 * [HTTP Endpoints](endpoints/) for available HTTP endpoints.


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Incorporate CMake into standard documentation
> -
>
> Key: MESOS-3139
> URL: https://issues.apache.org/jira/browse/MESOS-3139
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>Priority: Major
>  Labels: cmake, mesosphere, microsoft, windows-mvp
> Fix For: 1.3.0
>
>
> Right now it's anyone's guess how to build with CMake. If we want people to 
> use it, we should put up documentation. The central challenge is that the 
> CMake instructions will be slightly different for different platforms.
> For example, on Linux, the gist of the build is basically the same as 
> autotools; you pull down the system dependencies (like APR, _etc_.), and then:
> ```
> ./bootstrap
> mkdir build-cmake && cd build-cmake
> cmake ..
> make
> ```
> But, on Windows, it will be somewhat more complicated. There is no bootstrap 
> step, for example, because Windows doesn't have bash natively. And even when 
> we put that in, you'll still have to build the glog stuff out-of-band because 
> CMake has no way of booting up Visual Studio and calling 

[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-3139:
---

greggomann commented on issue #105: MESOS-3139 Added first draft CMake build 
docs.
URL: https://github.com/apache/mesos/pull/105#issuecomment-416308848
 
 
   Closing this PR since we have added CMake documentation in the meantime.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Incorporate CMake into standard documentation
> -
>
> Key: MESOS-3139
> URL: https://issues.apache.org/jira/browse/MESOS-3139
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>Priority: Major
>  Labels: cmake, mesosphere, microsoft, windows-mvp
> Fix For: 1.3.0
>
>
> Right now it's anyone's guess how to build with CMake. If we want people to 
> use it, we should put up documentation. The central challenge is that the 
> CMake instructions will be slightly different for different platforms.
> For example, on Linux, the gist of the build is basically the same as 
> autotools; you pull down the system dependencies (like APR, _etc_.), and then:
> ```
> ./bootstrap
> mkdir build-cmake && cd build-cmake
> cmake ..
> make
> ```
> But, on Windows, it will be somewhat more complicated. There is no bootstrap 
> step, for example, because Windows doesn't have bash natively. And even when 
> we put that in, you'll still have to build the glog stuff out-of-band because 
> CMake has no way of booting up Visual Studio and calling "build."
> So practically, we need to figure out:
> * What our build story is for different platforms
> * Write specific instructions for our "core" target platforms.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-5925) Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

jieyu closed pull request #158: Fixed MESOS-5925 Building Mesos in Docker 1.12 
on OS X
URL: https://github.com/apache/mesos/pull/158
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/3rdparty/gmock-1.7.0.tar.gz b/3rdparty/gmock-1.7.0.tar.gz
index 09f5ea3ce9..edf43e1926 100644
Binary files a/3rdparty/gmock-1.7.0.tar.gz and b/3rdparty/gmock-1.7.0.tar.gz 
differ
diff --git a/3rdparty/gperftools-2.5.tar.gz b/3rdparty/gperftools-2.5.tar.gz
index 0002c837a2..ed6be94550 100644
Binary files a/3rdparty/gperftools-2.5.tar.gz and 
b/3rdparty/gperftools-2.5.tar.gz differ


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>Assignee: haosdent
>Priority: Major
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> 

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/301


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7386) Executor not cleaning up existing running docker containers if external logrotate/logger processes die/killed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7386:
---

GitHub user r4um opened a pull request:

https://github.com/apache/mesos/pull/304

[MESOS-7386] Do a stop if container is not killed

Fixes [MESOS-7386](https://issues.apache.org/jira/browse/MESOS-7386)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/r4um/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/304.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #304


commit 933cd229119925d8196149cbe6f775434b6e2cfa
Author: Pranay Kanwar 
Date:   2018-07-22T06:41:14Z

[MESOS-7386] Do a stop if container is not killed




> Executor not cleaning up existing running docker containers if external 
> logrotate/logger processes die/killed
> -
>
> Key: MESOS-7386
> URL: https://issues.apache.org/jira/browse/MESOS-7386
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, docker, executor
>Affects Versions: 0.28.2, 1.2.0
> Environment: Mesos 0.28.2/1.2.0, docker 1.12.0/17.04.0-ce, marathon 
> v1.1.2/v1.4.2 , ubuntu trusty 14.04, 
> org_apache_mesos_LogrotateContainerLogger, 
> org_apache_mesos_ExternalContainerLogger
>Reporter: Pranay Kanwar
>Priority: Critical
>
> if mesos-logrorate/external logger processes die/killed executor exits / task 
> fails and task is relaunched , but is unable to cleanup existing running 
> container.
> Logs 
> {noformat}
> slave-one_1  | I0413 12:45:17.707762  8989 status_update_manager.cpp:395] 
> Received status update acknowledgement (UUID: 
> 7262c443-e201-45f4-8de0-825d3d92c26b) for task 
> msg.dfb155bc-2046-11e7-8019-02427fa1c4d5 of framework 
> d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-
> slave-one_1  | I0413 12:45:17.707813  8989 status_update_manager.cpp:832] 
> Checkpointing ACK for status update TASK_FAILED (UUID: 
> 7262c443-e201-45f4-8de0-825d3d92c26b) for task 
> msg.dfb155bc-2046-11e7-8019-02427fa1c4d5 of framework 
> d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-
> slave-one_1  | I0413 12:45:18.615839  8991 slave.cpp:4388] Got exited event 
> for executor(1)@172.17.0.1:36471
> slave-one_1  | I0413 12:45:18.696413  8987 docker.cpp:2358] Executor for 
> container 665e86c8-ef36-4be3-b56e-3ba7edc81182 has exited
> slave-one_1  | I0413 12:45:18.696446  8987 docker.cpp:2052] Destroying 
> container 665e86c8-ef36-4be3-b56e-3ba7edc81182
> slave-one_1  | I0413 12:45:18.696482  8987 docker.cpp:2179] Running docker 
> stop on container 665e86c8-ef36-4be3-b56e-3ba7edc81182
> slave-one_1  | I0413 12:45:18.697042  8994 slave.cpp:4769] Executor 
> 'msg.dfb155bc-2046-11e7-8019-02427fa1c4d5' of framework 
> d1d616b4-1ed1-4fed-92e5-0ee3d8619be9- exited with status 0
> slave-one_1  | I0413 12:45:18.697077  8994 slave.cpp:4869] Cleaning up 
> executor 'msg.dfb155bc-2046-11e7-8019-02427fa1c4d5' of framework 
> d1d616b4-1ed1-4fed-92e5-0ee3d8619be9- at executor(1)@172.17.0.1:36471
> slave-one_1  | I0413 12:45:18.697424  8994 slave.cpp:4957] Cleaning up 
> framework d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-
> slave-one_1  | I0413 12:45:18.697530  8994 gc.cpp:55] Scheduling 
> '/tmp/mesos/agent/slaves/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-S0/frameworks/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-/executors/msg.dfb155bc-2046-11e7-8019-02427fa1c4d5/runs/665e86c8-ef36-4be3-b56e-3ba7edc81182'
>  for gc 6.9192952593days in the future
> slave-one_1  | I0413 12:45:18.697572  8994 gc.cpp:55] Scheduling 
> '/tmp/mesos/agent/slaves/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-S0/frameworks/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-/executors/msg.dfb155bc-2046-11e7-8019-02427fa1c4d5'
>  for gc 6.9192882963days in the future
> slave-one_1  | I0413 12:45:18.697607  8994 gc.cpp:55] Scheduling 
> '/tmp/mesos/agent/meta/slaves/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-S0/frameworks/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-/executors/msg.dfb155bc-2046-11e7-8019-02427fa1c4d5/runs/665e86c8-ef36-4be3-b56e-3ba7edc81182'
>  for gc 6.9192843852days in the future
> slave-one_1  | I0413 12:45:18.697628  8994 gc.cpp:55] Scheduling 
> '/tmp/mesos/agent/meta/slaves/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-S0/frameworks/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-/executors/msg.dfb155bc-2046-11e7-8019-02427fa1c4d5'
>  for gc 6.9192808889days in the future
> slave-one_1  | I0413 12:45:18.697649  8994 gc.cpp:55] Scheduling 
> '/tmp/mesos/agent/slaves/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-S0/frameworks/d1d616b4-1ed1-4fed-92e5-0ee3d8619be9-'
> 

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r204167169
  
--- Diff: docs/scheduler-http-api.md ---
@@ -479,6 +479,32 @@ HTTP/1.1 202 Accepted
 
 ```
 
+### SUPPRESS
+Sent by the scheduler when it doesn't need offers for a given set of its 
roles. When Mesos master receives this request, it will stop sending offers for 
the given set of roles to the framework. As a special case, if roles are not 
specified, all subscribed roles of this framework are suppressed.
+
+Note that master continues to send offers to other subscribed roles of 
this framework that are not suppressed. Also, status updates about tasks, 
executors and agents are not affected by this call and tasks will continue 
running for `FrameworkInfo.failover_timeout`.
+
+If the scheduler wishes to receive offers for the suppressed roles again 
(e.g., it needs to schedule new workloads), it can send `REVIVE` call.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler  HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+  "framework_id" : {"value" : "12220-3440-12532-2345"},
+  "type" : "SUPPRESS",
+  "suppress" : {"role": }
--- End diff --

This should be `roles` and not `role` since Mesos at least 1.3.0!  And 
`roles` takes an array of strings (i.e., roles) and not a single role.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r204166164
  
--- Diff: docs/scheduler-http-api.md ---
@@ -479,6 +479,32 @@ HTTP/1.1 202 Accepted
 
 ```
 
+### SUPPRESS
+Sent by the scheduler when it doesn't need offers for a given set of its 
roles. When Mesos master receives this request, it will stop sending offers for 
the given set of roles to the framework. As a special case, if roles are not 
specified, all subscribed roles of this framework are suppressed.
+
+Note that master continues to send offers to other subscribed roles of 
this framework that are not suppressed. Also, status updates about tasks, 
executors and agents are not affected by this call and tasks will continue 
running for `FrameworkInfo.failover_timeout`.
--- End diff --

I would remove `...and tasks will continue running for 
`FrameworkInfo.failover_timeout`` part. That timeout doesn't come into play at 
all during suppression. That will only come into play when a framework 
disconnects.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

GitHub user thzois reopened a pull request:

https://github.com/apache/mesos/pull/301

Document SUPPRESS HTTP call [MESOS-7211]



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/thzois/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/301.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #301


commit e4391b6f13ed5a0f333d6dc3bbc5b4ec1fc51cef
Author: Thodoris Zois 
Date:   2018-07-12T14:02:12Z

Document SUPPRESS HTTP call [MESOS-7211]




> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user thzois closed the pull request at:

https://github.com/apache/mesos/pull/301


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

GitHub user thzois reopened a pull request:

https://github.com/apache/mesos/pull/301

Document SUPPRESS HTTP call [MESOS-7211]



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/thzois/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/301.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #301


commit 5441716bf1d4d3b695574d21f1d50a2b866b0a14
Author: Thodoris Zois 
Date:   2018-07-12T13:47:01Z

Document SUPPRESS HTTP call [MESOS-7211]




> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user thzois closed the pull request at:

https://github.com/apache/mesos/pull/301


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

GitHub user thzois reopened a pull request:

https://github.com/apache/mesos/pull/301

Document SUPPRESS HTTP call [MESOS-7211]



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/thzois/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/301.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #301


commit 2c9bc7270956c17b055f23b24a24a006748b7725
Author: zois 
Date:   2018-07-10T13:24:37Z

Document SUPPRESS HTTP call [MESOS-7211]

commit f9725b0c51db2dc49d6437798b798bb1534659e6
Author: Thodoris Zois 
Date:   2018-07-10T23:39:55Z

Merge branch 'master' of https://github.com/apache/mesos

commit 23c8ec9669549917dc2e4722034446e5b33a9b79
Author: Thodoris Zois 
Date:   2018-07-11T00:02:12Z

Changes to documentation of SUPPRESS HTTP call [MESOS-7211]




> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user thzois closed the pull request at:

https://github.com/apache/mesos/pull/301


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user thzois commented on the issue:

https://github.com/apache/mesos/pull/301
  
Hello, I think that everything is OK now. Can you confirm this? I will also 
create a new pull request for the "REVIVE" call.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201406612
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending 
offers to the framework. When Mesos receives this request it will stop sending 
offers to framework but the tasks will continue running for 
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can 
send again a `REVIVE` request.
--- End diff --

How about:

Sent by the scheduler when it doesn't need offers for a given set of its 
roles. When Mesos master receives this request, it will stop sending offers for 
the given set of roles to the framework. As a special case, if `roles` is not 
specified, all subscribed roles of this framework are suppressed.

Note that master continues to send offers to other subscribed roles of this 
framework that are not suppressed. Also, status updates about tasks, executors 
and agents are not affected by this call. 

If the scheduler wishes to receive offers for the suppressed roles again 
(e.g., it needs to schedule new workloads), it can send `REVIVE` call.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201407700
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending 
offers to the framework. When Mesos receives this request it will stop sending 
offers to framework but the tasks will continue running for 
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can 
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler  HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+  "framework_id": {"value" : "12220-3440-12532-2345"},
+  "type": "SUPPRESS"
+}
+
+SUPPRESS Response:
+HTTP/1.1 202 Accepted
+```
+
--- End diff --

While you are at it, can you also update the documentation about "REVIVE" 
call below. I think it's a bit outdated now. Preferably in a different PR.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201401610
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
--- End diff --

Can you move this to #500 below #REQUEST section to preserve the call enum 
order?


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user vinodkone commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201406742
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending 
offers to the framework. When Mesos receives this request it will stop sending 
offers to framework but the tasks will continue running for 
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can 
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler  HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+  "framework_id": {"value" : "12220-3440-12532-2345"},
+  "type": "SUPPRESS"
+}
--- End diff --

Can you also include `roles` field here for completeness?


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user nfnt commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201402242
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending 
offers to the framework. When Mesos receives this request it will stop sending 
offers to framework but the tasks will continue running for 
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can 
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler  HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+  "framework_id": {"value" : "12220-3440-12532-2345"},
+  "type": "SUPPRESS"
--- End diff --

Please re-indent. With spaces, even though some other calls in this 
document use tabs.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

Github user nfnt commented on a diff in the pull request:

https://github.com/apache/mesos/pull/301#discussion_r201402758
  
--- Diff: docs/scheduler-http-api.md ---
@@ -128,6 +128,26 @@ TEARDOWN Response:
 HTTP/1.1 202 Accepted
 ```
 
+### SUPPRESS
+Sent by the scheduler when it wants to inform Mesos master to stop sending 
offers to the framework. When Mesos receives this request it will stop sending 
offers to framework but the tasks will continue running for 
`FrameworkInfo.failover_timeout`. Once the framework has work to do, it can 
send again a `REVIVE` request.
+
+```
+SUPPRESS Request (JSON):
+POST /api/v1/scheduler  HTTP/1.1
+
+Host: masterhost:5050
+Content-Type: application/json
+Mesos-Stream-Id: 130ae4e3-6b13-4ef4-baa9-9f2e85c3e9af
+
+{
+  "framework_id": {"value" : "12220-3440-12532-2345"},
+  "type": "SUPPRESS"
+}
--- End diff --

The `Supress` call has a `roles` option. Please use an example call that 
sets a role to suppress offers for.


> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7211) Document SUPPRESS HTTP call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7211:
---

GitHub user thzois opened a pull request:

https://github.com/apache/mesos/pull/301

Document SUPPRESS HTTP call [MESOS-7211]



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/thzois/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/301.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #301


commit 2c9bc7270956c17b055f23b24a24a006748b7725
Author: zois 
Date:   2018-07-10T13:24:37Z

Document SUPPRESS HTTP call [MESOS-7211]




> Document SUPPRESS HTTP call
> ---
>
> Key: MESOS-7211
> URL: https://issues.apache.org/jira/browse/MESOS-7211
> Project: Mesos
>  Issue Type: Documentation
>  Components: documentation
>Affects Versions: 1.1.0
>Reporter: Bruce Merry
>Priority: Minor
>  Labels: mesosphere, newbie
>
> The documentation at 
> http://mesos.apache.org/documentation/latest/scheduler-http-api/ doesn't list 
> the SUPPRESS call as one of the call types, but it does seem to be 
> implemented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8967) Comments for FaultDomain should include notes for convention pertaining to additional hierarchy.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8967:
---

Github user jdef commented on the issue:

https://github.com/apache/mesos/pull/294
  
xref https://issues.apache.org/jira/browse/MESOS-8967


> Comments for FaultDomain should include notes for convention pertaining to 
> additional hierarchy.
> 
>
> Key: MESOS-8967
> URL: https://issues.apache.org/jira/browse/MESOS-8967
> Project: Mesos
>  Issue Type: Task
>Reporter: James DeFelice
>Priority: Major
>  Labels: mesosphere
>
> The original design doc includes conventions for additional hierarchy. This 
> commentary is missing from the protobuf and so it's easily missed.
> https://docs.google.com/document/d/1gEugdkLRbBsqsiFv3urRPRNrHwUC-i1HwfFfHR_MvC8/edit#heading=h.emfys1xszpir



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8857) Fix subprocess(flags) logic on Windows to handle arguments with quotes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8857:
---

GitHub user radhikaj opened a pull request:

https://github.com/apache/mesos/pull/289

Fixtestflags

Fixing bug described in
https://issues.apache.org/jira/browse/MESOS-8857
echo on windows just reproduces the command line args it receives and does 
not apply any text processing to it. The Flags test in SubProcessTest expects 
standard text processing to be applied to the command line args. Therefore 
instead of using echo on windows to test that flags are being fed correctly to 
a console app, we add test-flags.exe which receives command line args via argv 
and prints argv's elements out with a space in between.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/radhikaj/mesos fixtestflags

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/289.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #289






> Fix subprocess(flags) logic on Windows to handle arguments with quotes
> --
>
> Key: MESOS-8857
> URL: https://issues.apache.org/jira/browse/MESOS-8857
> Project: Mesos
>  Issue Type: Bug
>Reporter: Andrew Schwartzmeyer
>Assignee: Radhika Jandhyala
>Priority: Major
>  Labels: flags, libprocess, windows
>
> In the {{SubprocessTest.Flags}} unit test, a bug was discovered where the 
> flags argument {{flags.s3 = "\"geek\"";}} does not make it round-trip back to 
> the test. It is because the {{stringify_args}} logic in {{shell.hpp}} 
> purposefully (correctly?) surrounds an argument that contains a double quote 
> with a pair of double quotes. Thus the final command-line flag looks like 
> {{"\"--s3=\\\"geek\\\"\""}}, which {{flags.load()}} then fails to reparse. 
> The same problem occurs for the (more complicated) JSON flag.
> I believe this is because the original logic was expecting the shell to drop 
> the quotes ({{echo "--s3=\"geek\""}} in Bash returns {{--s3="geek"}}, but 
> {{cmd.exe}} echos {{"--s3=\"geek\""}}, exactly what was passed. Maybe the 
> test just needs to be fixed; maybe the stringifier shouldn't add more quotes; 
> maybe {{flags.load()}} needs to parse the quotes and escapes.
> For now, we're enabling the rest of the test by turning off those two checks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8857) Fix subprocess(flags) logic on Windows to handle arguments with quotes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8857:
---

Github user radhikaj closed the pull request at:

https://github.com/apache/mesos/pull/288


> Fix subprocess(flags) logic on Windows to handle arguments with quotes
> --
>
> Key: MESOS-8857
> URL: https://issues.apache.org/jira/browse/MESOS-8857
> Project: Mesos
>  Issue Type: Bug
>Reporter: Andrew Schwartzmeyer
>Assignee: Radhika Jandhyala
>Priority: Major
>  Labels: flags, libprocess, windows
>
> In the {{SubprocessTest.Flags}} unit test, a bug was discovered where the 
> flags argument {{flags.s3 = "\"geek\"";}} does not make it round-trip back to 
> the test. It is because the {{stringify_args}} logic in {{shell.hpp}} 
> purposefully (correctly?) surrounds an argument that contains a double quote 
> with a pair of double quotes. Thus the final command-line flag looks like 
> {{"\"--s3=\\\"geek\\\"\""}}, which {{flags.load()}} then fails to reparse. 
> The same problem occurs for the (more complicated) JSON flag.
> I believe this is because the original logic was expecting the shell to drop 
> the quotes ({{echo "--s3=\"geek\""}} in Bash returns {{--s3="geek"}}, but 
> {{cmd.exe}} echos {{"--s3=\"geek\""}}, exactly what was passed. Maybe the 
> test just needs to be fixed; maybe the stringifier shouldn't add more quotes; 
> maybe {{flags.load()}} needs to parse the quotes and escapes.
> For now, we're enabling the rest of the test by turning off those two checks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8857) Fix subprocess(flags) logic on Windows to handle arguments with quotes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8857:
---

GitHub user radhikaj opened a pull request:

https://github.com/apache/mesos/pull/288

Fixtestflags

https://issues.apache.org/jira/browse/MESOS-8857



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/radhikaj/mesos fixtestflags

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/288.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #288


commit 9d895daf4bcd27e6929b03a95e7cef8002876f59
Author: Radhika Jandhyala 
Date:   2018-05-09T21:09:34Z

Fix TEST_F(SubprocessTest, Flags)

commit 0c60122764d5923c8e7255516042bd26787a1ff5
Author: Radhika Jandhyala 
Date:   2018-05-09T21:51:20Z

run clang-format




> Fix subprocess(flags) logic on Windows to handle arguments with quotes
> --
>
> Key: MESOS-8857
> URL: https://issues.apache.org/jira/browse/MESOS-8857
> Project: Mesos
>  Issue Type: Bug
>Reporter: Andrew Schwartzmeyer
>Assignee: Radhika Jandhyala
>Priority: Major
>  Labels: flags, libprocess, windows
>
> In the {{SubprocessTest.Flags}} unit test, a bug was discovered where the 
> flags argument {{flags.s3 = "\"geek\"";}} does not make it round-trip back to 
> the test. It is because the {{stringify_args}} logic in {{shell.hpp}} 
> purposefully (correctly?) surrounds an argument that contains a double quote 
> with a pair of double quotes. Thus the final command-line flag looks like 
> {{"\"--s3=\\\"geek\\\"\""}}, which {{flags.load()}} then fails to reparse. 
> The same problem occurs for the (more complicated) JSON flag.
> I believe this is because the original logic was expecting the shell to drop 
> the quotes ({{echo "--s3=\"geek\""}} in Bash returns {{--s3="geek"}}, but 
> {{cmd.exe}} echos {{"--s3=\"geek\""}}, exactly what was passed. Maybe the 
> test just needs to be fixed; maybe the stringifier shouldn't add more quotes; 
> maybe {{flags.load()}} needs to parse the quotes and escapes.
> For now, we're enabling the rest of the test by turning off those two checks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8750) Check failed: !slaves.registered.contains(task->slave_id)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8750:
---

Github user m9a closed the pull request at:

https://github.com/apache/mesos/pull/279


> Check failed: !slaves.registered.contains(task->slave_id)
> -
>
> Key: MESOS-8750
> URL: https://issues.apache.org/jira/browse/MESOS-8750
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Affects Versions: 1.6.0
>Reporter: Megha Sharma
>Assignee: Megha Sharma
>Priority: Critical
>
> It appears that in certain circumstances an unreachable task doesn't get 
> cleaned up from the framework.unreachableTasks when the respective agent 
> re-registers leading to this check failure later when the framework is being 
> removed. When an agent goes unreachable master adds the tasks from this agent 
> to {{framework.unreachableTasks}} and when such an agent re-registers the 
> master removes the tasks that it specifies during re-registeration from this 
> datastructure but there could be tasks that the agent doesn't know about e.g. 
> if the runTask message for them got dropped and so such tasks will not get 
> removed from unreachableTasks.
> {noformat}
> F0310 13:30:58.856665 62740 master.cpp:9671] Check failed: 
> !slaves.registered.contains(task->slave_id()) Unreachable task  of 
> framework 4f57975b-05dd-4118-8674-5b29a86c6a6c-0850 was found on registered 
> agent 683c4a92-b5a0-490c-998a-6113fc86d37a-S1428
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-7658) apply-reviews.py fails with Unicode characters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7658:
---

Github user kaysoky commented on the issue:

https://github.com/apache/mesos/pull/284
  
Here's the associated JIRA: https://issues.apache.org/jira/browse/MESOS-7658


> apply-reviews.py fails with Unicode characters
> --
>
> Key: MESOS-7658
> URL: https://issues.apache.org/jira/browse/MESOS-7658
> Project: Mesos
>  Issue Type: Bug
>Reporter: Andrew Schwartzmeyer
>Priority: Major
>  Labels: reviewboard
>
> This prevents commits from being applied if the name or message contains 
> non-ASCII characters, and so can break the Windows ReviewBot.
> {code}
> > git checkout b2801f0012535e29609f603b4324a9ca693f70cb~
> > python .\support\apply-reviews.py -r 59874
> Traceback (most recent call last):
>   File ".\support\apply-reviews.py", line 381, in 
> reviewboard()
>   File ".\support\apply-reviews.py", line 360, in reviewboard
> apply_review()
>   File ".\support\apply-reviews.py", line 126, in apply_review
> commit_patch()
>   File ".\support\apply-reviews.py", line 225, in commit_patch
> shell(cmd, options['dry_run'])
>   File ".\support\apply-reviews.py", line 111, in shell
> error_code = subprocess.call(command, stderr=subprocess.STDOUT, 
> shell=True)
>   File "C:\Python27\lib\subprocess.py", line 168, in call
> return Popen(*popenargs, **kwargs).wait()
>   File "C:\Python27\lib\subprocess.py", line 390, in __init__
> errread, errwrite)
>   File "C:\Python27\lib\subprocess.py", line 610, in _execute_child
> args = '{} /c "{}"'.format (comspec, args)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 
> 25: ordinal not in range(128)
> ~\src\mesos-copy2 |-/
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8750) Check failed: !slaves.registered.contains(task->slave_id)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8750:
---

Github user m9a commented on the issue:

https://github.com/apache/mesos/pull/279
  
The JIRA for this PR: https://issues.apache.org/jira/browse/MESOS-8750
Since @xujyan is shepherding it I intended to set him as the reviewer but 
it doesn't look like I can change those fields on the PR.


> Check failed: !slaves.registered.contains(task->slave_id)
> -
>
> Key: MESOS-8750
> URL: https://issues.apache.org/jira/browse/MESOS-8750
> Project: Mesos
>  Issue Type: Task
>  Components: master
>Reporter: Megha Sharma
>Assignee: Megha Sharma
>Priority: Major
>
> It appears that in certain circumstances an unreachable task doesn't get 
> cleaned up from the framework.unreachableTasks when the respective agent 
> re-registers leading to this check failure later when the framework is being 
> removed. When an agent goes unreachable master adds the tasks from this agent 
> to framework.unreachableTasks and when such an agent re-registers the master 
> removes the tasks that it specifies during re-registeration from this 
> datastructure but there could be tasks that the agent doesn't know about e.g. 
> if the runTask message for them got dropped and so such tasks will not get 
> removed from unreachableTasks.
> F0112 21:50:39.272985 44038 master.cpp:9617] Check failed: 
> !slaves.registered.contains(task->slave_id())
> Check failure stack trace: ***
>  @ 0x7fb7260692bd (unknown)
>  @ 0x7fb72606b04d (unknown)
>  @ 0x7fb726068e42 (unknown)
>  @ 0x7fb72606ba29 (unknown)
>  @ 0x7fb7251f5226 (unknown)
>  @ 0x7fb725120081 (unknown)
>  @ 0x7fb72519ca37 (unknown)
>  @ 0x7fb725fbb2fe (unknown)
>  @ 0x7fb724f75de9 (unknown)
>  @ 0x7fb725fb4fc2 (unknown)
>  @ 0x7fb725fc4a17 (unknown)
>  @ 0x7fb725fca276 (unknown)
>  @ 0x7fb72352d470 (unknown)
>  @ 0x7fb723784aa1 start_thread
>  @ 0x7fb722f47bcd clone
>  @ (nil) (unknown)
>  Aborted
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user sagar8192 closed the pull request at:

https://github.com/apache/mesos/pull/263


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Assignee: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
> Fix For: 1.6.0
>
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs 
> multiple tasks in parallel. It is mainly used for running tests that depend 
> on other containerized internal microservices. It was developed before mesos 
> had support for docker-executor. So, it uses a custom executor, which 
> directly talks to docker daemon on the host and run a bunch of service 
> containers along with the process where tests are executed. Resources for all 
> these containers are not accounted for in mesos. Clean-up of these containers 
> is also a headache. We have a tool called docker-reaper that automatically 
> reaps the orphaned containers once the executor goes away. In addition to 
> that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We 
> also want to delegate the responsibility of lifecycle management of docker 
> containers to mesos and get rid of the custom executor. We looked at a few 
> alternatives to do this and decided to go with pods because they provide 
> all-or-nothing(atomicity) semantics that we need for our application. But, we 
> cannot use pods directly because all the containers in a pod have the same 
> network namespace. The service discovery mechanism requires all the 
> containers to have separate IPs. All of our microservices bind to  
> container port, so we will have port collision unless we are giving separate 
> namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate 
> namespaces. If NetworkInfo protobuf for nested containers is not empty, then 
> we will assign separate mnt and network namespaces to the nested containers. 
> Otherwise,  they will share the network and mount namepsaces with the 
> parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user sagar8192 commented on the issue:

https://github.com/apache/mesos/pull/263
  
Closed in favor of https://reviews.apache.org/r/65987/


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Assignee: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
> Fix For: 1.6.0
>
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs 
> multiple tasks in parallel. It is mainly used for running tests that depend 
> on other containerized internal microservices. It was developed before mesos 
> had support for docker-executor. So, it uses a custom executor, which 
> directly talks to docker daemon on the host and run a bunch of service 
> containers along with the process where tests are executed. Resources for all 
> these containers are not accounted for in mesos. Clean-up of these containers 
> is also a headache. We have a tool called docker-reaper that automatically 
> reaps the orphaned containers once the executor goes away. In addition to 
> that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We 
> also want to delegate the responsibility of lifecycle management of docker 
> containers to mesos and get rid of the custom executor. We looked at a few 
> alternatives to do this and decided to go with pods because they provide 
> all-or-nothing(atomicity) semantics that we need for our application. But, we 
> cannot use pods directly because all the containers in a pod have the same 
> network namespace. The service discovery mechanism requires all the 
> containers to have separate IPs. All of our microservices bind to  
> container port, so we will have port collision unless we are giving separate 
> namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate 
> namespaces. If NetworkInfo protobuf for nested containers is not empty, then 
> we will assign separate mnt and network namespaces to the nested containers. 
> Otherwise,  they will share the network and mount namepsaces with the 
> parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user sagar8192 commented on the issue:

https://github.com/apache/mesos/pull/263
  
Posted a new review here: https://reviews.apache.org/r/65987/


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs 
> multiple tasks in parallel. It is mainly used for running tests that depend 
> on other containerized internal microservices. It was developed before mesos 
> had support for docker-executor. So, it uses a custom executor, which 
> directly talks to docker daemon on the host and run a bunch of service 
> containers along with the process where tests are executed. Resources for all 
> these containers are not accounted for in mesos. Clean-up of these containers 
> is also a headache. We have a tool called docker-reaper that automatically 
> reaps the orphaned containers once the executor goes away. In addition to 
> that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We 
> also want to delegate the responsibility of lifecycle management of docker 
> containers to mesos and get rid of the custom executor. We looked at a few 
> alternatives to do this and decided to go with pods because they provide 
> all-or-nothing(atomicity) semantics that we need for our application. But, we 
> cannot use pods directly because all the containers in a pod have the same 
> network namespace. The service discovery mechanism requires all the 
> containers to have separate IPs. All of our microservices bind to  
> container port, so we will have port collision unless we are giving separate 
> namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate 
> namespaces. If NetworkInfo protobuf for nested containers is not empty, then 
> we will assign separate mnt and network namespaces to the nested containers. 
> Otherwise,  they will share the network and mount namepsaces with the 
> parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user sagar8192 commented on the issue:

https://github.com/apache/mesos/pull/263
  
@jdef, @qianzhangxa: I have added some more information about the use case 
to the [ticket](https://issues.apache.org/jira/browse/MESOS-8534). Please check 
it out. We are planning to discuss this in today's containerization sync.


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs 
> multiple tasks in parallel. It is mainly used for running tests that depend 
> on other containerized internal microservices. It was developed before mesos 
> had support for docker-executor. So, it uses a custom executor, which 
> directly talks to docker daemon on the host and run a bunch of service 
> containers along with the process where tests are executed. Resources for all 
> these containers are not accounted for in mesos. Clean-up of these containers 
> is also a headache. We have a tool called docker-reaper that automatically 
> reaps the orphaned containers once the executor goes away. In addition to 
> that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We 
> also want to delegate the responsibility of lifecycle management of docker 
> containers to mesos and get rid of the custom executor. We looked at a few 
> alternatives to do this and decided to go with pods because they provide 
> all-or-nothing(atomicity) semantics that we need for our application. But, we 
> cannot use pods directly because all the containers in a pod have the same 
> network namespace. The service discovery mechanism requires all the 
> containers to have separate IPs. All of our microservices bind to  
> container port, so we will have port collision unless we are giving separate 
> namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate 
> namespaces. If NetworkInfo protobuf for nested containers is not empty, then 
> we will assign separate mnt and network namespaces to the nested containers. 
> Otherwise,  they will share the network and mount namepsaces with the 
> parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user qianzhangxa commented on the issue:

https://github.com/apache/mesos/pull/263
  
I'd like to echo @jdef's comment, we need a clear use case for ip per 
nested container. Our current status is, if framework launches multiple task 
groups (pods) via a single default executor, all the nested containers of all 
these task groups will share the executor's network namespace. This is actually 
different from Kubernetes pod where each pod will have its own network 
namespace and all the container in a pod will share the same network namespace 
so that they can communicated with 127.0.0.1/localhost. IMHO, we should 
consider to do something similar with Kubernetes, i.e., each task group will 
have its own network namespace rather than each nested container has its own 
network namespace unless we have a use case for it.


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user Gilbert88 commented on the issue:

https://github.com/apache/mesos/pull/263
  
A quick note that we could have a followup patch to add documents here: 
http://mesos.apache.org/documentation/latest/containerizer-internals/#linux-namespaces


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jdef commented on the issue:

https://github.com/apache/mesos/pull/263
  
What's the high level use case that's driving this change request? One of 
the major goals of task-groups (pods) is to allow containers to share 
networking and storage. What point is there in launching a nested container 
that DOES NOT share these things with the other containers in the pod?


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168600405
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -570,10 +570,17 @@ Future 
NetworkCniIsolatorProcess::prepare(
 return Failure("Container has already been prepared");
   }
 
+  bool needsSeparateNs = false;
+  if ((containerConfig.has_container_info() &&
+containerConfig.container_info().network_infos().size() > 0) ||
+!containerId.has_parent()) {
+needsSeparateNs = true;
+  }
+
   hashmap containerNetworks;
   Option hostname;
 
-  if (!containerId.has_parent()) {
+  if (needsSeparateNs) {
 const ExecutorInfo& executorInfo = containerConfig.executor_info();
--- End diff --

Not yours, but instead of relying on 
`containerConfig.executor_info().container()`, we should rely on 
`containerConfig.container_info()`. With standalone container being introduced, 
it's possible that the top level container does not have `ExecutorInfo`. This 
will also make the code more consistent with the new change you added above.


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168652532
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -751,10 +751,11 @@ Future 
NetworkCniIsolatorProcess::prepare(
 launchInfo.add_clone_namespaces(CLONE_NEWNET);
 launchInfo.add_clone_namespaces(CLONE_NEWNS);
 launchInfo.add_clone_namespaces(CLONE_NEWUTS);
+infos[containerId]->needsSeparateNs = needsSeparateNs;
   }
 } else {
-  // This is a nested container. This shares the parent's network
-  // and UTS namespace. For non-DEBUG containers it also needs a
+  // This is a nested container and wants to share parent's network
+  // and UTS namespace. For non-DEBUG containers, it also needs a
--- End diff --

```
launchInfo.add_enter_namespaces(CLONE_NEWNET);
launchInfo.add_enter_namespaces(CLONE_NEWUTS);

if (!isDebugContainer) {
  launchInfo.add_clone_namespaces(CLONE_NEWNS);
}


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168655002
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -751,10 +751,11 @@ Future 
NetworkCniIsolatorProcess::prepare(
 launchInfo.add_clone_namespaces(CLONE_NEWNET);
 launchInfo.add_clone_namespaces(CLONE_NEWNS);
 launchInfo.add_clone_namespaces(CLONE_NEWUTS);
+infos[containerId]->needsSeparateNs = needsSeparateNs;
--- End diff --

I'd just store `joinParentNetwork` boolean in the `Info` struct.

Looks like we need some way to checkpoint this information. Otherwise, 
after recovery, how does the isolator tell if it needs to call CNI detach for 
nested container? Currently, since nested container always share with its 
parent, no need to do any cleanup. But it's no longer true with this change.

But I think we can tell if we discover a nested container having 
checkpointed data under `/var/run/mesos/isolators/network/cni/`. See 
`src/slave/containerizer/mesos/isolators/network/cni/paths.hpp` for the 
checkpointing layout. You'll notice this when you properly implement recover() 
method.


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168654738
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -820,18 +821,16 @@ Future NetworkCniIsolatorProcess::isolate(
   CHECK_SOME(rootDir);
   CHECK_SOME(pluginDir);
 
-  if (containerId.has_parent()) {
+  if (!infos[containerId]->needsSeparateNs) {
--- End diff --

I'd make this more explicit.
```
// NOTE: DEBUG container should not have Info struct. Thus if the control
// reaches here, the container is not a DEBUG container.
if (isNestedContainer && joinParentNetwork)
```


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168647358
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -570,10 +570,17 @@ Future 
NetworkCniIsolatorProcess::prepare(
 return Failure("Container has already been prepared");
   }
 
+  bool needsSeparateNs = false;
+  if ((containerConfig.has_container_info() &&
+containerConfig.container_info().network_infos().size() > 0) ||
+!containerId.has_parent()) {
--- End diff --

This is misleading. It's possible that the top level container joins host 
network (thus does not require a separate network namespace). Calling the 
boolean `needsSeparateNs` is misleading.

I think basically the first step in this function is to calculate 
`containerNetworks` and `hostname` for the container. I'd suggest making it 
more explicit:

```c++
hashmap containerNetworks; 
Option hostname;

bool isNestedContainer = containerId.has_parent();
bool isDebugContainer = containerConfig.container_class() == 
ContainerClass::DEBUG;

// Not setting network infos for a nested container means that it'll join 
its parent's networks.
bool joinParentNetwork =
  !containerConfig.has_container_info() ||
  containerConfig.container_info().network_infos().empty();

if (isDebugContainer || (isNestedContainer && joinParentNetwork) {
  ContainerID rootContainerId = protobuf::getRootContainerId(containerId);
  if (infos.contains(rootContainerId)) {
containerNetworks = infos[rootContainerId]->containerNetworks;
  }
} else {
  // Top level container, or nested container joining separate network than 
the parent.
  if (containerConfig.has_container_info()) {
const ContainerInfo& containerInfo = containerConfig.container_info();

if (containerInfo.type() != ContainerInfo::MESOS) {
  return Failure("...");
}

if (containerInfo.has_hostname()) {
  hostname = containerInfo.hostname();
}

int ifIndex = 0;
foreach (...) {
  ...
}
  }
}
```


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168651591
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -570,10 +570,17 @@ Future 
NetworkCniIsolatorProcess::prepare(
 return Failure("Container has already been prepared");
   }
 
+  bool needsSeparateNs = false;
+  if ((containerConfig.has_container_info() &&
+containerConfig.container_info().network_infos().size() > 0) ||
+!containerId.has_parent()) {
+needsSeparateNs = true;
+  }
+
   hashmap containerNetworks;
   Option hostname;
 
-  if (!containerId.has_parent()) {
+  if (needsSeparateNs) {
 const ExecutorInfo& executorInfo = containerConfig.executor_info();
 if (!executorInfo.has_container()) {
--- End diff --

not yours, but let's remove this short circuit here. We should defer the 
decision to below.


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/263#discussion_r168652041
  
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -721,7 +721,7 @@ Future 
NetworkCniIsolatorProcess::prepare(
 env->set_name("LIBPROCESS_IP");
 env->set_value("0.0.0.0");
 
-if (!containerId.has_parent()) {
+if (needsSeparateNs) {
--- End diff --

This should be
```
if (!isDebugContainer && (!nestedContainer || !joinParentNetwork))
```


> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can share 
> namespaces with parent/root container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8534) Allow nested containers in TaskGroups to have separate network namespaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8534:
---

GitHub user sagar8192 opened a pull request:

https://github.com/apache/mesos/pull/263

Allow nested containers in pods to have separate namespaces(Ref: 
MESOS-8534).

This change allows nested containers to have separate network and mount 
namespaces. It also retains the existing functionality, where a nested 
container can attach to parent's network and mount namespace.

I have not fixed/added tests for this. First, I want to make sure that this 
is the right approach. If this change looks good to the reviewers, I will 
fix/add unit tests.

After this change is shipped, the docs also need to be updated.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sagar8192/mesos 
sagarp-MESOS-MESOS-8534-allow-ip-per-container-in-pods

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/263.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #263


commit 68deedb42212c42c6c7719e8432fd6b0031239c4
Author: Sagar Sadashiv Patwardhan 
Date:   2018-02-09T00:50:44Z

Allow nested containers in pods to have separate namespaces.




> Allow nested containers in TaskGroups to have separate network namespaces
> -
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Sagar Sadashiv Patwardhan
>Priority: Minor
>  Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to 
> allow nested containers in TaskGroups to have separate namespaces. I am also 
> going to retain the existing functionality, where nested containers can 
> connect to parent/root containers namespace.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MESOS-8169) master validation incorrectly rejects slaves, buggy executorID checking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8169:
---

Github user jdef commented on the issue:

https://github.com/apache/mesos/pull/248
  
https://issues.apache.org/jira/browse/MESOS-8169


> master validation incorrectly rejects slaves, buggy executorID checking
> ---
>
> Key: MESOS-8169
> URL: https://issues.apache.org/jira/browse/MESOS-8169
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: James DeFelice
>Priority: Major
>  Labels: mesosphere
>
> proposed fix: https://github.com/apache/mesos/pull/248
> I observed this in my environment, where I had two frameworks that used the 
> same ExecutorID and then triggered a master failover. The master refuses to 
> reregister the slave because it's not considering the owning-framework of the 
> ExecutorID when computing ExecutorID uniqueness, and concludes (incorrectly) 
> that there's an erroneous duplicate executor ID:
> {code}
> W1103 00:33:42.509891 19638 master.cpp:6008] Dropping re-registration of 
> agent at slave(1)@10.2.0.7:5051 because it sent an invalid re-registration: 
> Executor has a duplicate ExecutorID 'default'
> {code}
> (yes, "default" is probably a terrible name for an ExecutorID - that's a 
> separate discussion!)
> /cc [~neilc]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-8073) Add per-framework metrics

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-8073:
---

Github user janisz commented on the pull request:


https://github.com/apache/mesos/commit/548aaee3a8f5935457767db1e3b761d873b09cbf#commitcomment-24904496
  
In src/webui/master/static/js/controllers.js:
In src/webui/master/static/js/controllers.js on line 250:
Created an issue for this 
[MESOS-8073](https://issues.apache.org/jira/browse/MESOS-8073)


> Add per-framework metrics
> -
>
> Key: MESOS-8073
> URL: https://issues.apache.org/jira/browse/MESOS-8073
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Priority: Minor
>
> Add per-framework metrics to the master so that the webui does not need to 
> loop over all tasks!
> https://github.com/apache/mesos/commit/548aaee3a8f5935457767db1e3b761d873b09cbf#diff-9f2e9a08332888bca98d111787b3a8c3R249
> Refs: MESOS-7962 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7961) Display task health in the webui.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7961:
---

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/233


> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7962) Display task state counters in the framework page of the webui.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7962:
---

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/234


> Display task state counters in the framework page of the webui.
> ---
>
> Key: MESOS-7962
> URL: https://issues.apache.org/jira/browse/MESOS-7962
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui displays task state counters across all frameworks on the 
> home page, but it does not display the per-framework task state counters when 
> you click in to a particular framework. We should add the task state counters 
> to the per-framework page.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7962) Display task state counters in the framework page of the webui.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7962:
---

GitHub user janisz opened a pull request:

https://github.com/apache/mesos/pull/234

Display task state counters in the framework page.

Fixes: [MESOS-7962](https://issues.apache.org/jira/browse/MESOS-7962)


![screencapture-localhost-5050-1505334897521](https://user-images.githubusercontent.com/1616386/30399457-10e15dd2-98d4-11e7-92bb-502a1f87c3df.png)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/janisz/mesos 
MESOS-7962/Display_task_state_counters_in_the_framework_page_of_the_webui

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/234.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #234


commit c5906b08a62ade1442d435f5b7465a4031780f0d
Author: Tomasz Janiszewski 
Date:   2017-09-13T20:35:42Z

Display task state counters in the framework page.

Fixes: MESOS-7962




> Display task state counters in the framework page of the webui.
> ---
>
> Key: MESOS-7962
> URL: https://issues.apache.org/jira/browse/MESOS-7962
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui displays task state counters across all frameworks on the 
> home page, but it does not display the per-framework task state counters when 
> you click in to a particular framework. We should add the task state counters 
> to the per-framework page.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7961) Display task health in the webui.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7961:
---

GitHub user janisz opened a pull request:

https://github.com/apache/mesos/pull/233

Display task health in the Web UI.

Fixes: MESOS-7961


![screencapture-localhost-5050-1505329729249](https://user-images.githubusercontent.com/1616386/30395983-54332de2-98c8-11e7-8e57-a1d744bb2381.png)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/janisz/mesos 
MESOS-7961/disaply_task_health_state_in_web_UI

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/233.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #233


commit c9faf8ced314860a77a8f2742ee1db4677d0075a
Author: Tomasz Janiszewski 
Date:   2017-09-13T19:10:39Z

Display task health in the Web UI.

Fixes: MESOS-7961




> Display task health in the webui.
> -
>
> Key: MESOS-7961
> URL: https://issues.apache.org/jira/browse/MESOS-7961
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Reporter: Benjamin Mahler
>Assignee: Tomasz Janiszewski
>
> Currently the webui does not display task health based on the latest status 
> update. Since this information is in the protobuf, it is within the webui's 
> scope to display health information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

Github user lycing commented on the issue:

https://github.com/apache/mesos/pull/218
  
this bug is fixed already, close it.


> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

Github user bbannier commented on the issue:

https://github.com/apache/mesos/pull/218
  
For code changes like this one we prefer working with our JIRA and 
reviewboard, https://mesos.apache.org/documentation/latest/submitting-a-patch/. 
Could you submit a review request to reviewboard? You probably also want to 
assign the issue to you.


> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7654) mesos fetcher download files with incorrect permission

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-7654:
---

GitHub user lycing opened a pull request:

https://github.com/apache/mesos/pull/218

MESOS-7654 Fix owner of fetched files in docker containerizer

Fix the wrong owner while mesos-fetcher downloading files，and test passed 
in our production environment，from issue 
[MESOS-7654](https://issues.apache.org/jira/browse/MESOS-7654)
@jieyu @Gilbert88 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lycing/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/218.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #218


commit 8f740dc28a06b055572311ffef8f59aba0ea0eac
Author: lycing 
Date:   2017-06-13T10:43:05Z

Update docker.cpp

fix the wrong owner while mesos-fetcher download files

commit 0a07fed19017b21d5d448746f0870dd374f3a76d
Author: LiuYanchun 
Date:   2017-06-13T14:15:51Z

Fix owner of fetched files in docker containerizer




> mesos fetcher download files with incorrect permission
> --
>
> Key: MESOS-7654
> URL: https://issues.apache.org/jira/browse/MESOS-7654
> Project: Mesos
>  Issue Type: Bug
>  Components: docker, fetcher
>Affects Versions: 1.2.0
>Reporter: chenmingjie
>Priority: Minor
>
> mesos fectcher download uri file as root permission in docker 
> container,though  we have pointed out a common user in CommandInfo  or Task



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-5655) Travis CI currently fails to build PRs from GitHub.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5655:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/165
  
Hi, @dcaba Since Mesos have used Apache CI to perform testings instead of 
travis ci, could refer to https://issues.apache.org/jira/browse/MESOS-5655 for 
the details. And thx @jfarrell, he just disabled the travis ci for Mesos. cc 
@vinodkone 


> Travis CI currently fails to build PRs from GitHub.
> ---
>
> Key: MESOS-5655
> URL: https://issues.apache.org/jira/browse/MESOS-5655
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Till Toenshoff
>Assignee: Jake Farrell
>  Labels: CI, Github
>
> Our travis CI is currently not functional, causing the validation of github 
> PRs to fail. See e.g. https://travis-ci.org/apache/mesos/builds/138507481



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MESOS-6509) Incorrect glyphicons-halflings-regular.woff2 file

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6509:
---

Github user haosdent closed the pull request at:

https://github.com/apache/mesos/pull/176


> Incorrect glyphicons-halflings-regular.woff2 file
> -
>
> Key: MESOS-6509
> URL: https://issues.apache.org/jira/browse/MESOS-6509
> Project: Mesos
>  Issue Type: Bug
>  Components: webui
>Reporter: haosdent
>Assignee: haosdent
>Priority: Minor
>
> We add this font file to fix the incomplete Bootstrap upgrade in 
> https://reviews.apache.org/r/47699/ .The size of 
> glyphicons-halflings-regular.woff2 is 0 now due to review board does support 
> to upload binary files.  
> {code}
> du -sh src/webui/master/static/fonts/*
>  20Ksrc/webui/master/static/fonts/glyphicons-halflings-regular.eot
> 108Ksrc/webui/master/static/fonts/glyphicons-halflings-regular.svg
>  48Ksrc/webui/master/static/fonts/glyphicons-halflings-regular.ttf
>  24Ksrc/webui/master/static/fonts/glyphicons-halflings-regular.woff
>   0Bsrc/webui/master/static/fonts/glyphicons-halflings-regular.woff2
> {code}



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

[jira] [Commented] (MESOS-6509) Incorrect glyphicons-halflings-regular.woff2 file

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6509:
---

GitHub user haosdent opened a pull request:

https://github.com/apache/mesos/pull/176

MESOS-6509 Fix incorrect glyphicons-halflings-regular.woff2.

Because review board doesn't support upload binary files now, I create pull 
request at Github.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/haosdent/mesos MESOS-6509

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/176.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #176


commit d820456aa3927920a02dd26dce9025ee0b8b92ab
Author: Haosdent Huang 
Date:   2016-10-29T17:26:34Z

Fix incorrect glyphicons-halflings-regular.woff2.

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




> Incorrect glyphicons-halflings-regular.woff2 file
> -
>
> Key: MESOS-6509
> URL: https://issues.apache.org/jira/browse/MESOS-6509
> Project: Mesos
>  Issue Type: Bug
>  Components: webui
>Reporter: haosdent
>Assignee: haosdent
>Priority: Minor
>
> We add this font file to fix the incomplete Bootstrap upgrade in 
> https://reviews.apache.org/r/47699/ .The size of 
> glyphicons-halflings-regular.woff2 is 0 now due to review board does support 
> to upload binary files.  



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

[jira] [Commented] (MESOS-6409) mesos-ps - Invalid header value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6409:
---

Github user ronaldpetty closed the pull request at:

https://github.com/apache/mesos/pull/171


> mesos-ps - Invalid header value
> ---
>
> Key: MESOS-6409
> URL: https://issues.apache.org/jira/browse/MESOS-6409
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 1.0.1
> Environment: Linux
>Reporter: Ronald Petty
>Assignee: Ronald Petty
> Fix For: 1.2.0
>
>
> Fresh install on Ubuntu 16.04.  Follow posix instructions then install libz.
> user@nodea:~$ mesos-ps --master=127.0.0.1:5050
> Failed to get the master state: Invalid header value '127.0.0.1:5050\n'
> Master log shows:
> I1017 21:08:28.685926 70112 http.cpp:381] HTTP GET for /master/state from 
> 127.0.0.1:50526 with User-Agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; 
> rv:49.0) Gecko/20100101 Firefox/49.0'
> If you use 'curl' it works:
> curl localhost:5050/state.json
> I also tried 127.0.0.1 and http, also errors out.



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

[jira] [Commented] (MESOS-6409) mesos-ps - Invalid header value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6409:
---

GitHub user ronaldpetty opened a pull request:

https://github.com/apache/mesos/pull/171

Update cli.py

The CLI tools are failing per #MESOS-6409 in 1.0.1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ronaldpetty/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/171.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #171


commit 3891871f256ddb75d4643253cd3cd75f97891e16
Author: Ronald Petty 
Date:   2016-10-18T17:11:59Z

Update cli.py

The CLI tools are failing per #MESOS-6409 in 1.0.1.




> mesos-ps - Invalid header value
> ---
>
> Key: MESOS-6409
> URL: https://issues.apache.org/jira/browse/MESOS-6409
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 1.0.1
> Environment: Linux
>Reporter: Ronald Petty
>
> Fresh install on Ubuntu 16.04.  Follow posix instructions then install libz.
> user@nodea:~$ mesos-ps --master=127.0.0.1:5050
> Failed to get the master state: Invalid header value '127.0.0.1:5050\n'
> Master log shows:
> I1017 21:08:28.685926 70112 http.cpp:381] HTTP GET for /master/state from 
> 127.0.0.1:50526 with User-Agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; 
> rv:49.0) Gecko/20100101 Firefox/49.0'
> If you use 'curl' it works:
> curl localhost:5050/state.json
> I also tried 127.0.0.1 and http, also errors out.



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

[jira] [Commented] (MESOS-6310) Remove or define non-POSIX function

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6310:
---

Github user h0tbird commented on the pull request:


https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20#commitcomment-19287343
  
In src/slave/containerizer/mesos/containerizer.cpp:
In src/slave/containerizer/mesos/containerizer.cpp on line 1945:
Done: [MESOS-6310](https://issues.apache.org/jira/browse/MESOS-6310)


> Remove or define non-POSIX function
> ---
>
> Key: MESOS-6310
> URL: https://issues.apache.org/jira/browse/MESOS-6310
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Affects Versions: 1.0.2
>Reporter: Marc Villacorta
>Priority: Minor
>
> I was trying to compile Mesos using _musl_ inside Alpine Linux 3.4.
> But this [commit| 
> https://github.com/apache/mesos/commit/498d14e934233e4501597b43da3924bfe8b2de20]
>  introduced the {{W_EXITCODE()}} macro which is not defined in _musl_ and 
> seems to be non-POSIX.



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

[jira] [Commented] (MESOS-6210) Master redirect with suffix gets in redirect loop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6210:
---

Github user drcrallen closed the pull request at:

https://github.com/apache/mesos/pull/169


> Master redirect with suffix gets in redirect loop
> -
>
> Key: MESOS-6210
> URL: https://issues.apache.org/jira/browse/MESOS-6210
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Charles Allen
>  Labels: newbie
>
> Trying to go to a URI like 
> {{http://SOME_MASTER:5050/master/redirect/master/frameworks}} ends up in a 
> redirect loop.
> The expected behavior is to either not support anything after {{redirect}} in 
> the path (redirect must be handled by a smart client), or to redirect to the 
> suffix (redirect can be handled by a dumb client).



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

[jira] [Commented] (MESOS-6210) Master redirect with suffix gets in redirect loop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6210:
---

GitHub user drcrallen opened a pull request:

https://github.com/apache/mesos/pull/169

Add smarter master redirects.

* Fix MESOS-6210
* Any path after `/redirect` is now appended to the response
* Does not make any guarantees about non-path components of
the original request
* Updated docs to clarify this behavior.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/metamx/mesos MESOS-6210

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #169






> Master redirect with suffix gets in redirect loop
> -
>
> Key: MESOS-6210
> URL: https://issues.apache.org/jira/browse/MESOS-6210
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Charles Allen
>  Labels: newbie
>
> Trying to go to a URI like 
> {{http://SOME_MASTER:5050/master/redirect/master/frameworks}} ends up in a 
> redirect loop.
> The expected behavior is to either not support anything after {{redirect}} in 
> the path (redirect must be handled by a smart client), or to redirect to the 
> suffix (redirect can be handled by a dumb client).



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

[jira] [Commented] (MESOS-5655) Travis CI currently fails to build PRs from GitHub.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5655:
---

Github user dcaba commented on the issue:

https://github.com/apache/mesos/pull/165
  
Hi @kaysoky , @haosdent !

  thanks so much for your comments. Yep, I see this is not new for the 
project, and I was missing a lot of context when I initiated this PR. So now we 
have two options, from my point of view:
- Dismiss this PR. This integration brings small or no value to the project 
(at a cost of a .travis.yml and keeping the integration active), as the free 
version of travis does not meet all the CI requirements you currently have 
covered with Jenkins.
- Accept the PR. This will fix the "red flag" we can see in all the PRs, 
and this job will potentially provide quicker feedback as we are only compiling 
in the end (while Jenkins will bring the results of all the test coverage later)

   Please, make the decision bearing in mind what's more convenient for the 
project... No rancor at all if you close without merge ;) (it was an exercise 
requiring small efforts). But I'd appreciate the related Jira issue is closed 
(MESOS-5655) an you actually disable Travis to prevent these red crosses to add 
noise to all PRs.

Best,


> Travis CI currently fails to build PRs from GitHub.
> ---
>
> Key: MESOS-5655
> URL: https://issues.apache.org/jira/browse/MESOS-5655
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Till Toenshoff
>  Labels: CI, Github
>
> Our travis CI is currently not functional, causing the validation of github 
> PRs to fail. See e.g. https://travis-ci.org/apache/mesos/builds/138507481



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

[jira] [Commented] (MESOS-5655) Travis CI currently fails to build PRs from GitHub.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5655:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/165
  
Some experience to make it faster as well. 
https://reviews.apache.org/r/39257/diff/1#index_header (`- 
CXXFLAGS=-gsplit-dwarf`)
But I think we give up travis ci long time ago? Refer to 
https://issues.apache.org/jira/browse/MESOS-5655?focusedCommentId=15339918=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15339918


> Travis CI currently fails to build PRs from GitHub.
> ---
>
> Key: MESOS-5655
> URL: https://issues.apache.org/jira/browse/MESOS-5655
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Till Toenshoff
>  Labels: CI, Github
>
> Our travis CI is currently not functional, causing the validation of github 
> PRs to fail. See e.g. https://travis-ci.org/apache/mesos/builds/138507481



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

[jira] [Commented] (MESOS-6098) Frameworks UI shows metrics for used resources plus offers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6098:
---

Github user asfgit closed the pull request at:

https://github.com/apache/mesos/pull/162


> Frameworks UI shows metrics for used resources plus offers
> --
>
> Key: MESOS-6098
> URL: https://issues.apache.org/jira/browse/MESOS-6098
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Affects Versions: 1.0.1
>Reporter: Miguel Bernadin
>Assignee: Joseph Wu
>Priority: Minor
>
> When a framework is receiving many offers and it is denying them, the 
> frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. 
> From a mesos perspective, those offers are given to the framework until the 
> framework declines them, so depending on the time the mesos UI gets updated, 
> its has combined all the used resources and offers (that have not been 
> accepted) to the framework and is reflected on the framework UI. If a 
> framework does not implement suppressiveOffers(), it will continue to deny 
> offers from mesos, which leads to the sporadic changes of metrics on the 
> framework UI. 
> From the operator's perspective, the user would expect to see used resources 
> consumed by the framework. Any offered resources can be viewed instead by 
> Mesos's Offers tab.



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

[jira] [Commented] (MESOS-6098) Frameworks UI shows metrics for used resources plus offers

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6098:
---

GitHub user bernadinm opened a pull request:

https://github.com/apache/mesos/pull/162

Frameworks UI shows metrics for used resources plus offers

https://issues.apache.org/jira/browse/MESOS-6098

When a framework is receiving many offers and it is denying them, the 
frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk.
From a mesos perspective, those offers are given to the framework until the 
framework declines them, so depending on the time the mesos UI gets updated, 
its has combined all the used resources and offers (that have not been 
accepted) to the framework and is reflected on the framework UI. If a framework 
does not implement suppressiveOffers(), it will continue to deny offers from 
mesos, which leads to the sporadic changes of metrics on the framework UI.
From the operator's perspective, the user would expect to see used 
resources consumed by the framework. Any offered resources can be viewed 
instead by Mesos's Offers tab.

cc: @kaysoky 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bernadinm/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/162.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #162


commit b4296aeaf0e219885e62490f98cf2aed976f7984
Author: Miguel Bernadin 
Date:   2016-08-26T23:06:09Z

update Mesos UI to reflect used resources

commit b0bc9ce7f1c18bdc024c8bc5f16373cc1acb191f
Author: Miguel Bernadin 
Date:   2016-08-26T23:21:09Z

Update Mesos UI to reflect used resources




> Frameworks UI shows metrics for used resources plus offers
> --
>
> Key: MESOS-6098
> URL: https://issues.apache.org/jira/browse/MESOS-6098
> Project: Mesos
>  Issue Type: Improvement
>  Components: webui
>Affects Versions: 1.0.1
>Reporter: Miguel Bernadin
>Assignee: Miguel Bernadin
>Priority: Minor
>
> When a framework is receiving many offers and it is denying them, the 
> frameworks UI will show the metrics fluctuating for mem, cpu, gpu, and disk. 
> From a mesos perspective, those offers are given to the framework until the 
> framework declines them, so depending on the time the mesos UI gets updated, 
> its has combined all the used resources and offers (that have not been 
> accepted) to the framework and is reflected on the framework UI. If a 
> framework does not implement suppressiveOffers(), it will continue to deny 
> offers from mesos, which leads to the sporadic changes of metrics on the 
> framework UI. 
> From the operator's perspective, the user would expect to see used resources 
> consumed by the framework. Any offered resources can be viewed instead by 
> Mesos's Offers tab.



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

[jira] [Commented] (MESOS-1209) Latest build fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-1209:
---

Github user jfarrell closed the pull request at:

https://github.com/apache/mesos/pull/14


> Latest build fails
> --
>
> Key: MESOS-1209
> URL: https://issues.apache.org/jira/browse/MESOS-1209
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.19.0
> Environment: debian sid
> #define PACKAGE_STRING "mesos 0.19.0"
> #define PACKAGE "mesos"
> #define STDC_HEADERS 1
> #define HAVE_SYS_TYPES_H 1
> #define HAVE_SYS_STAT_H 1
> #define HAVE_STDLIB_H 1
> #define HAVE_STRING_H 1
> #define HAVE_MEMORY_H 1
> #define HAVE_STRINGS_H 1
> #define HAVE_INTTYPES_H 1
> #define HAVE_STDINT_H 1
> #define HAVE_UNISTD_H 1
> #define HAVE_DLFCN_H 1
> #define HAVE_PTHREAD 1
> #define MESOS_HAS_JAVA 1
> #define HAVE_PYTHON "2.7"
> #define MESOS_HAS_PYTHON 1
> #define HAVE_LIBZ 1
> #define HAVE_LIBCURL 1
> #define HAVE_LIBSASL2 1
>Reporter: james michael dupont
>Assignee: james michael dupont
>
> make check fails 
> [  FAILED  ] OsTest.release
> [ RUN  ] OsTest.release
> stout/tests/os_tests.cpp:279: Failure
> info: Failed to parse: 3.10-1-amd64
> [  FAILED  ] OsTest.release (0 ms)
> Output of : uname -a
> Linux mdupont-Aspire-7750G 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) 
> x86_64 GNU/Linux



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

[jira] [Commented] (MESOS-987) Wire up a code coverage tool

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-987:
--

Github user jfarrell closed the pull request at:

https://github.com/apache/mesos/pull/15


> Wire up a code coverage tool
> 
>
> Key: MESOS-987
> URL: https://issues.apache.org/jira/browse/MESOS-987
> Project: Mesos
>  Issue Type: Improvement
>  Components: technical debt
>Reporter: Vinod Kone
>Assignee: Dominic Hamon
> Fix For: 0.20.0
>
> Attachments: lcov.png
>
>
> Some options are gcov (works only with gcc afaict) and optionally lcov.
> It would be nice to hook this up with Jenkins too.
> http://meekrosoft.wordpress.com/2010/06/02/continuous-code-coverage-with-gcc-googletest-and-hudson/



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

[jira] [Commented] (MESOS-1209) Latest build fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-1209:
---

Github user jfarrell commented on the issue:

https://github.com/apache/mesos/pull/14
  
Closing as requested in https://s.apache.org/V8r3


> Latest build fails
> --
>
> Key: MESOS-1209
> URL: https://issues.apache.org/jira/browse/MESOS-1209
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.19.0
> Environment: debian sid
> #define PACKAGE_STRING "mesos 0.19.0"
> #define PACKAGE "mesos"
> #define STDC_HEADERS 1
> #define HAVE_SYS_TYPES_H 1
> #define HAVE_SYS_STAT_H 1
> #define HAVE_STDLIB_H 1
> #define HAVE_STRING_H 1
> #define HAVE_MEMORY_H 1
> #define HAVE_STRINGS_H 1
> #define HAVE_INTTYPES_H 1
> #define HAVE_STDINT_H 1
> #define HAVE_UNISTD_H 1
> #define HAVE_DLFCN_H 1
> #define HAVE_PTHREAD 1
> #define MESOS_HAS_JAVA 1
> #define HAVE_PYTHON "2.7"
> #define MESOS_HAS_PYTHON 1
> #define HAVE_LIBZ 1
> #define HAVE_LIBCURL 1
> #define HAVE_LIBSASL2 1
>Reporter: james michael dupont
>Assignee: james michael dupont
>
> make check fails 
> [  FAILED  ] OsTest.release
> [ RUN  ] OsTest.release
> stout/tests/os_tests.cpp:279: Failure
> info: Failed to parse: 3.10-1-amd64
> [  FAILED  ] OsTest.release (0 ms)
> Output of : uname -a
> Linux mdupont-Aspire-7750G 3.10-1-amd64 #1 SMP Debian 3.10.3-1 (2013-07-27) 
> x86_64 GNU/Linux



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

[jira] [Commented] (MESOS-6084) Deprecate and remove the included MPI framework

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6084:
---

Github user kaysoky commented on the issue:

https://github.com/apache/mesos/pull/28
  
This MPI code likely does not work anymore, as there is no maintainer for 
it.  I've opened https://issues.apache.org/jira/browse/MESOS-6084 to track the 
deprecation of the MPI framework.


> Deprecate and remove the included MPI framework
> ---
>
> Key: MESOS-6084
> URL: https://issues.apache.org/jira/browse/MESOS-6084
> Project: Mesos
>  Issue Type: Task
>Affects Versions: 1.0.0
>Reporter: Joseph Wu
>Priority: Minor
>  Labels: mpi
>
> The Mesos codebase still includes code for an 
> [MPI|http://www.mcs.anl.gov/research/projects/mpi/] framework.  This code has 
> been untouched and probably not used since around Mesos 0.9.0.  Since we 
> don't support this code anymore, we should deprecate and remove it.
> The code is located here:
> https://github.com/apache/mesos/tree/db4c8a0e9eaf27f3e2d42a620a5e612863cbf9ea/mpi



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

[jira] [Commented] (MESOS-6056) add NOOP Container Logger for mesos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6056:
---

Github user IvanJobs closed the pull request at:

https://github.com/apache/mesos/pull/159


> add NOOP Container Logger for mesos
> ---
>
> Key: MESOS-6056
> URL: https://issues.apache.org/jira/browse/MESOS-6056
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization, slave
>Affects Versions: 1.0.0
> Environment: mesos 1.0.0, docker
>Reporter: IvanJobs
>Priority: Trivial
>  Labels: easyfix, features
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> mesos has two Container Loggers in its source files. 
> One is build into mesos-agent: sandbox Container Logger, it just redirects 
> stderr/stdout to sandbox, causing fill disk usage problem.
> The other is LogrotateContainerLogger module lib, it's good, we can make sure 
> stdout/stderr in sandbox be in a constant size.
> But there is a common need: don't write stdout/stderr into sandbox, pity, we 
> don't have any flags for turning it off. 
> This is a come around for this: developing a new module lib for 
> ContainerLogger for doing nothing(redirect stdout/stderr to /dev/null)
> yep, that's it. We need a NOOP ContainerLogger, BTW, FYI, we can also 
> retrieve stderr/stdout from docker daemon either.



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

[jira] [Commented] (MESOS-6056) add NOOP Container Logger for mesos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6056:
---

Github user IvanJobs commented on the issue:

https://github.com/apache/mesos/pull/159
  
Well, actually after communication with Joseph Wu, I think this NOOP 
Container Logger is not so common and should not be accept by mesos community. 
So just forget about it. But if you have special use case and want to use this, 
I'm happy about that


> add NOOP Container Logger for mesos
> ---
>
> Key: MESOS-6056
> URL: https://issues.apache.org/jira/browse/MESOS-6056
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization, slave
>Affects Versions: 1.0.0
> Environment: mesos 1.0.0, docker
>Reporter: IvanJobs
>Priority: Trivial
>  Labels: easyfix, features
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> mesos has two Container Loggers in its source files. 
> One is build into mesos-agent: sandbox Container Logger, it just redirects 
> stderr/stdout to sandbox, causing fill disk usage problem.
> The other is LogrotateContainerLogger module lib, it's good, we can make sure 
> stdout/stderr in sandbox be in a constant size.
> But there is a common need: don't write stdout/stderr into sandbox, pity, we 
> don't have any flags for turning it off. 
> This is a come around for this: developing a new module lib for 
> ContainerLogger for doing nothing(redirect stdout/stderr to /dev/null)
> yep, that's it. We need a NOOP ContainerLogger, BTW, FYI, we can also 
> retrieve stderr/stdout from docker daemon either.



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

[jira] [Commented] (MESOS-6056) add NOOP Container Logger for mesos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6056:
---

GitHub user IvanJobs opened a pull request:

https://github.com/apache/mesos/pull/159

MESOS-6056 add NOOP Container Logger for mesos.

mesos has two Container Loggers in its source files. 
One is build into mesos-agent: sandbox Container Logger, it just redirects 
stderr/stdout to sandbox, causing fill disk usage problem.
The other is LogrotateContainerLogger module lib, it's good, we can make 
sure stdout/stderr in sandbox be in a constant size.
But there is a common need: don't write stdout/stderr into sandbox, pity, 
we don't have any flags for turning it off. 

This is a come around for this: developing a new module lib for 
ContainerLogger for doing nothing(redirect stdout/stderr to /dev/null)

yep, that's it. We need a NOOP ContainerLogger,.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/IvanJobs/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/159.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #159


commit 3afdacffee17b87af6677b9dc7687022b76dea15
Author: IvanJobs 
Date:   2016-08-19T10:21:23Z

MESOS-6056 add NOOP Container Logger for mesos.




> add NOOP Container Logger for mesos
> ---
>
> Key: MESOS-6056
> URL: https://issues.apache.org/jira/browse/MESOS-6056
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization, slave
>Affects Versions: 1.0.0
> Environment: mesos 1.0.0, docker
>Reporter: IvanJobs
>Priority: Trivial
>  Labels: easyfix, features
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> mesos has two Container Loggers in its source files. 
> One is build into mesos-agent: sandbox Container Logger, it just redirects 
> stderr/stdout to sandbox, causing fill disk usage problem.
> The other is LogrotateContainerLogger module lib, it's good, we can make sure 
> stdout/stderr in sandbox be in a constant size.
> But there is a common need: don't write stdout/stderr into sandbox, pity, we 
> don't have any flags for turning it off. 
> This is a come around for this: developing a new module lib for 
> ContainerLogger for doing nothing(redirect stdout/stderr to /dev/null)
> yep, that's it. We need a NOOP ContainerLogger, BTW, FYI, we can also 
> retrieve stderr/stdout from docker daemon either.



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user aaronjwood closed the pull request at:

https://github.com/apache/mesos/pull/157


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user aaronjwood commented on the issue:

https://github.com/apache/mesos/pull/157
  
It looks like I was wrong about this, I had thought the copy constructor of 
tuple was getting called when it wasn't the copy constructor at all. I did some 
more testing with this and found that the original version behaves properly.


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/157
  
You could join via https://mesos-slackin.herokuapp.com/


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user aaronjwood commented on the issue:

https://github.com/apache/mesos/pull/157
  
I don't have access to their Slack but I agree.


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/157
  
By the way, copy a comment from @jpeach in 
https://mesos.slack.com/messages/cxx/

```
Promise promise = Promise();

why not just
```Promise promise;```
``


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user aaronjwood commented on the issue:

https://github.com/apache/mesos/pull/157
  
No no, that's okay. I appreciate everyone helping me validate these 
changes. I'm trying to be very careful with this :)


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/157
  
>Even though the Promise is local to the stack, when we return Future 
shouldn't it be a copy of what's needed underneath?

Sorry, I misunderstanding something before. Future store its data in 
`std::shared_ptr data` and your function return a copy instead of const 
reference, so it should work.


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user aaronjwood commented on the issue:

https://github.com/apache/mesos/pull/157
  
I might be misunderstanding things but why can we not do this? I see it 
being done here 
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/http.cpp#L1001

If we make the `Promise` local like it is in this patch, pass its address 
into the tuple via the copy constructor (that should be the copy constructor 
getting called, right?) so that it takes a copy and doesn't rely on an actual 
address from the stack, and return the future in the same way as the example 
above, would that not work? Even though the `Promise` is local to the stack, 
when we return `Future` shouldn't it be a copy of what's needed underneath?


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/157
  
+1 For what @Vish0007 said. If promise became a locale scope object here, 
return its future seems incorrect. I search `return \S+\.future\(\);` in all 
exists code, all `Promise` are member objects or heap objects.


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-6038) Prevent leaking allocated memory for Promises

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-6038:
---

Github user Vish0007 commented on the issue:

https://github.com/apache/mesos/pull/157
  
@aaronjwood  the "promise" object you have has local scope (and lifetime) 
and its not valid outside the method; I am sure valgrind wold report this as 
error;


> Prevent leaking allocated memory for Promises
> -
>
> Key: MESOS-6038
> URL: https://issues.apache.org/jira/browse/MESOS-6038
> Project: Mesos
>  Issue Type: Bug
>  Components: c++ api, libprocess
>Reporter: Aaron Wood
>Priority: Minor
>  Labels: github-import, patch
>
> I had found a few places where these Promise objects were leaking. Once the 
> Future was returned there was no way to free the memory for the Promise 
> object that had been allocated thus causing the leak.
> https://reviews.apache.org/r/51068/
> https://github.com/apache/mesos/pull/157



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

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user radekg commented on the issue:

https://github.com/apache/mesos/pull/153
  
Fix in https://github.com/apache/mesos/pull/158


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: Cannot change ownership to uid 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user radekg commented on the issue:

https://github.com/apache/mesos/pull/158
  
  from me to merge this


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: Cannot change ownership to uid 501, gid 10: 
> 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/158
  
@radekg Yes, I think to change the incorrect permissions in the tar 
packages is better than add `--no-same-owener` as a workaround.


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/158
  
cc @tillt @karya0 @radekg


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: Cannot change ownership to uid 501, gid 10: 
> 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

GitHub user haosdent opened a pull request:

https://github.com/apache/mesos/pull/158

Fixed MESOS-5925 Building Mesos in Docker Beta on OS X

* Replaced gmock-1.7.0.tar.gz with a correct permissions version.
* Replaced gperftools-2.5.tar.gz with a correct permissions version.

Because I found upload binary changes does not work in 
https://reviews.apache.org/r/51079/ and  https://reviews.apache.org/r/51080/,  
I open this pull request.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/haosdent/mesos MESOS-5925

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/158.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #158


commit fc1a27c7e5b30835f1750dce0915814d080559ab
Author: Haosdent Huang 
Date:   2016-08-14T04:20:00Z

Replaced gmock-1.7.0.tar.gz with a correct permissions version.

Some files' permissions in gmock-1.7.0.tar.gz are '0444/-r--r--r--',
which means owner don't have write permission on them. This breaks the
build of Mesos since Docker 1.12 on MacOS. This patch packaged
gmock-1.7.0.tar.gz with correct permissions.

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

commit a34f189015d7f964af9fa5378beda258f9c315f0
Author: Haosdent Huang 
Date:   2016-08-14T04:30:11Z

Replaced gperftools-2.5.tar.gz with a correct permissions version.

Some files' permissions in gperftools-2.5.tar.gz are
'0444/-r--r--r--', which means owner don't have write permission on
them. This breaks the build of Mesos since Docker 1.12 on MacOS. This
patch packaged gperftools-2.5.tar.gz with correct permissions.

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




> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
OK, I think I find the root cause. 

```
$ stat test/gmock-port_test.cc
  File: 'test/gmock-port_test.cc'
  Size: 2020Blocks: 4  IO Block: 512regular file
Device: 28h/40d Inode: 37331162Links: 1
Access: (0444/-r--r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 1970-01-01 00:00:00.0 +
Modify: 2013-09-18 17:50:15.0 +
Change: 2016-08-14 04:06:55.0 +
 Birth: -
```

```
$ stat ./.git/objects/pack/pack-4ad0e5887c21e2edcca6e6b0af3851568bbee729.idx
  File: 
'./.git/objects/pack/pack-4ad0e5887c21e2edcca6e6b0af3851568bbee729.idx'
  Size: 144180  Blocks: 282IO Block: 512regular file
Device: 28h/40d Inode: 37330833Links: 1
Access: (0444/-r--r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2016-08-14 04:08:46.0 +
Modify: 2016-04-19 21:45:36.0 +
Change: 2016-08-14 04:06:51.0 +
 Birth: -
```

Those files are `-r--r--r--`, which don't allow to write.  Docker is 
correct.


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
As I checked, only gmock-1.7.0 and gperftools-2.5 encounter this problem. 
If I use the releases from https://github.com/google/googlemock/releases, it 
works fine.

And for other tars, although there are packaged with different users. They 
still could be unpacked successfully.

```
$ tar --list -v --file boost-1.53.0.tar.gz  | head -2
drwxr-xr-x jie/staff 0 2016-01-18 07:35 boost-1.53.0/
drwxr-xr-x jie/staff 0 2016-01-18 07:34 boost-1.53.0/boost/
```


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user radekg commented on the issue:

https://github.com/apache/mesos/pull/153
  
@haosdent:

```
[rad] Downloads $ uname -a
Darwin moan.fttx-di01-b07.german-fiber.net 15.4.0 Darwin Kernel Version 
15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 
x86_64
[rad] Downloads $ ls -la | grep zookeeper
-rw-r--r--@   1 rad  staff22261552 Jun  7 16:57 zookeeper-3.4.8.tar.gz
[rad] Downloads $ tar xvf zookeeper-3.4.8.tar.gz --no-same-owner
x zookeeper-3.4.8/
x zookeeper-3.4.8/zookeeper-3.4.8.jar.md5
x zookeeper-3.4.8/zookeeper-3.4.8.jar.asc
x zookeeper-3.4.8/zookeeper-3.4.8.jar
x zookeeper-3.4.8/contrib/
x zookeeper-3.4.8/contrib/ZooInspector/
x zookeeper-3.4.8/contrib/ZooInspector/icons/
x zookeeper-3.4.8/contrib/ZooInspector/icons/launch_run.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/save_edit.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/new_con.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/search_prev.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/file_obj.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/launch_stop.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/jspdecl.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/fldr_obj.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/refresh.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/info_obj.gif
x zookeeper-3.4.8/contrib/ZooInspector/icons/search_next.gif
...
[rad] Downloads $ ls -la | grep zookeeper
drwxr-xr-x@  22 rad  staff 748 Feb  6  2016 zookeeper-3.4.8
-rw-r--r--@   1 rad  staff22261552 Jun  7 16:57 zookeeper-3.4.8.tar.gz
```

@tillt I'm all for fixing this in docker, the only thing that worries me is 
the amount of time it takes docker to fix this (if this is a bug and not a 
_feature_ of the new Docker for mac). The `--no-same-owner` option has zero 
impact on anything and works fine in every case. The patch does not break 
anything. It seems that the tar option was designed specifically for such 
situations, why not to take advantage of it and have the `Makefile` working in 
every situation and report to docker that the problem exists. Thoughts?


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
@tillt That make sense. I am finding if it has tracked in docker issues, 
otherwise I could file one.


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user tillt commented on the issue:

https://github.com/apache/mesos/pull/153
  
If it truly is a bug of docker, then we should get that fixed upstream, no? 


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
It looks like a bug of docker mount volume in OS X.

```
root@7f689b81a4bb:~/workspace/cpp/mesos/build/gmock-1.7.0# chown root:root 
test/gmock_test_utils.py
chown: changing ownership of 'test/gmock_test_utils.py': Permission denied
``` 


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user tillt commented on the issue:

https://github.com/apache/mesos/pull/153
  
Why exactly do we need this patch?

I understand it solves the problem for the OP but WHY does the problem even 
occur?
As far as I understand, the option `--no-same-owner` is only effective when 
being invoked by `root` - so if `root` was the current user, why would we get a 
permission denied? I would like to understand the actual problem.


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
Verify OS X tar would ignore unknow flags. So it works in OS X. 

+1 for this change.


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: 

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

Github user haosdent commented on the issue:

https://github.com/apache/mesos/pull/153
  
Run `man tar` in OS X could not find this option: `no-same-owner`.  I think 
we should make sure this patch don't break OS X?


> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> 

[jira] [Commented] (MESOS-5958) Reviewbot failing due to python files not being cleaned up after distclean

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5958:
---

Github user vinodkone commented on the issue:

https://github.com/apache/mesos/pull/36
  
I think this broke the ReviewBot. See 
https://issues.apache.org/jira/browse/MESOS-5958


> Reviewbot failing due to python files not being cleaned up after distclean
> --
>
> Key: MESOS-5958
> URL: https://issues.apache.org/jira/browse/MESOS-5958
> Project: Mesos
>  Issue Type: Bug
> Environment: ASF CI
>Reporter: Vinod Kone
>Priority: Critical
>
> This is on ASF CI. 
> https://builds.apache.org/job/mesos-reviewbot/14573/consoleFull
> {code}
> find python -name "build" -o -name "dist" -o -name "*.pyc"\
> -o -name "*.egg-info" -exec rm -rf '{}' \+
> test -z "libmesos_no_3rdparty.la libbuild.la liblog.la libstate.la libjava.la 
> libexamplemodule.la libtestallocator.la libtestanonymous.la 
> libtestauthentication.la libtestauthorizer.la libtestcontainer_logger.la 
> libtesthook.la libtesthttpauthenticator.la libtestisolator.la 
> libtestmastercontender.la libtestmasterdetector.la libtestqos_controller.la 
> libtestresource_estimator.la" || rm -f libmesos_no_3rdparty.la libbuild.la 
> liblog.la libstate.la libjava.la libexamplemodule.la libtestallocator.la 
> libtestanonymous.la libtestauthentication.la libtestauthorizer.la 
> libtestcontainer_logger.la libtesthook.la libtesthttpauthenticator.la 
> libtestisolator.la libtestmastercontender.la libtestmasterdetector.la 
> libtestqos_controller.la libtestresource_estimator.la
> test -z "liblogrotate_container_logger.la libfixed_resource_estimator.la 
> libload_qos_controller.la " || rm -f liblogrotate_container_logger.la 
> libfixed_resource_estimator.la libload_qos_controller.la 
>  rm -f mesos-fetcher mesos-executor mesos-containerizer 
> mesos-logrotate-logger mesos-health-check mesos-usage mesos-docker-executor
>  rm -f mesos-agent mesos-master mesos-slave
> rm -f ./so_locations
> rm -f *.o
> rm -f *.lo
> rm -f ../include/mesos/*.o
> rm -f ./so_locations
> rm -f *.tab.c
> test -z "" || rm -f 
> rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
> rm -f ./so_locations
> rm -f ../include/mesos/*.lo
> test . = "../../src" || test -z "" || rm -f 
> rm -f ../include/mesos/.deps/.dirstamp
> rm -f ../include/mesos/agent/*.o
> rm -f ../include/mesos/agent/*.lo
> rm -f ../include/mesos/.dirstamp
> rm -f ../include/mesos/allocator/*.o
> rm -f ../include/mesos/agent/.deps/.dirstamp
> rm -f ../include/mesos/allocator/*.lo
> rm -f ../include/mesos/agent/.dirstamp
> rm -f ../include/mesos/appc/*.o
> rm -f ../include/mesos/allocator/.deps/.dirstamp
> rm -f ../include/mesos/appc/*.lo
> rm -f ../include/mesos/allocator/.dirstamp
> rm -f ../include/mesos/authentication/*.o
> rm -f ../include/mesos/appc/.deps/.dirstamp
> rm -f ../include/mesos/authentication/*.lo
> rm -f ../include/mesos/appc/.dirstamp
> rm -f ../include/mesos/authorizer/*.o
> rm -f ../include/mesos/authentication/.deps/.dirstamp
> rm -f ../include/mesos/authorizer/*.lo
> rm -f ../include/mesos/authentication/.dirstamp
> rm -f ../include/mesos/containerizer/*.o
> rm -f ../include/mesos/authorizer/.deps/.dirstamp
> rm -f ../include/mesos/containerizer/*.lo
> rm -f ../include/mesos/authorizer/.dirstamp
> rm -f ../include/mesos/docker/*.o
> rm -f ../include/mesos/containerizer/.deps/.dirstamp
> rm -f ../include/mesos/docker/*.lo
> rm: cannot remove 'python/cli/build': Is a directory
> rm: cannot remove 'python/executor/build': Is a directory
> rm: cannot remove 'python/interface/build': Is a directory
> rm: cannot remove 'python/native/build': Is a directory
> rm: cannot remove 'python/scheduler/build': Is a directory
> rm -f ../include/mesos/containerizer/.dirstamp
> make[2]: [clean-generic] Error 1 (ignored)
> rm -f ../include/mesos/executor/*.o
> rm -f ../include/mesos/docker/.deps/.dirstamp
> rm -f ../include/mesos/executor/*.lo
> rm -f ../include/mesos/docker/.dirstamp
> rm -f ../include/mesos/fetcher/*.o
> rm -f ../include/mesos/executor/.deps/.dirstamp
> rm -f ../include/mesos/fetcher/*.lo
> rm -f ../include/mesos/executor/.dirstamp
> rm -f ../include/mesos/maintenance/*.o
> rm -f ../include/mesos/fetcher/.deps/.dirstamp
> rm -f ../include/mesos/maintenance/*.lo
> rm -f ../include/mesos/fetcher/.dirstamp
> rm -f ../include/mesos/master/*.o
> rm -f ../include/mesos/maintenance/.deps/.dirstamp
> rm -f ../include/mesos/master/*.lo
> rm -f ../include/mesos/module/*.o
> rm -f ../include/mesos/maintenance/.dirstamp
> rm -f ../include/mesos/module/*.lo
> rm -f ../include/mesos/master/.deps/.dirstamp
> rm -f ../include/mesos/master/.dirstamp
> rm -f ../include/mesos/quota/*.o
> rm -f ../include/mesos/module/.deps/.dirstamp

[jira] [Commented] (MESOS-5925) Building Mesos in Docker Beta on OS X fails - tar issue in Makefile

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-5925:
---

GitHub user radekg opened a pull request:

https://github.com/apache/mesos/pull/153

[MESOS-5925] Building Mesos in Docker Beta on OS X fails - tar issue …

…in Makefile

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/radekg/mesos master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/153.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #153


commit 5852b9f3f57daccedfff14698612818e961a9f6b
Author: radekg 
Date:   2016-07-28T23:45:58Z

[MESOS-5925] Building Mesos in Docker Beta on OS X fails - tar issue in 
Makefile




> Building Mesos in Docker Beta on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: 

[jira] [Commented] (MESOS-4370) NetworkSettings.IPAddress field is deprecated in Docker

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MESOS-4370:
---

Github user jfarrell commented on the issue:

https://github.com/apache/mesos/pull/90
  
Closing per request at https://s.apache.org/V8r3


> NetworkSettings.IPAddress field is deprecated in Docker
> ---
>
> Key: MESOS-4370
> URL: https://issues.apache.org/jira/browse/MESOS-4370
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.0
> Environment: Ubuntu 14.04
> Docker 1.9.1, Docker 1.10.x
>Reporter: Clint Armstrong
>Assignee: Timothy Chen
>  Labels: Blocker
> Fix For: 0.28.0
>
>
> The latest docker API deprecates the NetworkSettings.IPAddress field, in 
> favor of the NetworkSettings.Networks field.
> https://docs.docker.com/engine/reference/api/docker_remote_api/#v1-21-api-changes
> With this deprecation, NetworkSettings.IPAddress is not populated for 
> containers running with networks that use new network plugins.
> As a result the mesos API has no data in 
> container_status.network_infos.ip_address or 
> container_status.network_infos.ipaddresses.
> The immediate impact of this is that mesos-dns is unable to retrieve a 
> containers IP from the netinfo interface.



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