Review Request 55030: CMake: Added source groups for libprocess build.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55030/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Bugs: MESOS-3542
https://issues.apache.org/jira/browse/MESOS-3542


Repository: mesos


Description
---

Currently in IDEs such as XCode and Visual Studio, all mesos source
files are grouped into one huge folder, with no attempt made to reflect
the hierarchy of folders that exist on disk.

This commit groups libprocess files into relevant source groups so that
they appear in a sensible directory structure in these IDEs.

In addition to beginning to directly address MESOS-3542, this is also
(indirectly) the first step towards addressing the problem of breaking
libmesos up into smaller binaries (MESOS-3542).


Diffs
-

  3rdparty/libprocess/cmake/ProcessConfigure.cmake 
873f41d844faa0d442f77411e94314a89be5f046 
  3rdparty/libprocess/src/CMakeLists.txt 
60f0e76dfd237d9a12a366b413802d1a96892b55 
  3rdparty/libprocess/src/tests/CMakeLists.txt 
4b80c397381ca2c869cd6eb7507bb9df94ce3623 

Diff: https://reviews.apache.org/r/55030/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55029: CMake: Added source groups to Stout build.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55029/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Bugs: MESOS-3542
https://issues.apache.org/jira/browse/MESOS-3542


Repository: mesos


Description
---

Currently in IDEs such as XCode and Visual Studio, all mesos source
files are grouped into one huge folder, with no attempt made to reflect
the hierarchy of folders that exist on disk.

This commit groups Stout files into relevant source groups so that they
appear in a sensible directory structure in these IDEs.

In addition to beginning to directly address MESOS-3542, this is also
(indirectly) the first step towards addressing the problem of breaking
libmesos up into smaller binaries (MESOS-3542).


Diffs
-

  3rdparty/stout/cmake/StoutConfigure.cmake 
04e0f2f0d464d6740055eb1db2a8d41349879171 
  3rdparty/stout/tests/CMakeLists.txt a09693d4b9a70faf1e4e337ec71ead2f0bbab0a2 

Diff: https://reviews.apache.org/r/55029/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55028: Propagate `os::killtree` error correctly in `PosixLauncher::destroy`.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55028/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Currently if the POSIX launcher fails to kill a process group with
`os::killtree`, it will simply ignore the error. This currently causes
some executor tests to hang indefinitely on Windows, with no mention of
the true error, since `killtree` is not yet completely bug free
(MESOS-6839).

This commit will cause us to correctly propagate and report the error
when it is observed.


Diffs
-

  src/slave/containerizer/mesos/launcher.cpp 
a6a8c01cb39f35f8174fcb5af0ef18de2da5ee78 

Diff: https://reviews.apache.org/r/55028/diff/


Testing
---


Thanks,

Alex Clemmer

Re: Review Request 54873: Added asynchronous libcurl support to Mesos.

2016-12-24 Thread Jie Yu 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54873/
---

(Updated Dec. 24, 2016, 11:04 p.m.)


Review request for mesos, Benjamin Hindman, Benjamin Mahler, Gilbert Song, and 
Joris Van Remoortere.


Bugs: MESOS-4853 and MESOS-6129
https://issues.apache.org/jira/browse/MESOS-4853
https://issues.apache.org/jira/browse/MESOS-6129


Repository: mesos


Description
---

