[jira] [Commented] (MESOS-7605) UCR doesn't isolate uts namespace w/ host networking

2017-07-11 Thread James Peach (JIRA) 

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

James Peach commented on MESOS-7605:


Assigning to me. What I would like to do here is simply enter a UTS namespace 
when using host networking. If the task is using a container image then we can 
probably support setting the hostname and updating the relevant config files as 
well.

> UCR doesn't isolate uts namespace w/ host networking
> 
>
> Key: MESOS-7605
> URL: https://issues.apache.org/jira/browse/MESOS-7605
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: James DeFelice
>Assignee: James Peach
>  Labels: mesosphere
>
> Docker's {{run}} command supports a {{--hostname}} parameter which impacts 
> container isolation, even in {{host}} network mode: (via 
> https://docs.docker.com/engine/reference/run/)
> {quote}
> Even in host network mode a container has its own UTS namespace by default. 
> As such --hostname is allowed in host network mode and will only change the 
> hostname inside the container. Similar to --hostname, the --add-host, --dns, 
> --dns-search, and --dns-option options can be used in host network mode.
> {quote}
> I see no evidence that UCR offers a similar isolation capability.
> Related: the {{ContainerInfo}} protobuf has a {{hostname}} field which was 
> initially added to support the Docker containerizer's use of the 
> {{--hostname}} Docker {{run}} flag.



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

[jira] [Assigned] (MESOS-7605) UCR doesn't isolate uts namespace w/ host networking

2017-07-11 Thread James Peach (JIRA) 

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

James Peach reassigned MESOS-7605:
--

Assignee: James Peach

> UCR doesn't isolate uts namespace w/ host networking
> 
>
> Key: MESOS-7605
> URL: https://issues.apache.org/jira/browse/MESOS-7605
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: James DeFelice
>Assignee: James Peach
>  Labels: mesosphere
>
> Docker's {{run}} command supports a {{--hostname}} parameter which impacts 
> container isolation, even in {{host}} network mode: (via 
> https://docs.docker.com/engine/reference/run/)
> {quote}
> Even in host network mode a container has its own UTS namespace by default. 
> As such --hostname is allowed in host network mode and will only change the 
> hostname inside the container. Similar to --hostname, the --add-host, --dns, 
> --dns-search, and --dns-option options can be used in host network mode.
> {quote}
> I see no evidence that UCR offers a similar isolation capability.
> Related: the {{ContainerInfo}} protobuf has a {{hostname}} field which was 
> initially added to support the Docker containerizer's use of the 
> {{--hostname}} Docker {{run}} flag.



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

[jira] [Commented] (MESOS-7605) UCR doesn't isolate uts namespace w/ host networking

2017-07-11 Thread James Peach (JIRA) 

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

James Peach commented on MESOS-7605:


{quote}
It also implies that it's impossible to give a container permission to *bind* 
to a host network port without also giving it permission to *change the host's 
network name*. This feels like a security hole to me.
{quote}

The task would only have permission to change the hostname if it is privileged 
with the right capabilities or running as root. I think this is expected 
behavior, not a security hole.

The reason we didn't apply UTS namespace in host networking was because we were 
not sure whether to allow the kernel hostname to diverge from the hostname 
stored in the system files. However, thinking about this some more, I don't see 
any reason to not enter a UTS namespace when we are using host networking, just 
as a defense-in-depth measure.

> UCR doesn't isolate uts namespace w/ host networking
> 
>
> Key: MESOS-7605
> URL: https://issues.apache.org/jira/browse/MESOS-7605
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: James DeFelice
>  Labels: mesosphere
>
> Docker's {{run}} command supports a {{--hostname}} parameter which impacts 
> container isolation, even in {{host}} network mode: (via 
> https://docs.docker.com/engine/reference/run/)
> {quote}
> Even in host network mode a container has its own UTS namespace by default. 
> As such --hostname is allowed in host network mode and will only change the 
> hostname inside the container. Similar to --hostname, the --add-host, --dns, 
> --dns-search, and --dns-option options can be used in host network mode.
> {quote}
> I see no evidence that UCR offers a similar isolation capability.
> Related: the {{ContainerInfo}} protobuf has a {{hostname}} field which was 
> initially added to support the Docker containerizer's use of the 
> {{--hostname}} Docker {{run}} flag.



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

[jira] [Created] (MESOS-7782) Add fetcher cache size metrics.

2017-07-11 Thread James Peach (JIRA) 
James Peach created MESOS-7782:
--

 Summary: Add fetcher cache size metrics.
 Key: MESOS-7782
 URL: https://issues.apache.org/jira/browse/MESOS-7782
 Project: Mesos
  Issue Type: Improvement
  Components: agent, statistics
Reporter: James Peach
Assignee: James Peach


Add agent metrics to publish the size and used space of the fetcher cache.



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

[jira] [Assigned] (MESOS-3528) Add more explanation comments to VsBuildCommand.bat

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-3528:
---

Assignee: Andrew Schwartzmeyer  (was: haosdent)

> Add more explanation comments to VsBuildCommand.bat
> ---
>
> Key: MESOS-3528
> URL: https://issues.apache.org/jira/browse/MESOS-3528
> Project: Mesos
>  Issue Type: Task
>Reporter: haosdent
>Assignee: Andrew Schwartzmeyer
>
> Now VsBuildCommand.bat need more comments to explain what we do in it.



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

[jira] [Commented] (MESOS-7770) Persistent volume might not be mounted if there is a sandbox volume whose source is the same as the target of the persistent volume.

2017-07-11 Thread Jie Yu (JIRA) 

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

Jie Yu commented on MESOS-7770:
---

commit c3632f67df4435f4dc3d9cb2d4d50db63aa8bcf8
Author: Gilbert Song 
Date:   Tue Jul 11 14:14:31 2017 -0700

Added unit tests for persistent volume and host volume conflict issue.

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

commit 2106fc7a2fd5f54e4a6454ba3cf7de023f732561
Author: Gilbert Song 
Date:   Tue Jul 11 14:14:28 2017 -0700

Fixed persistent volume and host volume conflict issue.

This is the fix for MESOS-7770. Basically, if a persistent volume
and a host volume are both specified and the source path of the
host volume is the same as the container path of the persistent
volume, then the persistent volume will be skipped and is not
mounted correctly. We should precisely check the mount table
to determine whether the persistent volume is mounted or not.
If not mounted, make sure we do mount the persistent volume.

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

> Persistent volume might not be mounted if there is a sandbox volume whose 
> source is the same as the target of the persistent volume.
> 
>
> Key: MESOS-7770
> URL: https://issues.apache.org/jira/browse/MESOS-7770
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Affects Versions: 1.1.2, 1.2.1, 1.3.0
>Reporter: Jie Yu
>Assignee: Gilbert Song
>Priority: Critical
>  Labels: mesosphere, persistent-volumes
>
> This issue is only for Mesos Containerizer.
> If the source of a sandbox volume is a relative path, we'll create the 
> directory in the sandbox in Isolator::prepare method:
> https://github.com/apache/mesos/blob/1.3.x/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp#L480-L485
> And then, we'll try to mount persistent volumes. However, because of this 
> TODO in the code:
> https://github.com/apache/mesos/blob/1.3.x/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp#L726-L739
> We'll skip mounting the persistent volume. That will cause a silent failure.
> This is important because the workaround we suggest folks to solve MESOS-4016 
> is to use an additional sandbox volume.



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

[jira] [Updated] (MESOS-7781) Windows API GetVersionExW was declared deprecated

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer updated MESOS-7781:

Priority: Minor  (was: Major)

> Windows API GetVersionExW was declared deprecated
> -
>
> Key: MESOS-7781
> URL: https://issues.apache.org/jira/browse/MESOS-7781
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
> Environment: Windows
>Reporter: Andrew Schwartzmeyer
>Priority: Minor
>  Labels: windows
>
> The following warning:
> {noformat}
> stout/windows/os.hpp(56): warning C4996: 'GetVersionExW': was declared 
> deprecated
> {noformat}
> appears when compiling Mesos, because the API was deprecated. According to 
> [MSDN | 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx]
>  we're supposed to move to the "Version Helper" functions.



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

[jira] [Comment Edited] (MESOS-6838) Reconsider the semantics of `subprocess` on Windows

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer edited comment on MESOS-6838 at 7/11/17 9:30 PM:
--

To start with: if this continue stays unchanged, we need to add an assert that 
the sent `path` is equivalent to the sent `argv[0]` as the latter is what gets 
used as the former (possibly unbeknownst to the developer).


was (Author: andschwa):
To start with: if the continue stays unchanged, we need to add an assert that 
the sent `path` is equivalent to the sent `argv[0]` as the latter is what gets 
used as the former (possibly unbeknownst to the developer).

> Reconsider the semantics of `subprocess` on Windows
> ---
>
> Key: MESOS-6838
> URL: https://issues.apache.org/jira/browse/MESOS-6838
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Reporter: Alex Clemmer
>Assignee: Andrew Schwartzmeyer
>  Labels: microsoft
>
> Right now, throughout the codebase, we are passing Windows shell commands 
> into `subprocess`'s `argv` parameter, and ignoreing the `path` parameter. For 
> example, we might do something like:
> {code}
> subprocess("", "cmd /c mesos-containerizer.exe", ...)
> {code}
> The `cmd /c` here is required. This obviously does not have high cohesion 
> with the Unix usage of this, so we should consider ways to clean this up.



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

[jira] [Commented] (MESOS-6735) `os::realpath` semantics differ between Windows and POSIX

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-6735:
-

Commit dd87bd416 updated the Windows implementation to use {{GetFullPathName}} 
instead of {{_fullpath}}, which also has this problem:

{quote}This function does not verify that the resulting path and file name are 
valid, or that they see an existing file on the associated volume.
{quote}

> `os::realpath` semantics differ between Windows and POSIX
> -
>
> Key: MESOS-6735
> URL: https://issues.apache.org/jira/browse/MESOS-6735
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: John Kordich
>  Labels: stout
>
> `os::realpath` on Unix should error out if the path does not exist. On 
> Windows, the implementation is backed by `_fullpath`, which does not error 
> out if the path does not exist. In general, we'd like the semantics to be as 
> similar as possible across the two.



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

[jira] [Comment Edited] (MESOS-6959) Separate the mesos-containerizer binary into a static binary, which only depends on stout

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer edited comment on MESOS-6959 at 7/11/17 9:27 PM:
--

-We can pretty easily replace this with 
[GetProductInfo|https://msdn.microsoft.com/en-us/library/windows/desktop/ms724358(v=vs.85).aspx].-


was (Author: andschwa):
We can pretty easily replace this with 
[GetProductInfo|https://msdn.microsoft.com/en-us/library/windows/desktop/ms724358(v=vs.85).aspx].

> Separate the mesos-containerizer binary into a static binary, which only 
> depends on stout
> -
>
> Key: MESOS-6959
> URL: https://issues.apache.org/jira/browse/MESOS-6959
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Joseph Wu
>Assignee: Andrew Schwartzmeyer
>  Labels: cmake, mesosphere, microsoft
>
> The {{mesos-containerizer}} binary currently has [three 
> commands|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/main.cpp#L46-L48]:
> * 
> [MesosContainerizerLaunch|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/launch.cpp]
> * 
> [MesosContainerizerMount|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/mount.cpp]
> * 
> [NetworkCniIsolatorSetup|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L1776-L1997]
> These commands are all heavily dependent on stout, and have no need to be 
> linked to libprocess.  In fact, adding an erroneous call to 
> {{process::initialize}} (either explicitly, or by accidentally using a 
> libprocess method) will break {{mesos-containerizer}} can cause several Mesos 
> containerizer tests to fail.  (The tasks fail to launch, saying {{Failed to 
> synchronize with agent (it's probably exited)}}).
> Because this binary only depends on stout, we can separate it from the other 
> source files and make this a static binary.



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

[jira] [Assigned] (MESOS-6942) CMake build with `-DENABLE_LIBEVENT=ON` requires system-installed `openssl`.

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-6942:
---

Assignee: Andrew Schwartzmeyer

> CMake build with `-DENABLE_LIBEVENT=ON` requires system-installed `openssl`.
> 
>
> Key: MESOS-6942
> URL: https://issues.apache.org/jira/browse/MESOS-6942
> Project: Mesos
>  Issue Type: Bug
>  Components: cmake
>Reporter: Michael Park
>Assignee: Andrew Schwartzmeyer
>  Labels: microsoft
>
> Trying to build with CMake with {{-DENABLE_LIBEVENT=ON}} on Ubuntu without 
> {{openssl}} installed produces the following error message. On OS X, it 
> doesn't know to use the brew installed {{openssl}}.
> {code}
> -- Performing Test EVENT__HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY
> -- Performing Test EVENT__HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY - Failed
> CMake Error at 
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 
> (message):
>   Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
>   system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
>   OPENSSL_INCLUDE_DIR)
> Call Stack (most recent call first):
>   /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake-3.5/Modules/FindOpenSSL.cmake:370 
> (find_package_handle_standard_args)
>   CMakeLists.txt:591 (find_package)
> -- Configuring incomplete, errors occurred!
> See also 
> "/BUILD/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta-build/CMakeFiles/CMakeOutput.log".
> See also 
> "/BUILD/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta-build/CMakeFiles/CMakeError.log".
> -- Cache values
> // Choose the type of build, options are: None(CMAKE_CXX_FLAGS or 
> CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
> CMAKE_BUILD_TYPE:STRING=
> // Limited configurations
> CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release
> // Install path prefix, prepended onto install directories.
> CMAKE_INSTALL_PREFIX:PATH=/usr/local
> // Define if libevent should be built with shared libraries instead of 
> archives
> EVENT__BUILD_SHARED_LIBRARIES:BOOL=OFF
> // Enable running gcov to get a test coverage report (only works with 
> GCC/CLang). Make sure to enable -DCMAKE_BUILD_TYPE=Debug as well.
> EVENT__COVERAGE:BOOL=OFF
> // Defines if libevent should build without the benchmark exectuables
> EVENT__DISABLE_BENCHMARK:BOOL=OFF
> // Define if libevent should build without support for a debug mode
> EVENT__DISABLE_DEBUG_MODE:BOOL=OFF
> // Disable verbose warnings with GCC
> EVENT__DISABLE_GCC_WARNINGS:BOOL=OFF
> // Define if libevent should not allow replacing the mm functions
> EVENT__DISABLE_MM_REPLACEMENT:BOOL=OFF
> // Define if libevent should build without support for OpenSSL encrpytion
> EVENT__DISABLE_OPENSSL:BOOL=OFF
> // Disable the regress tests
> EVENT__DISABLE_REGRESS:BOOL=OFF
> // Disable sample files
> EVENT__DISABLE_SAMPLES:BOOL=OFF
> // If tests should be compiled or not
> EVENT__DISABLE_TESTS:BOOL=OFF
> // Define if libevent should not be compiled with thread support
> EVENT__DISABLE_THREAD_SUPPORT:BOOL=OFF
> // Enable gcc function sections
> EVENT__ENABLE_GCC_FUNCTION_SECTIONS:BOOL=OFF
> // Enable compiler security checks
> EVENT__ENABLE_GCC_HARDENING:BOOL=OFF
> // Make all GCC warnings into errors
> EVENT__ENABLE_GCC_WARNINGS:BOOL=OFF
> // Enables verbose debugging
> EVENT__ENABLE_VERBOSE_DEBUG:BOOL=OFF
> // When crosscompiling forces running a test program that verifies that 
> Kqueue works with pipes. Note that this requires you to manually run the test 
> program on the the cross compilation target to verify that it works. See 
> cmake documentation for try_run for more details
> EVENT__FORCE_KQUEUE_CHECK:BOOL=OFF
> // Path to a file.
> OPENSSL_INCLUDE_DIR:PATH=OPENSSL_INCLUDE_DIR-NOTFOUND
> 3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/build.make:111: recipe for target 
> '3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta-stamp/libevent-2.1.5-beta-configure'
>  failed
> make[3]: *** 
> [3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta-stamp/libevent-2.1.5-beta-configure]
>  Error 1
> make[3]: Leaving directory '/BUILD'
> CMakeFiles/Makefile2:534: recipe for target 
> '3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/all' failed
> make[2]: Leaving directory '/BUILD'
> make[2]: *** [3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/all] Error 2
> CMakeFiles/Makefile2:546: recipe for target 
> '3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/rule' failed
> make[1]: *** [3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/rule] Error 2
> make[1]: Leaving directory '/BUILD'
> Makefile:234: recipe for target 
> '3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/rule' failed
> make: *** [3rdparty/CMakeFiles/libevent-2.1.5-beta.dir/rule] Error

[jira] [Commented] (MESOS-6959) Separate the mesos-containerizer binary into a static binary, which only depends on stout

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-6959:
-

We can pretty easily replace this with 
[GetProductInfo|https://msdn.microsoft.com/en-us/library/windows/desktop/ms724358(v=vs.85).aspx].

> Separate the mesos-containerizer binary into a static binary, which only 
> depends on stout
> -
>
> Key: MESOS-6959
> URL: https://issues.apache.org/jira/browse/MESOS-6959
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Joseph Wu
>Assignee: Andrew Schwartzmeyer
>  Labels: cmake, mesosphere, microsoft
>
> The {{mesos-containerizer}} binary currently has [three 
> commands|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/main.cpp#L46-L48]:
> * 
> [MesosContainerizerLaunch|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/launch.cpp]
> * 
> [MesosContainerizerMount|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/mount.cpp]
> * 
> [NetworkCniIsolatorSetup|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L1776-L1997]
> These commands are all heavily dependent on stout, and have no need to be 
> linked to libprocess.  In fact, adding an erroneous call to 
> {{process::initialize}} (either explicitly, or by accidentally using a 
> libprocess method) will break {{mesos-containerizer}} can cause several Mesos 
> containerizer tests to fail.  (The tasks fail to launch, saying {{Failed to 
> synchronize with agent (it's probably exited)}}).
> Because this binary only depends on stout, we can separate it from the other 
> source files and make this a static binary.



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

[jira] [Created] (MESOS-7781) Windows API GetVersionExW was declared deprecated

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 
Andrew Schwartzmeyer created MESOS-7781:
---

 Summary: Windows API GetVersionExW was declared deprecated
 Key: MESOS-7781
 URL: https://issues.apache.org/jira/browse/MESOS-7781
 Project: Mesos
  Issue Type: Bug
  Components: stout
 Environment: Windows
Reporter: Andrew Schwartzmeyer


The following warning:

{noformat}
stout/windows/os.hpp(56): warning C4996: 'GetVersionExW': was declared 
deprecated
{noformat}

appears when compiling Mesos, because the API was deprecated. According to 
[MSDN | 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx]
 we're supposed to move to the "Version Helper" functions.



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

[jira] [Commented] (MESOS-6959) Separate the mesos-containerizer binary into a static binary, which only depends on stout

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-6959:
-

I can likely do this as part of my CMake refactor. I'm sorting out the 
dependencies anyway.

> Separate the mesos-containerizer binary into a static binary, which only 
> depends on stout
> -
>
> Key: MESOS-6959
> URL: https://issues.apache.org/jira/browse/MESOS-6959
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Joseph Wu
>Assignee: Andrew Schwartzmeyer
>  Labels: cmake, mesosphere, microsoft
>
> The {{mesos-containerizer}} binary currently has [three 
> commands|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/main.cpp#L46-L48]:
> * 
> [MesosContainerizerLaunch|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/launch.cpp]
> * 
> [MesosContainerizerMount|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/mount.cpp]
> * 
> [NetworkCniIsolatorSetup|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L1776-L1997]
> These commands are all heavily dependent on stout, and have no need to be 
> linked to libprocess.  In fact, adding an erroneous call to 
> {{process::initialize}} (either explicitly, or by accidentally using a 
> libprocess method) will break {{mesos-containerizer}} can cause several Mesos 
> containerizer tests to fail.  (The tasks fail to launch, saying {{Failed to 
> synchronize with agent (it's probably exited)}}).
> Because this binary only depends on stout, we can separate it from the other 
> source files and make this a static binary.



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

[jira] [Assigned] (MESOS-6959) Separate the mesos-containerizer binary into a static binary, which only depends on stout

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-6959:
---

Assignee: Andrew Schwartzmeyer

> Separate the mesos-containerizer binary into a static binary, which only 
> depends on stout
> -
>
> Key: MESOS-6959
> URL: https://issues.apache.org/jira/browse/MESOS-6959
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Joseph Wu
>Assignee: Andrew Schwartzmeyer
>  Labels: cmake, mesosphere, microsoft
>
> The {{mesos-containerizer}} binary currently has [three 
> commands|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/main.cpp#L46-L48]:
> * 
> [MesosContainerizerLaunch|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/launch.cpp]
> * 
> [MesosContainerizerMount|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/mount.cpp]
> * 
> [NetworkCniIsolatorSetup|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L1776-L1997]
> These commands are all heavily dependent on stout, and have no need to be 
> linked to libprocess.  In fact, adding an erroneous call to 
> {{process::initialize}} (either explicitly, or by accidentally using a 
> libprocess method) will break {{mesos-containerizer}} can cause several Mesos 
> containerizer tests to fail.  (The tasks fail to launch, saying {{Failed to 
> synchronize with agent (it's probably exited)}}).
> Because this binary only depends on stout, we can separate it from the other 
> source files and make this a static binary.



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

[jira] [Commented] (MESOS-7173) CMake does not define `GIT_SHA` etc. in build.cpp

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-7173:
-

This is ready for review: https://reviews.apache.org/r/60482/

> CMake does not define `GIT_SHA` etc. in build.cpp
> -
>
> Key: MESOS-7173
> URL: https://issues.apache.org/jira/browse/MESOS-7173
> Project: Mesos
>  Issue Type: Bug
> Environment: CMake
>Reporter: Andrew Schwartzmeyer
>Assignee: Andrew Schwartzmeyer
>Priority: Minor
>  Labels: cmake, microsoft, windows
>
> `build.cpp` expects `BUILD_GIT_{SHA,BRANCH,TAG}` to be defined by the build 
> system (CMake) but they are not currently.



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

[jira] [Commented] (MESOS-7370) Fix create symlink code to use flag which enables non-admins to make symlinks

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-7370:
-

While this is doable, the big question is whether or not that flag will cause 
an `INVALID_PARAMETER` error when the code is run on older builds of Windows 
which did not have the flag.

> Fix create symlink code to use flag which enables non-admins to make symlinks
> -
>
> Key: MESOS-7370
> URL: https://issues.apache.org/jira/browse/MESOS-7370
> Project: Mesos
>  Issue Type: Improvement
>  Components: stout
> Environment: Windows 10
>Reporter: Andrew Schwartzmeyer
>Assignee: Li Li
>  Labels: windows
>
> Specifically {{SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE}}.
> bq. Specify this flag to allow creation of symbolic links when the process is 
> not elevated



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

[jira] [Commented] (MESOS-7605) UCR doesn't isolate uts namespace w/ host networking

2017-07-11 Thread Gilbert Song (JIRA) 

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

Gilbert Song commented on MESOS-7605:
-

/cc [~jpe...@apache.org], could you take a look? ^^

> UCR doesn't isolate uts namespace w/ host networking
> 
>
> Key: MESOS-7605
> URL: https://issues.apache.org/jira/browse/MESOS-7605
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: James DeFelice
>  Labels: mesosphere
>
> Docker's {{run}} command supports a {{--hostname}} parameter which impacts 
> container isolation, even in {{host}} network mode: (via 
> https://docs.docker.com/engine/reference/run/)
> {quote}
> Even in host network mode a container has its own UTS namespace by default. 
> As such --hostname is allowed in host network mode and will only change the 
> hostname inside the container. Similar to --hostname, the --add-host, --dns, 
> --dns-search, and --dns-option options can be used in host network mode.
> {quote}
> I see no evidence that UCR offers a similar isolation capability.
> Related: the {{ContainerInfo}} protobuf has a {{hostname}} field which was 
> initially added to support the Docker containerizer's use of the 
> {{--hostname}} Docker {{run}} flag.



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

[jira] [Commented] (MESOS-7605) UCR doesn't isolate uts namespace w/ host networking

2017-07-11 Thread James DeFelice (JIRA) 

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

James DeFelice commented on MESOS-7605:
---

Re-opening this ticket for further discussion.

If there are no container networks, there is no UTS namespace isolation, as per:

https://github.com/apache/mesos/blob/9b69c09310cdb6d7cfca1284f60c3f1b422c77cc/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L655

without such isolation, calls to `sethostname` from a container will impact the 
host netns, as per:

https://linux.die.net/man/2/sethostname

and

https://linux.die.net/man/1/unshare

{quote}
UTS namespace

setting hostname, domainname will not affect rest of the system (CLONE_NEWUTS 
flag),
{quote}

This is distinctly different from the Docker experience. It also implies that 
it's impossible to give a container permission to **bind** to a host network 
port without also giving it permission to **change the host's network name**. 
This feels like a security hole to me.

> UCR doesn't isolate uts namespace w/ host networking
> 
>
> Key: MESOS-7605
> URL: https://issues.apache.org/jira/browse/MESOS-7605
> Project: Mesos
>  Issue Type: Improvement
>  Components: containerization
>Reporter: James DeFelice
>  Labels: mesosphere
>
> Docker's {{run}} command supports a {{--hostname}} parameter which impacts 
> container isolation, even in {{host}} network mode: (via 
> https://docs.docker.com/engine/reference/run/)
> {quote}
> Even in host network mode a container has its own UTS namespace by default. 
> As such --hostname is allowed in host network mode and will only change the 
> hostname inside the container. Similar to --hostname, the --add-host, --dns, 
> --dns-search, and --dns-option options can be used in host network mode.
> {quote}
> I see no evidence that UCR offers a similar isolation capability.
> Related: the {{ContainerInfo}} protobuf has a {{hostname}} field which was 
> initially added to support the Docker containerizer's use of the 
> {{--hostname}} Docker {{run}} flag.



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

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

2017-07-11 Thread Till Toenshoff (JIRA) 

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

Till Toenshoff edited comment on MESOS-7658 at 7/11/17 5:57 PM:


Turns out this is failing not only on Windows and macOS, but also on Linux.


was (Author: bbannier):
Turns out this is failing not only on Windows and macOS, but also one Linux.

> 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
>Assignee: Andrew Schwartzmeyer
>
> 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
(v6.4.14#64029)

[jira] [Updated] (MESOS-7171) Mesos Containerizer Change Size of SHM

2017-07-11 Thread James DeFelice (JIRA) 

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

James DeFelice updated MESOS-7171:
--
Labels: mesosphere  (was: )

> Mesos Containerizer Change Size of SHM
> --
>
> Key: MESOS-7171
> URL: https://issues.apache.org/jira/browse/MESOS-7171
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Miguel Bernadin
>Assignee: Joseph Wu
>Priority: Minor
>  Labels: mesosphere
>
> like the ability to adjust the size of the shared memory device just like 
> this can be performed on docker.
> For example: To be able to change this on docker you can specify how much 
> space you would like to allocate as a parameter in the app definition in 
> marathon.
> {code}
>   "parameters": [
> {
>   "key": "shm-size",
>   "value": "256mb"
> }
> {code}
> As you can see below, here is an example of a container running and how much 
> space is available on disk reflecting this change.
> Modified Parameter Container:
> {code}
> {
>   "id": "/ubuntu-withshm",
>   "cmd": "sleep 1000\n",
>   "cpus": 1,
>   "mem": 128,
>   "disk": 0,
>   "instances": 1,
>   "container": {
> "type": "DOCKER",
> "volumes": [],
> "docker": {
>   "image": "ubuntu",
>   "network": "HOST",
>   "privileged": false,
>   "parameters": [
> {
>   "key": "shm-size",
>   "value": "256mb"
> }
>   ],
>   "forcePullImage": false
> }
>   },
>   "portDefinitions": [
> {
>   "port": 10005,
>   "protocol": "tcp",
>   "labels": {}
> }
>   ]
> }
> {code}
> Modified Parameter Container:
> {code}
> core@ip-10-0-0-19 ~ $ docker exec -it a818cf2277a5 bash
> root@ip-10-0-0-19:/# df -h
> Filesystem  Size  Used Avail Use% Mounted on
> overlay  37G  2.0G   33G   6% /
> tmpfs   7.4G 0  7.4G   0% /dev
> tmpfs   7.4G 0  7.4G   0% /sys/fs/cgroup
> /dev/xvdb37G  2.0G   33G   6% /etc/hostname
> shm 256M 0  256M   0% /dev/shm
> {code}
> Standard Container:
> {code}
> {
>   "id": "/ubuntu-withoutshm",
>   "cmd": "sleep 1",
>   "cpus": 1,
>   "mem": 128,
>   "disk": 0,
>   "instances": 1,
>   "container": {
> "type": "DOCKER",
> "volumes": [],
> "docker": {
>   "image": "ubuntu",
>   "network": "HOST",
>   "privileged": false,
>   "parameters": [],
>   "forcePullImage": false
> }
>   },
>   "portDefinitions": [
> {
>   "port": 10006,
>   "protocol": "tcp",
>   "labels": {}
> }
>   ]
> }
> {code}
> Standard Container:
> {code}
> root@ip-10-0-0-19:/# exit
> exit
> core@ip-10-0-0-19 ~ $ docker exec -it c85433062e78 bash
> root@ip-10-0-0-19:/# df -h
> Filesystem  Size  Used Avail Use% Mounted on
> overlay  37G  2.0G   33G   6% /
> tmpfs   7.4G 0  7.4G   0% /dev
> tmpfs   7.4G 0  7.4G   0% /sys/fs/cgroup
> /dev/xvdb37G  2.0G   33G   6% /etc/hostname
> shm  64M 0   64M   0% /dev/shm
> {code}
> How can this be done on mesos containerizer?



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

[jira] [Assigned] (MESOS-5417) define WSTRINGIFY behaviour on Windows

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer reassigned MESOS-5417:
---

Assignee: Andrew Schwartzmeyer  (was: Li Li)

> define WSTRINGIFY behaviour on Windows
> --
>
> Key: MESOS-5417
> URL: https://issues.apache.org/jira/browse/MESOS-5417
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Daniel Pravat
>Assignee: Andrew Schwartzmeyer
>Priority: Minor
>  Labels: windows
> Fix For: 1.4.0
>
>
> Identify the proper behaviour of WSTRINGIFY to improve the logging.  



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

[jira] [Updated] (MESOS-7752) Command executor still active after terminal task state update.

2017-07-11 Thread James DeFelice (JIRA) 

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

James DeFelice updated MESOS-7752:
--
Labels: mesosphere  (was: )

> Command executor still active after terminal task state update.
> ---
>
> Key: MESOS-7752
> URL: https://issues.apache.org/jira/browse/MESOS-7752
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: A. Dukhovniy
>  Labels: mesosphere
>
> Here is a rather simple scenario to reproduce this error:
> * Frameworks starts a task with taskId = _task1_
> * Framework kills _task1_ *successfully* and *acknowledges* TASK_KILLED
> * Framework starts another task with the same _task1_  but receives 
> "_TASK_FAILED (Attempted to run multiple tasks using a "command" executor)_"
> *Note*: this test is racy so this scenario fails occasionally.
> *Here is a full log* from that show a life-cycle of a task id 
> _app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c_:
> {code:java}
> # Starting...
> WARN [10:51:14 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:14.476085 14666 master.cpp:3352] Authorizing framework principal 
> 'principal' to launch task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
> WARN [10:51:14 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:14.510136 14666 master.cpp:4426] Launching task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be- (marathon) at 
> scheduler-6dbbac16-7355-4a33-aee6-b9697c83e51c@127.0.1.1:61567 with 
> resources...
> WARN [10:51:14 ResidentTaskIntegrationTest-MesosAgent-32788] I0703 
> 10:51:14.513908 14697 slave.cpp:2118] Queued task 
> 'app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c'
>  for executor 
> 'app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c'
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be-
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:15.011696 14671 master.cpp:6222] Forwarding status update TASK_RUNNING 
> (UUID: ed2d0475-9d83-4e09-9f54-5b4d323e4558) for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be-
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:15.036391 14671 master.cpp:5092] Processing ACKNOWLEDGE call 
> ed2d0475-9d83-4e09-9f54-5b4d323e4558 for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be- (marathon) at 
> scheduler-6dbbac16-7355-4a33-aee6-b9697c83e51c@127.0.1.1:61567 on agent 
> 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be-S0
> {code}
> {code:java}
> # Killing...
> DEBUG[10:51:15 ResidentTaskIntegrationTest-LocalMarathon-32800] WARN 
> [10:51:15 KillAction$] Killing known task 
> [app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c]
>  of instance instance 
> [app-restart-resident-app-with-five-instances.marathon-8882bd16-5fdd-11e7-a00e-0242aceef95c]
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosAgent-32788] I0703 
> 10:51:15.196702 14697 slave.cpp:3816] Handling status update TASK_KILLED 
> (UUID: f7e9d0bc-726c-43aa-9ddc-3b082a68642e) for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be- from 
> executor(1)@172.16.10.121:35184
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosAgent-32788] I0703 
> 10:51:15.197676 14697 slave.cpp:4166] Sending acknowledgement for status 
> update TASK_KILLED (UUID: f7e9d0bc-726c-43aa-9ddc-3b082a68642e) for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be- to 
> executor(1)@172.16.10.121:35184
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:15.198299 14671 master.cpp:6154] Status update TASK_KILLED (UUID: 
> f7e9d0bc-726c-43aa-9ddc-3b082a68642e) for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c
>  of framework 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be- from agent 
> 76d8f3e7-8f3a-4764-bb7d-2bcf8e85e2be-S0 at slave(1)@172.16.10.121:32788 
> (172.16.10.121)
> DEBUG[10:51:15 ResidentTaskIntegrationTest-LocalMarathon-32800] INFO 
> [10:51:15 MarathonScheduler] Received status update for task 
> app-restart-resident-app-with-five-instances.8882bd16-5fdd-11e7-a00e-0242aceef95c:
>  TASK_KILLED (Command terminated with signal Terminated)
> WARN [10:51:15 ResidentTaskIntegrationTest-MesosMaster-32782] I0703 
> 10:51:15.216081 14671

[jira] [Created] (MESOS-7780) Add `SUBSCRIBE` call handling to the resource provider manager

2017-07-11 Thread Jan Schlicht (JIRA) 
Jan Schlicht created MESOS-7780:
---

 Summary: Add `SUBSCRIBE` call handling to the resource provider 
manager
 Key: MESOS-7780
 URL: https://issues.apache.org/jira/browse/MESOS-7780
 Project: Mesos
  Issue Type: Task
Reporter: Jan Schlicht
Assignee: Jan Schlicht


Resource providers will use the HTTP API to subscribe to the 
{{ResourceProviderManager}}. Handling these calls needs to be implemented. On 
subscription, a unique resource provider ID will be assigned to the resource 
provider and a {{SUBSCRIBED}} event will be sent.



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

[jira] [Commented] (MESOS-7634) OsTest.ChownNoAccess fails on s390x machines

2017-07-11 Thread vandita (JIRA) 

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

vandita commented on MESOS-7634:


Hi Vinod,

I could resolve the test case failure by running the docker script as a root 
user. In  file "support/docker-build.sh" modified line 190 to docker run --user 
root $TAG. Root user was there on the system with root access.The test case 
passed with that.



> OsTest.ChownNoAccess fails on s390x machines
> 
>
> Key: MESOS-7634
> URL: https://issues.apache.org/jira/browse/MESOS-7634
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Nayana Thorat
>
> Running a custom branch of Mesos (with some fixes in docker build scripts for 
> s390x) on s390x based CI machines throws the following error when running 
> stout tests.
> {code}
> [ RUN  ] OsTest.ChownNoAccess
> ../../../../3rdparty/stout/tests/os_tests.cpp:839: Failure
> Value of: os::chown(uid.get(), gid.get(), "one", true).isError()
>   Actual: false
> Expected: true
> ../../../../3rdparty/stout/tests/os_tests.cpp:840: Failure
> Value of: os::chown(uid.get(), gid.get(), "one/two", true).isError()
>   Actual: false
> {code}
> One can repro this by building Mesos from my custom branch here: 
> https://github.com/vinodkone/mesos/tree/vinod/s390x



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

[jira] [Created] (MESOS-7779) Consider showing aggregated anonymous data on filtered results.

2017-07-11 Thread Alexander Rojas (JIRA) 
Alexander Rojas created MESOS-7779:
--

 Summary: Consider showing aggregated anonymous data on filtered 
results.
 Key: MESOS-7779
 URL: https://issues.apache.org/jira/browse/MESOS-7779
 Project: Mesos
  Issue Type: Bug
Reporter: Alexander Rojas
Priority: Minor


Some of the endpoints/json results filter data like resources, however this 
leads to Data not adding up, for example an entry would show the total 
resources of an agent, another would show the free resources and another the 
used ones, however, used resources are filtered based in the role creating a 
situation in which adding the free resources + used resources ≠ total resources.

Perhaps an anonymous aggregated field used to show filtered data so that the 
results add up could do the trick.



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

[jira] [Updated] (MESOS-7775) Eliminate extra process abort in a subprocess watchdog

2017-07-11 Thread Alexander Rukletsov (JIRA) 

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

Alexander Rukletsov updated MESOS-7775:
---
Story Points: 3  (was: 2)

> Eliminate extra process abort in a subprocess watchdog
> --
>
> Key: MESOS-7775
> URL: https://issues.apache.org/jira/browse/MESOS-7775
> Project: Mesos
>  Issue Type: Bug
>Reporter: Andrei Budnik
>Assignee: Andrei Budnik
>
> `abort()` is called in `SUPERVISOR` hook when child process exits with an 
> error code, or `waitpid()` fails, or parent process exits. All these cases 
> shouldn't lead to abnormal program termination with coredumps.



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

[jira] [Comment Edited] (MESOS-7160) Parsing of perf version segfaults

2017-07-11 Thread Alexander Rukletsov (JIRA) 

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

Alexander Rukletsov edited comment on MESOS-7160 at 7/11/17 8:33 AM:
-

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


was (Author: abudnik):
https://reviews.apache.org/r/60397/
https://reviews.apache.org/r/60598/

> Parsing of perf version segfaults
> -
>
> Key: MESOS-7160
> URL: https://issues.apache.org/jira/browse/MESOS-7160
> Project: Mesos
>  Issue Type: Bug
>  Components: test
>Reporter: Benjamin Bannier
>Assignee: Andrei Budnik
>
> Parsing the perf version [fails with a segfault in ASF 
> CI|https://builds.apache.org/job/Mesos-Buildbot/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu:14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/3294/],
> {noformat}
> E0222 20:54:03.033464   805 perf.cpp:237] Failed to get perf version: Failed 
> to execute perf: terminated with signal Aborted (core dumped)
> {noformat}



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

[jira] [Commented] (MESOS-3394) Change glog download target for Windows when pull req is moved upstream

2017-07-11 Thread Andrew Schwartzmeyer (JIRA) 

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

Andrew Schwartzmeyer commented on MESOS-3394:
-

We should wait for the next release of Glog, which includes full Windows 
support (stack tracing, symbol resolution, and signal handling).

> Change glog download target for Windows when pull req is moved upstream
> ---
>
> Key: MESOS-3394
> URL: https://issues.apache.org/jira/browse/MESOS-3394
> Project: Mesos
>  Issue Type: Task
>  Components: cmake
>Reporter: Alex Clemmer
>Assignee: Andrew Schwartzmeyer
>  Labels: build, cmake, mesosphere
>
> To build on Windows, we have to build glog on Windows. But, glog doesn't 
> build on Windows, so we had to submit a patch to the project. So, to build on 
> Windows, we download the patched version directly from the pull request that 
> was sent to the glog repository on GitHub.
> When these patches move upstream, we need to change this to point at the 
> "real" glog release instead of the pull request.
> (For details see the `CMakeLists.txt` in `3rdparty/libprocess/3rdparty`.)



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