This patch integrates libcurl with Mesos's event runtime. It uses the
multi interface (https://curl.haxx.se/libcurl/c/libcurl-multi.html) to
avoid blocking operations.

This patch introduces some common basic interfaces which all the
protocols (e.g., http/ftp/etc.) share. In the future, the plan is to
introduce more protocol specific interfaces (e.g., curl::http).


Diffs
-

  src/CMakeLists.txt c8d4260c03d8cdee1951a50d293e9fdabcd2cf84 
  src/Makefile.am abcf7eed717ccd2396540011d7fb9fc7959c18f2 
  src/curl/common.hpp PRE-CREATION 
  src/curl/common.cpp PRE-CREATION 
  src/tests/curl_tests.cpp PRE-CREATION 

Diff: https://reviews.apache.org/r/54873/diff/


Testing (updated)
---

```
[==] Running 6 tests from 1 test case.  

   
[--] Global test environment set-up.
[--] 6 tests from CurlTest
[ RUN  ] CurlTest.InvalidUrl
* Could not resolve host: invalidurl; Name or service not known
* Closing connection 0
[   OK ] CurlTest.InvalidUrl (9 ms)
[ RUN  ] CurlTest.SimpleUrl
* About to connect() to 10.0.49.2 port 42347 (#1)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#1)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

< HTTP/1.1 200 OK
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #1 to host 10.0.49.2 left intact
[   OK ] CurlTest.SimpleUrl (4 ms)
[ RUN  ] CurlTest.MultipleSessions
* About to connect() to 10.0.49.2 port 42347 (#2)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#2)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Found bundle for host 10.0.49.2: 0x7f7f64017930
* About to connect() to 10.0.49.2 port 42347 (#3)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#3)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

< HTTP/1.1 200 OK
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #2 to host 10.0.49.2 left intact
< HTTP/1.1 202 Accepted
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #3 to host 10.0.49.2 left intact
[   OK ] CurlTest.MultipleSessions (4 ms)
[ RUN  ] CurlTest.INTERNET_HttpsUrl
* About to connect() to registry-1.docker.io port 443 (#4)
*   Trying 52.54.195.55...
* Connected to registry-1.docker.io (52.54.195.55) port 443 (#4)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=*.docker.io,OU=Domain Control Validated - 
RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT98568428
*   start date: Mar 19 17:34:32 2015 GMT
*   expire date: Apr 21 01:51:52 2018 GMT
*   common name: *.docker.io
*   issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET /v2/ HTTP/1.1
Host: registry-1.docker.io
Accept: */*

< HTTP/1.1 401 Unauthorized
< Content-Type: application/json; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer 
realm="https://auth.docker.io/token",service="registry.docker.io;
< Date: Sat, 24 Dec 2016 22:41:01 GMT
< Content-Length: 87
< Strict-Transport-Security: max-age=31536000
< 
{"errors":[{"code":"UNAUTHORIZED","message":"authentication 
required","detail":null}]}
* Connection #4 to host registry-1.docker.io left intact
[   OK ] CurlTest.INTERNET_HttpsUrl (456 ms)
[ RUN  ] CurlTest.Discard
* About to connect() to 10.0.49.2 port 42347 (#5)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#5)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Closing connection 5
[   OK ] CurlTest.Discard (5 ms)
[ RUN  ] CurlTest.Timeout
* About to connect() to 10.0.49.2 port 42347 (#6)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#6)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Operation timed out after 138 milliseconds with 0 out of -1 bytes received
* Closing connection 6
[   OK ] CurlTest.Timeout (101 ms)
[--] 6 tests from CurlTest (580 ms total)

[--] Global test environment tear-down
[==] 6 tests from 1 test case ran. (636 ms total)
[  PASSED  ] 6

Re: Review Request 54873: Added asynchronous libcurl support to Mesos.

2016-12-24 Thread Jie Yu 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54873/
---

(Updated Dec. 24, 2016, 11:02 p.m.)


Review request for mesos, Benjamin Hindman, Benjamin Mahler, Gilbert Song, and 
Joris Van Remoortere.


Changes
---

Ready for review.


Summary (updated)
-

Added asynchronous libcurl support to Mesos.


Bugs: MESOS-4853 and MESOS-6129
https://issues.apache.org/jira/browse/MESOS-4853
https://issues.apache.org/jira/browse/MESOS-6129


Repository: mesos


Description (updated)
---

This patch integrates libcurl with Mesos's event runtime. It uses the
multi interface (https://curl.haxx.se/libcurl/c/libcurl-multi.html) to
avoid blocking operations.

This patch introduces some common basic interfaces which all the
protocols (e.g., http/ftp/etc.) share. In the future, the plan is to
introduce more protocol specific interfaces (e.g., curl::http).


Diffs (updated)
-

  src/CMakeLists.txt c8d4260c03d8cdee1951a50d293e9fdabcd2cf84 
  src/Makefile.am abcf7eed717ccd2396540011d7fb9fc7959c18f2 
  src/curl/common.hpp PRE-CREATION 
  src/curl/common.cpp PRE-CREATION 
  src/tests/curl_tests.cpp PRE-CREATION 

Diff: https://reviews.apache.org/r/54873/diff/


Testing (updated)
---

[==] Running 6 tests from 1 test case.  


   [40/59709]
[--] Global test environment set-up.
[--] 6 tests from CurlTest
[ RUN  ] CurlTest.InvalidUrl
* Could not resolve host: invalidurl; Name or service not known
* Closing connection 0
[   OK ] CurlTest.InvalidUrl (9 ms)
[ RUN  ] CurlTest.SimpleUrl
* About to connect() to 10.0.49.2 port 42347 (#1)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#1)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

< HTTP/1.1 200 OK
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #1 to host 10.0.49.2 left intact
[   OK ] CurlTest.SimpleUrl (4 ms)
[ RUN  ] CurlTest.MultipleSessions
* About to connect() to 10.0.49.2 port 42347 (#2)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#2)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Found bundle for host 10.0.49.2: 0x7f7f64017930
* About to connect() to 10.0.49.2 port 42347 (#3)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#3)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

< HTTP/1.1 200 OK
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #2 to host 10.0.49.2 left intact
< HTTP/1.1 202 Accepted
< Date: Sat, 24 Dec 2016 22:41:00 GMT
< Content-Length: 0
< 
* Connection #3 to host 10.0.49.2 left intact
[   OK ] CurlTest.MultipleSessions (4 ms)
[ RUN  ] CurlTest.INTERNET_HttpsUrl
* About to connect() to registry-1.docker.io port 443 (#4)
*   Trying 52.54.195.55...
* Connected to registry-1.docker.io (52.54.195.55) port 443 (#4)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=*.docker.io,OU=Domain Control Validated - 
RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT98568428
*   start date: Mar 19 17:34:32 2015 GMT
*   expire date: Apr 21 01:51:52 2018 GMT
*   common name: *.docker.io
*   issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET /v2/ HTTP/1.1
Host: registry-1.docker.io
Accept: */*

< HTTP/1.1 401 Unauthorized
< Content-Type: application/json; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer 
realm="https://auth.docker.io/token",service="registry.docker.io;
< Date: Sat, 24 Dec 2016 22:41:01 GMT
< Content-Length: 87
< Strict-Transport-Security: max-age=31536000
< 
{"errors":[{"code":"UNAUTHORIZED","message":"authentication 
required","detail":null}]}
* Connection #4 to host registry-1.docker.io left intact
[   OK ] CurlTest.INTERNET_HttpsUrl (456 ms)
[ RUN  ] CurlTest.Discard
* About to connect() to 10.0.49.2 port 42347 (#5)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#5)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Closing connection 5
[   OK ] CurlTest.Discard (5 ms)
[ RUN  ] CurlTest.Timeout
* About to connect() to 10.0.49.2 port 42347 (#6)
*   Trying 10.0.49.2...
* Connected to 10.0.49.2 (10.0.49.2) port 42347 (#6)
> GET /TestHttpServer/test HTTP/1.1
Host: 10.0.49.2:42347
Accept: */*

* Operation timed out after 138 milliseconds with 0 out of -1 bytes received
* Closing connection 6
[   OK ] CurlTest.Timeout (101 ms)

Re: Review Request 55023: Windows: Fixed malformatted containerizer command in launcher.

2016-12-24 Thread Daniel Pravat 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55023/#review160115
---




src/slave/containerizer/mesos/containerizer.cpp (line 1611)


This code was working before. you should not change it to make the taest 
work and add overhead in production.


- Daniel Pravat


On Dec. 24, 2016, 10:02 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55023/
> ---
> 
> (Updated Dec. 24, 2016, 10:02 a.m.)
> 
> 
> Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
> and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently in `MesosContainerizerProcess::_launch`, we are passing a
> malformatted shell command to the launcher. This causes the
> containerizer process to crash immediately upon invocation in all
> executor tests.
> 
> This commit will fix this command.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/mesos/containerizer.cpp 
> d9d5619e45ae1199fc91878f17a33b5647f48305 
> 
> Diff: https://reviews.apache.org/r/55023/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Re: Review Request 54877: Windows: Stout: Removed dependency on Shell API.

2016-12-24 Thread Alex Clemmer 


> On Dec. 20, 2016, 12:29 a.m., Daniel Pravat wrote:
> > 3rdparty/stout/include/stout/windows/os.hpp, line 748
> > 
> >
> > I don't think the conversion to UTF-8 is appropiate here.
> 
> Andrew Schwartzmeyer wrote:
> What would you convert it to? It's currently in UTF-16, and Windows paths 
> are allowed to have (almost) any Unicode character.
> 
> Alex Clemmer wrote:
> I think he's saying that bad things will happen if you use strings that 
> have Unicode in them, so it's probably better to just error out.
> 
> Andrew Schwartzmeyer wrote:
> I'm not following... That is a case our codebase must deal with, NTFS 
> paths are stored in Unicode:
> 
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx
> 
> and on top of that, Windows file paths can:
> 
> > Use any character in the current code page for a name, including 
> Unicode characters and characters in the extended character set (128–255)
> 
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
> 
> So what I'm saying is that bad things _must not happen_ if we have paths 
> with non-ASCII characters in them; we need to handle that at any point we 
> deal with file paths on Windows.
> 
> I'm not saying this function is likely to return a path like `C:\ÂÑÐ¥`, 
> but that would be a valid file path, and so we must be treating all our paths 
> on Windows as Unicode.
> 
> If this is not the case, are purposefully constraining ourselves to 
> ASCII, and if so, why?
> 
> Alex Clemmer wrote:
> Sorry, I meant bad things will happen to Mesos if you give it strings 
> with unicode in them. Mesos itself does not deal with Unicode gracefully.
> 
> Andrew Schwartzmeyer wrote:
> Oooh. We should probably fix that.
> 
> Andrew Schwartzmeyer wrote:
> Alex, Daniel, do we have a resolution on this? I spoke with Alex and we 
> feel that we should be doing two main things: avoid exacberating the problem 
> in MESOS-6817 by being explicit in our use of `W` APIs, rather than relying 
> on the mercurial value of `TCHAR`; and not attempt to guard against paths 
> that Mesos does not handle, as it is a bug that Mesos does not handle paths 
> with valid extended characters (since both Linux and Windows may have these 
> paths), so failing here would be inappropriate as it hides the actual bug. 
> (Not to speak for you Alex, I think this summarizes our discussion yesterday.)

If I'm understanding our discussion correctly, failing here on unicode 
conversion would be preferable, since it makes a subtle bug more obvious. If 
that's nontrivial I think we can just ship it as is, since Mesos already has 
these problems.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54877/#review159672
---


On Dec. 19, 2016, 11:20 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54877/
> ---
> 
> (Updated Dec. 19, 2016, 11:20 p.m.)
> 
> 
> Review request for mesos, Daniel Pravat, Alex Clemmer, and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The API `SHGetKnownFolderPath` requires `Shell32.dll`,
> which is not available on Nano server.
> The equivalent API `GetAllUsersProfileDirectory`
> only requires `Userenv.dll`, which is available on Nano.
> 
> This API is also friendlier, as we own the allocation.
> 
> The Unicode version `GetAllUsersProfileDirectoryW` is
> explicitly used so that we are guaranteed a Unicode path,
> which we then convert from UTF-16 to UTF-8,
> instead of using the ASCII version which depends on a
> varying Windows code-page, and is not recommended.
> 
> A `vector` is used over a `wstring` to avoid dealing
> with the placement of the null-terminating character.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/windows.hpp 
> e641c46d033372e1b6c9f9c066b1ad4957d55088 
>   3rdparty/stout/include/stout/windows/os.hpp 
> 5cd92545a49648e39e8eb7cf131895e9cfc97902 
> 
> Diff: https://reviews.apache.org/r/54877/diff/
> 
> 
> Testing
> ---
> 
> cmake && msbuild, attach agent to master and check default `runtime_dir` 
> value.
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Review Request 55026: Windows: Shortened test directories on Windows to avoid path errors.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55026/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Currently some tests that use particularly long sandbox paths will due
to the notorious Windows path length limitations. Here, we change the
sandbox directory default on Windows agent tests to be something shorter
than the Unix equivalent in order to avoid these errors.


Diffs
-

  src/tests/environment.cpp a683d8c221635f81906abbead1e01d2469850d93 

Diff: https://reviews.apache.org/r/55026/diff/


Testing
---


Thanks,

Alex Clemmer

Re: Review Request 55025: Transitioned `BUILD_DIR` to use Unix-style paths on Windows.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55025/
---

(Updated Dec. 24, 2016, 11:09 a.m.)


Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Bugs: MESOS-6736
https://issues.apache.org/jira/browse/MESOS-6736


Repository: mesos


Description
---

Currently in the test harness, we pass the flags `-DSOURCE_DIR` and
`-DBUILD_DIR` to the compiler. These are used to do things like
determine where the containerizer is to launch it for tests.

On Windows, these paths should be Windows-style, with '\' characters
separating path components. Unfortunately, CMake does not escape these
slashes in path strings, so when we pass them as preprocessor flags,
a string like `C:\src` will look to the standard Windows API like a
string with an escaped '\s' character.

On the other hand, Windows APIs are happy to take Unix-style paths as
arguments. So, to unblock making the agent tests work, we simply use
Unix paths here.


Diffs
-

  src/tests/cmake/MesosTestsConfigure.cmake 
ca042bd3f7ebc339f1c342b1854a66e33ee9f20c 

Diff: https://reviews.apache.org/r/55025/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55025: Transitioned `BUILD_DIR` to use Unix-style paths on Windows.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55025/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Currently in the test harness, we pass the flags `-DSOURCE_DIR` and
`-DBUILD_DIR` to the compiler. These are used to do things like
determine where the containerizer is to launch it for tests.

On Windows, these paths should be Windows-style, with '\' characters
separating path components. Unfortunately, CMake does not escape these
slashes in path strings, so when we pass them as preprocessor flags,
a string like `C:\src` will look to the standard Windows API like a
string with an escaped '\s' character.

On the other hand, Windows APIs are happy to take Unix-style paths as
arguments. So, to unblock making the agent tests work, we simply use
Unix paths here.


Diffs
-

  src/tests/cmake/MesosTestsConfigure.cmake 
ca042bd3f7ebc339f1c342b1854a66e33ee9f20c 

Diff: https://reviews.apache.org/r/55025/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55024: Windows: Start the socket stack in `process::initialize`.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55024/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Currently libprocess will attempt to use sockets without initializing
the socket stack on Windows. This commit will resolving this problem by
causing `process::initialize` to initialize the socket stack.


Diffs
-

  3rdparty/libprocess/src/process.cpp 889a03444eaee7b5ad2be65bb414c30062d4a4f0 

Diff: https://reviews.apache.org/r/55024/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55023: Windows: Fixed malformatted containerizer command in launcher.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55023/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Currently in `MesosContainerizerProcess::_launch`, we are passing a
malformatted shell command to the launcher. This causes the
containerizer process to crash immediately upon invocation in all
executor tests.

This commit will fix this command.


Diffs
-

  src/slave/containerizer/mesos/containerizer.cpp 
d9d5619e45ae1199fc91878f17a33b5647f48305 

Diff: https://reviews.apache.org/r/55023/diff/


Testing
---


Thanks,

Alex Clemmer

Review Request 55022: Windows: Cause errors to be correctly reported in `io::read`.

2016-12-24 Thread Alex Clemmer 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55022/
---

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, John Kordich, 
and Joseph Wu.


Repository: mesos


Description
---

Windows: Cause errors to be correctly reported in `io::read`.


Diffs
-

  3rdparty/libprocess/src/io.cpp 27da897894e12941a6bba5f5eda04c35100d2d73 

Diff: https://reviews.apache.org/r/55022/diff/


Testing
---


Thanks,

Alex Clemmer