Re: Review Request 47123: Added --modules_dir flag to read module manifests from a directory.

2016-05-09 Thread Cody Maloney


> On May 10, 2016, 5:27 a.m., Cody Maloney wrote:
> >

I believe this covers the use cases we need. Be great to have a demo PR of it 
in action for:  https://github.com/dcos/dcos to validate that it does.


- Cody


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


On May 9, 2016, 5:10 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47123/
> ---
> 
> (Updated May 9, 2016, 5:10 p.m.)
> 
> 
> Review request for mesos, Cody Maloney and Till Toenshoff.
> 
> 
> Bugs: MESOS-5173
> https://issues.apache.org/jira/browse/MESOS-5173
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This allows the operator to use separate manifest JSON files for each
> module.  Previously, one had to merge all module manifest files into a
> single JSON file before passing on to the master/agent.
> 
> 
> Diffs
> -
> 
>   src/master/flags.hpp e4cac1f8d688319c804e608b7229f458f779364a 
>   src/master/flags.cpp c0c9e924e876175b75a174e375a4c993d97e18ee 
>   src/master/main.cpp 23149d5511d1556f1a885d01ea9380a9669fa8c5 
>   src/module/manager.hpp 9944af0daf6c9cb5a8ff338099401b1db88ee237 
>   src/module/manager.cpp 9f88ec3addab59e4a40b0b40612518178d535aa5 
>   src/sched/flags.hpp b4ca12b667283cee1f96a4b421fcf3b06bbe59d7 
>   src/sched/sched.cpp 4693d0dc09afc3ddbbf34e166579b6a6d71c3e38 
>   src/slave/flags.hpp 4fa3213545d4bd3525d85c3f71749f00f08dc998 
>   src/slave/flags.cpp 6fde51fc61cfcad61d4085c208bd2eca2eae8f14 
>   src/slave/main.cpp fee46bafc88f8cdade868aab8c0fee79b8d2fb6d 
>   src/tests/flags.hpp ae232b1a087edfaf678bd1c67bc509efd6c740d8 
>   src/tests/main.cpp c3ccf918c781bdb25b220c7ef3efa7d3b7c88c91 
> 
> Diff: https://reviews.apache.org/r/47123/diff/
> 
> 
> Testing
> ---
> 
> Manual testing with:
> 1. --module_dir
> 2. --modules
> 3. --module_dir in conjunction with --modules
> 
> The first two succeeded while the third failed as expected.
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>



Re: Review Request 47123: Added --modules_dir flag to read module manifests from a directory.

2016-05-09 Thread Cody Maloney

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




src/module/manager.cpp (line 357)
<https://reviews.apache.org/r/47123/#comment196564>

Should do the early exit:
`if (moduleManifests.isNone()) { return Nothing(); }`

That way the rest doesn't need to be indented.



src/module/manager.cpp (line 358)
<https://reviews.apache.org/r/47123/#comment196565>

Should document the sort order / load order based on filenames inside the 
doc changes to accompany this (I don't see it anywhere currently)



src/module/manager.cpp (line 377)
<https://reviews.apache.org/r/47123/#comment196566>

Is there a semantic difference between loading modules one at a time vs. 
just passing them all at once to loadManifest?

I'm worried that the behavior here could differ slightly from the --modules 
flag which calls loadManifest with all the modules at once.


- Cody Maloney


On May 9, 2016, 5:10 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47123/
> ---
> 
> (Updated May 9, 2016, 5:10 p.m.)
> 
> 
> Review request for mesos, Cody Maloney and Till Toenshoff.
> 
> 
> Bugs: MESOS-5173
> https://issues.apache.org/jira/browse/MESOS-5173
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This allows the operator to use separate manifest JSON files for each
> module.  Previously, one had to merge all module manifest files into a
> single JSON file before passing on to the master/agent.
> 
> 
> Diffs
> -
> 
>   src/master/flags.hpp e4cac1f8d688319c804e608b7229f458f779364a 
>   src/master/flags.cpp c0c9e924e876175b75a174e375a4c993d97e18ee 
>   src/master/main.cpp 23149d5511d1556f1a885d01ea9380a9669fa8c5 
>   src/module/manager.hpp 9944af0daf6c9cb5a8ff338099401b1db88ee237 
>   src/module/manager.cpp 9f88ec3addab59e4a40b0b40612518178d535aa5 
>   src/sched/flags.hpp b4ca12b667283cee1f96a4b421fcf3b06bbe59d7 
>   src/sched/sched.cpp 4693d0dc09afc3ddbbf34e166579b6a6d71c3e38 
>   src/slave/flags.hpp 4fa3213545d4bd3525d85c3f71749f00f08dc998 
>   src/slave/flags.cpp 6fde51fc61cfcad61d4085c208bd2eca2eae8f14 
>   src/slave/main.cpp fee46bafc88f8cdade868aab8c0fee79b8d2fb6d 
>   src/tests/flags.hpp ae232b1a087edfaf678bd1c67bc509efd6c740d8 
>   src/tests/main.cpp c3ccf918c781bdb25b220c7ef3efa7d3b7c88c91 
> 
> Diff: https://reviews.apache.org/r/47123/diff/
> 
> 
> Testing
> ---
> 
> Manual testing with:
> 1. --module_dir
> 2. --modules
> 3. --module_dir in conjunction with --modules
> 
> The first two succeeded while the third failed as expected.
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>



Re: Review Request 41680: Reduced LogLevel in order to avoid overflowing logs.

2015-12-23 Thread Cody Maloney

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

Ship it!


Ship It!

- Cody Maloney


On Dec. 23, 2015, 9:06 a.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41680/
> ---
> 
> (Updated Dec. 23, 2015, 9:06 a.m.)
> 
> 
> Review request for mesos and Bernd Mathiske.
> 
> 
> Bugs: MESOS-4181
> https://issues.apache.org/jira/browse/MESOS-4181
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Especially the logging of port ranges resulted in enourmous logs, reduced the 
> log level from LOG(INFO) to VLOG(1).
> 
> 
> Diffs
> -
> 
>   src/master/allocator/mesos/hierarchical.cpp 
> 775182515dcb52bd873ecdf98c827320251a59c8 
> 
> Diff: https://reviews.apache.org/r/41680/diff/
> 
> 
> Testing
> ---
> 
> make check and checked logs
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>



Re: Review Request 39388: Explicitly set the `LIBPROCESS_IP` env variable for docker containers.

2015-11-05 Thread Cody Maloney


> On Nov. 2, 2015, 5:43 a.m., Timothy Chen wrote:
> > src/docker/docker.cpp, line 433
> > 
> >
> > I think there are two problems here to address:
> > - --net is not always set to host, and if it's not it's causing problem 
> > as LIBPROCESS_IP takes precedence and also causes framework to not be able 
> > to connect
> > - docker code here in src/docker/docker.cpp is meant to be an 
> > abstraction to run docker, which we use to run executors and docker tasks. 
> > It shouldn't really have logic like this embedded especialy when this is 
> > not the desire effect for all docker containers we ever launch from Mesos. 
> > And really this problem and setting has to be two cases 1) We run a 
> > executor in the docker container 2) --net is host. We need to specifically 
> > solve this outside of the docker abstraction.

libprocess processes running with non-host networking (--net=bridge) won't work 
as libprocess processes doesn't like crossing NAT boundaries (which bridge 
networking is).

That we set it to the host IP might actually make it work better than if we 
don't (The libprocess inside the docker container announces the public host IP, 
which makes it so if it is talking to libprocess processes on other remote 
hosts, the remote hosts will get the IP which actually works to connect back, 
rather than the docker internal IP which doesn't. If you're running a bunch of 
things on the same host and connecting the docker networks together then that 
wouldn't work. The way libprocess works I think making both those work at once 
isn't feasible, and the --net=host working at all is generally preferrable (We 
launch mesos frameworks inside of docker containers, they need to talk to the 
Mesos Master using libmesos)


- Cody


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


On Oct. 17, 2015, 11:18 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39388/
> ---
> 
> (Updated Oct. 17, 2015, 11:18 p.m.)
> 
> 
> Review request for mesos and Niklas Nielsen.
> 
> 
> Bugs: MESOS-3740
> https://issues.apache.org/jira/browse/MESOS-3740
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.cpp 56d63dc75637c9f89a239af371f476a85a570696 
>   src/tests/containerizer/docker_containerizer_tests.cpp 
> 4bb65afd0ee61cafef68e064a697fdce65d60058 
> 
> Diff: https://reviews.apache.org/r/39388/diff/
> 
> 
> Testing
> ---
> 
> Added `DockerContainerizerTest.ROOT_DOCKER_LaunchWithLibprocessIP` test which 
> fails without the changes made to `src/docker/docker.cpp`.
> 
> 
> Thanks,
> 
> Michael Park
> 
>



Re: Review Request 39152: Pass LIBPROCESS_IP even when executor environment is specified.

2015-10-09 Thread Cody Maloney

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


LGTM!

- Cody Maloney


On Oct. 9, 2015, 12:57 a.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39152/
> ---
> 
> (Updated Oct. 9, 2015, 12:57 a.m.)
> 
> 
> Review request for mesos and Kapil Arya.
> 
> 
> Bugs: MESOS-3553
> https://issues.apache.org/jira/browse/MESOS-3553
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If DNS is not available on the agent node and a task is launched which 
> explicitly specifies the executor's environment, LIBPROCESS_IP will not be 
> passed through and the default hostname lookup after spawning the executor 
> process will throw an error. This patch alters the agent to always pass 
> LIBPROCESS_IP, even when the executor environment is specified.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/containerizer.cpp 
> 25c87e9f948b7efe8b9a853c403bee69982d6c4c 
>   src/tests/containerizer/mesos_containerizer_tests.cpp 
> 5bc7d408bda0c249e1b66747d8bd87e688362e6c 
> 
> Diff: https://reviews.apache.org/r/39152/diff/
> 
> 
> Testing
> ---
> 
> `make check`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>



Re: Review Request 36811: Don't check protobuf jar when --disable-java flag.

2015-08-04 Thread Cody Maloney

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



configure.ac (line 544)
https://reviews.apache.org/r/36811/#comment148717

The check should come before we do the AC_SUBST. I don't want to just move 
the AC_SUBST way away from the rest of the protobuf checking code though.

I think it would be better moving the whole protobuf / protobuf.jar check 
section to after the java check, then just update the if java check around 
the AC_CHECK_FILE where it was previously.


- Cody Maloney


On Aug. 4, 2015, 9:27 a.m., haosdent huang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36811/
 ---
 
 (Updated Aug. 4, 2015, 9:27 a.m.)
 
 
 Review request for mesos, Adam B, Cody Maloney, Michael Park, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2480
 https://issues.apache.org/jira/browse/MESOS-2480
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Don't check protobuf jar when --disable-java flag.
 
 
 Diffs
 -
 
   configure.ac 546c9bbf775a4ef481fafb3a58c85c6d80e19500 
 
 Diff: https://reviews.apache.org/r/36811/diff/
 
 
 Testing
 ---
 
 ../configure --with-protobuf=/usr/local --disable-java
 make -j4
 make check
 ```
 [--] Global test environment tear-down
 [==] 644 tests from 91 test cases ran. (431596 ms total)
 [  PASSED  ] 644 tests.
 ```
 
 ../configure
 make -j4
 make check
 ```
 [--] Global test environment tear-down
 [==] 685 tests from 98 test cases ran. (554759 ms total)
 [  PASSED  ] 685 tests.
 ```
 
 ../configure --disable-java
 make -j4
 make check
 ```
 [--] Global test environment tear-down
 [==] 644 tests from 91 test cases ran. (427688 ms total)
 [  PASSED  ] 644 tests.
 ```
 
 ../configure --with-protobuf=/usr/local
 make -j4
 make check
 ```
 [--] Global test environment tear-down
 [==] 685 tests from 98 test cases ran. (551493 ms total)
 [  PASSED  ] 685 tests.
 ```
 
 
 Thanks,
 
 haosdent huang
 




Re: Review Request 36810: Don't check protobuf jar in libprocess.

2015-08-04 Thread Cody Maloney

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

Ship it!


Seems reasonable to me. I haven't run a build personally toto guarantee things 
keep working.

- Cody Maloney


On Aug. 4, 2015, 9:27 a.m., haosdent huang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36810/
 ---
 
 (Updated Aug. 4, 2015, 9:27 a.m.)
 
 
 Review request for mesos, Adam B, Cody Maloney, Michael Park, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2480
 https://issues.apache.org/jira/browse/MESOS-2480
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Don't check protobuf jar in libprocess.
 
 
 Diffs
 -
 
   3rdparty/libprocess/configure.ac 7d1221bd5ddfc4fa816b0bbea0be5c6b2cbb 
 
 Diff: https://reviews.apache.org/r/36810/diff/
 
 
 Testing
 ---
 
 ../configure --with-protobuf=/usr/local --disable-java
 make -j4
 make check -j4 GTEST_FILTER=-*
 
 
 Thanks,
 
 haosdent huang
 




Re: Review Request 36425: Enabling IP Discovery script

2015-07-13 Thread Cody Maloney

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



docs/configuration.md (line 92)
https://reviews.apache.org/r/36425/#comment144889

Default isn't quite correct here. More accurate is `Mesos will do a lookup 
of the machine's hostname to try and figure out what IP address to use`



src/master/main.cpp (line 22)
https://reviews.apache.org/r/36425/#comment144891

Please use stdlib.h or use the c* variants consistently



src/master/main.cpp (line 35)
https://reviews.apache.org/r/36425/#comment144893

unused include



src/master/main.cpp (line 39)
https://reviews.apache.org/r/36425/#comment144894

unused include



src/master/main.cpp (line 148)
https://reviews.apache.org/r/36425/#comment144895

Supersedes - Overrides like you did in the docs?



src/master/main.cpp (line 211)
https://reviews.apache.org/r/36425/#comment144899

Could you add a basic Can we change this discoveredIp - an actual IP 
address check here?  The error message when LIBPROCESS_IP ends up incorrect 
inside libprocess is going to not say very cleanly where that value came from, 
and I suspect when doing iteration it will be fairly common for people to write 
IP scripts which give incorrect / invalid output.


- Cody Maloney


On July 13, 2015, 4:35 p.m., Marco Massenzio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36425/
 ---
 
 (Updated July 13, 2015, 4:35 p.m.)
 
 
 Review request for mesos, Benjamin Hindman and Cody Maloney.
 
 
 Bugs: MESOS-2902
 https://issues.apache.org/jira/browse/MESOS-2902
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Jira: MESOS-2902
 
 It is sometimes useful to enable an external script to
 configure the IP address the Mesos Master will bind to
 on the server, where it's not desirable to set the
 --ip flag and/or a wrapper script is not a viable option.
 
 This patch adds a --ip_discovery_script to point to a local
 script that will emit as its only output the IP address that
 the Master will bind to: only spaces and newlines are allowed;
 further, as we cannot use the `libprocess` sub-processing
 facilities, we cannot timeout the script, should this block
 for long times (or even forever).
 
 This will override the --ip flag, which, even if set, will be
 ignored.
 
 
 Diffs
 -
 
   docs/configuration.md feee5594c88112f77ce382cb3dd8628653f92d01 
   src/master/main.cpp fd4de4d0d9c3e9617408022d10b5e161bdc911e1 
 
 Diff: https://reviews.apache.org/r/36425/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Marco Massenzio
 




Re: Review Request 36425: Enabling IP Discovery script

2015-07-13 Thread Cody Maloney


 On July 13, 2015, 6:14 p.m., Anand Mazumdar wrote:
  src/master/main.cpp, line 211
  https://reviews.apache.org/r/36425/diff/2/?file=1009590#file1009590line211
 
  Can we remove the reference here ? 
  
  strings::trim(...) returns a temporary that would be destroyed at the 
  end of the line leaving you with a dangling reference.

Not actually a dangling reference since the C++ spec actually specifies the 
value lives as long as  the reference in this case. But it is against the style 
guide. See http://mesos.apache.org/documentation/latest/mesos-c++-style-guide/ 
section Capture by Reference


- Cody


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


On July 13, 2015, 7:25 p.m., Marco Massenzio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36425/
 ---
 
 (Updated July 13, 2015, 7:25 p.m.)
 
 
 Review request for mesos, Benjamin Hindman and Cody Maloney.
 
 
 Bugs: MESOS-2902
 https://issues.apache.org/jira/browse/MESOS-2902
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Jira: MESOS-2902
 
 It is sometimes useful to enable an external script to
 configure the IP address the Mesos Master will bind to
 on the server, where it's not desirable to set the
 --ip flag and/or a wrapper script is not a viable option.
 
 This patch adds a --ip_discovery_script to point to a local
 script that will emit as its only output the IP address that
 the Master will bind to: only spaces and newlines are allowed;
 further, as we cannot use the `libprocess` sub-processing
 facilities, we cannot timeout the script, should this block
 for long times (or even forever).
 
 This will override the --ip flag, which, even if set, will be
 ignored.
 
 
 Diffs
 -
 
   docs/configuration.md feee5594c88112f77ce382cb3dd8628653f92d01 
   src/master/main.cpp fd4de4d0d9c3e9617408022d10b5e161bdc911e1 
 
 Diff: https://reviews.apache.org/r/36425/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Marco Massenzio
 




Re: Review Request 36425: Enabling IP Discovery script

2015-07-13 Thread Cody Maloney


 On July 13, 2015, 9:12 p.m., Cody Maloney wrote:
  Generally looks reasonable to me. I haven't integration tested yet inside 
  DCOS, will work on that before too long.
 
 Marco Massenzio wrote:
  reasonable
 
 not exactly a ringing endorsement :) but I guess I'll take it...
 care to give me a Ship it?

Ship It comes post integration test. I still dislike the fopen() api a lot, but 
that one isn't your fault.


- Cody


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


On July 13, 2015, 9:35 p.m., Marco Massenzio wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/36425/
 ---
 
 (Updated July 13, 2015, 9:35 p.m.)
 
 
 Review request for mesos, Benjamin Hindman and Cody Maloney.
 
 
 Bugs: MESOS-2902
 https://issues.apache.org/jira/browse/MESOS-2902
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Jira: MESOS-2902
 
 It is sometimes useful to enable an external script to
 configure the IP address the Mesos Master will bind to
 on the server, where it's not desirable to set the
 --ip flag and/or a wrapper script is not a viable option.
 
 This patch adds a --ip_discovery_script to point to a local
 script that will emit as its only output the IP address that
 the Master will bind to: only spaces and newlines are allowed;
 further, as we cannot use the `libprocess` sub-processing
 facilities, we cannot timeout the script, should this block
 for long times (or even forever).
 
 This will override the --ip flag, which, even if set, will be
 ignored.
 
 
 Diffs
 -
 
   docs/configuration.md feee5594c88112f77ce382cb3dd8628653f92d01 
   src/master/main.cpp fd4de4d0d9c3e9617408022d10b5e161bdc911e1 
 
 Diff: https://reviews.apache.org/r/36425/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Marco Massenzio
 




Re: Review Request 32982: Added reservation user guide.

2015-06-26 Thread Cody Maloney


 On May 13, 2015, 10:25 p.m., Marco Massenzio wrote:
  docs/reservation.md, line 71
  https://reviews.apache.org/r/32982/diff/1/?file=921006#file921006line71
 
  this seems to imply that in the Request, the `slave_id` is some part of 
  a form submission:
  ```
  -d, --data data
   (HTTP) Sends the specified data in a POST request to the HTTP
   server, in the same way that a browser does
   when a user has filled in an HTML form and presses the submit
   button. This will cause curl  to  pass  the data to the server
   using the content-type application/x-www-form-urlencoded.
  ```
  
  IMO the API should instead carry the `slave_id` either as part of the 
  URL (`/reserve/slave_id/1234-xyz`) or part of the JSON body:
  ```
  {
  slave_id: 1234-xyz,
  resources: {
 name : cpus,
 type : SCALAR,
 scalar : { value : 8 },
 ...
  }
  }
  ```
  Also, we need to be sure that the `Content-Type` is set accordingly 
  (`application/json`)
  
  The same for all the other endpoints.

I think just having it all be in the request body is more like how Mesos does 
all the rest of it's endpoints currently.

For the HTTP API version would be nice to do JSON, but the current 
protobuf/http Mesos APIs currently they all work on the form encoding thing 
which is a standard (Although mesos only implements a specific subset of it 
with some quirks).


- Cody


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


On June 26, 2015, 7:53 p.m., Michael Park wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32982/
 ---
 
 (Updated June 26, 2015, 7:53 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Jie Yu, and Timothy Chen.
 
 
 Bugs: MESOS-2205
 https://issues.apache.org/jira/browse/MESOS-2205
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   docs/reservation.md PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32982/diff/
 
 
 Testing
 ---
 
 Documentation.
 
 
 Thanks,
 
 Michael Park
 




Re: Review Request 35234: libprocess: consistent handling of --enable options

2015-06-23 Thread Cody Maloney


 On June 9, 2015, 12:26 a.m., Till Toenshoff wrote:
  3rdparty/libprocess/configure.ac, line 31
  https://reviews.apache.org/r/35234/diff/1/?file=980998#file980998line31
 
  Can we switch to `#` prefixed comments here  instead?
 
 James Peach wrote:
 Originally I used #-comments, but since autoconf completely elides the 
 macro definition, this results in the header comments hanging in the middle 
 of nowhere in the resulting configure script, which just looks weird. If you 
 really want me to change it I will though :)

Sounds good to me


- Cody


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


On June 9, 2015, 12:04 a.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/35234/
 ---
 
 (Updated June 9, 2015, 12:04 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2537
 https://issues.apache.org/jira/browse/MESOS-2537
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Let both --enable-$OPTION and --disable-$OPTION work consistently.
 Add bundled package options consistent with Mesos, so that options
 passed down from Mesos work correctly.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/Makefile.am 
 519e38c2c22904e75f36b936142a915a8f615b21 
   3rdparty/libprocess/configure.ac 710490b2a7c71f35434494e87e2d132f78ef370a 
 
 Diff: https://reviews.apache.org/r/35234/diff/
 
 
 Testing
 ---
 
 Make and make check on CentOS 7 and OS X. There's definitely combinations 
 that have not been tested!
 
 Note that this removes some login around using gmock. AFAICT the unbundled 
 gmock doesn't work in the general case. I have a bunch of crashes where the 
 build would pick up gtest headers from the system and gmock from libprocess 
 3rdparty. My conclusion is that the only safe path is to use the bundled 
 gmock. There's no real path through the build to use decoupled gmock and 
 gtest, it seems to be assumed that gmock will provide gtest.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 34881: let libprocess to compile on arm64 servers

2015-06-21 Thread Cody Maloney

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



3rdparty/libprocess/3rdparty/protobuf-2.5.0.patch (line 18)
https://reviews.apache.org/r/34881/#comment141289

Where did this header come from? If we were to just update protobuf to a 
newer version would it just compile?


- Cody Maloney


On June 1, 2015, 7:10 a.m., Dong Robin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34881/
 ---
 
 (Updated June 1, 2015, 7:10 a.m.)
 
 
 Review request for mesos.
 
 
 Bugs: MESOS-2786
 https://issues.apache.org/jira/browse/MESOS-2786
 
 
 Repository: mesos
 
 
 Description
 ---
 
 To compile libprocess on arm64(aarch64) servers, we need to
 add patches for 3rd software to recognize aarch64 architecture
 and replace x86 assemble language to standard gcc buildin function
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/Makefile.am 
 519e38c2c22904e75f36b936142a915a8f615b21 
   3rdparty/libprocess/3rdparty/glog-0.3.3.patch 
 76b8c0fe3b4615371e265bab713d62c896b7c3d6 
   3rdparty/libprocess/3rdparty/libev-4.15.patch 
 bbd83e6928e6caba3bc5a9739823d60923cfaa2a 
   3rdparty/libprocess/3rdparty/protobuf-2.5.0.patch PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34881/diff/
 
 
 Testing
 ---
 
 Build and run mesos-mater/mesos-slave succesly on arm64 server.
 
 
 Thanks,
 
 Dong Robin
 




Re: Review Request 35179: MESOS-1733 Variadic Path Join

2015-06-09 Thread Cody Maloney


 On June 9, 2015, 6:34 a.m., Cody Maloney wrote:
  3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp, line 58
  https://reviews.apache.org/r/35179/diff/2/?file=980529#file980529line58
 
  I'm still against using enable_if here, it's a lot of extra complexity 
  (And will be slightly greater compile time, as well as more complexity the 
  compiler has to sort out for runtime). I don't see it providing great value 
  over not using it. Hiding it behind a macro doesn't make it simpler.
 
 Anand Mazumdar wrote:
 I removed the usage but is it fine with you if I keep require.hpp i.e. 
 the macro intact ? It might benefit others who find the std::enable_if 
 syntax too cumber-some ? ( I can see a couple of places in the code-base 
 already where this can be used already )
 
 Also, I did not quite understand your argument around a lot of extra 
 complexity. Did you mean syntaxtic complexity around std::enable_if ? ( That 
 is what the macro was trying to achieve to make it as painless to use it. )
 
 As for the compile-time complexity , I wouldn't think about it too much 
 with the modern compilers et al.

Just found a good presentation about the concepts in general: 
https://youtu.be/eR34r7HOU14?t=27m13s. At the very end of that presentation 
(Around 1 hour, 22 minutes in), Chandler talks in specific about doing stuff 
inside recursive variadic templates.

More or less, the template ends up generating a mountain of code and function 
calls which is very hard to analyze as a compiler back end.


- Cody


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


On June 9, 2015, 3:56 p.m., Anand Mazumdar wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/35179/
 ---
 
 (Updated June 9, 2015, 3:56 p.m.)
 
 
 Review request for mesos, Adam B and Cody Maloney.
 
 
 Bugs: MESOS-1733
 https://issues.apache.org/jira/browse/MESOS-1733
 
 
 Repository: mesos
 
 
 Description
 ---
 
 This change takes an un-complicated/naive route ( no trimming of values etc ) 
 at making path::join(...) variadic mainly in order to preserve the earlier 
 over-loaded join functionality.
 
 Might have some C++ style issues owing to this being my first commit here.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 
 d4df6502d1297ea3ad8e2a1e3bb16ea9d7c7913c 
 
 Diff: https://reviews.apache.org/r/35179/diff/
 
 
 Testing
 ---
 
 make check + added some additional tests.
 
 
 Thanks,
 
 Anand Mazumdar
 




Re: Review Request 35084: Provided consistent behavior for bundled packages.

2015-06-08 Thread Cody Maloney


 On June 9, 2015, 12:28 a.m., Cody Maloney wrote:
 

Partial review, going to review more thoroughly later, just posting so it 
doesn't get lost since it was on the old revision


- Cody


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


On June 9, 2015, 12:02 a.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/35084/
 ---
 
 (Updated June 9, 2015, 12:02 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2537
 https://issues.apache.org/jira/browse/MESOS-2537
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Add the MESOS_USE_BUNDLED_PACKAGE() macro to make it easy to provide
 consistent behavior for bundled packages selected by either
 --enable-bundled-$PACKAGE or --with-$PACKAGE.
 
 The default policy is set by --enable-bundled and overridden when
 the user specifies an --enable-bundled-$PACKAGE or --with-$PACKAGE
 option. If --with-$PACKAGE is specified as bundled, the bundled
 version is selected.
 
 
 Diffs
 -
 
   configure.ac cad7f0e92eacc86d37b3f578382946db8b466531 
 
 Diff: https://reviews.apache.org/r/35084/diff/
 
 
 Testing
 ---
 
 Configure and build on CentOS 7 and Mac OS X 10.10.3. Verify various (not 
 exhaustive!) combinations of enabling and disableing bundled packages.
 
 For example, on CentOS, this alost works:
   $ onfigure.developer  --disable-bundled --with-zookeeper=bundled 
 --with-gmock=bundled
 
 To work completely, this change needs to be propagated to libprocess, which I 
 can do once reviewers agree that it's the right behavior.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 35084: Provided consistent behavior for bundled packages.

2015-06-08 Thread Cody Maloney

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



configure.ac
https://reviews.apache.org/r/35084/#comment138798

nit: Could you document auto here? Right now it's an implicit magic value 
like 'bundled' in a lot of ways.

I also wonder if it is possible to have this macro set the AC_ARG_WITH / 
AC_ARG_ENABLE, but that definitely isn't necessary / blocker here.



configure.ac
https://reviews.apache.org/r/35084/#comment138799

Since these all follow about the same structure could we add an autoconf 
macro which takes the package name followed by the help description and  does 
the rest automatically?


- Cody Maloney


On June 9, 2015, 12:02 a.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/35084/
 ---
 
 (Updated June 9, 2015, 12:02 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2537
 https://issues.apache.org/jira/browse/MESOS-2537
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Add the MESOS_USE_BUNDLED_PACKAGE() macro to make it easy to provide
 consistent behavior for bundled packages selected by either
 --enable-bundled-$PACKAGE or --with-$PACKAGE.
 
 The default policy is set by --enable-bundled and overridden when
 the user specifies an --enable-bundled-$PACKAGE or --with-$PACKAGE
 option. If --with-$PACKAGE is specified as bundled, the bundled
 version is selected.
 
 
 Diffs
 -
 
   configure.ac cad7f0e92eacc86d37b3f578382946db8b466531 
 
 Diff: https://reviews.apache.org/r/35084/diff/
 
 
 Testing
 ---
 
 Configure and build on CentOS 7 and Mac OS X 10.10.3. Verify various (not 
 exhaustive!) combinations of enabling and disableing bundled packages.
 
 For example, on CentOS, this alost works:
   $ onfigure.developer  --disable-bundled --with-zookeeper=bundled 
 --with-gmock=bundled
 
 To work completely, this change needs to be propagated to libprocess, which I 
 can do once reviewers agree that it's the right behavior.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 34225: Deleted travis YAML file.

2015-05-14 Thread Cody Maloney

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

Ship it!


Ship It!

- Cody Maloney


On May 14, 2015, 6:21 p.m., Vinod Kone wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34225/
 ---
 
 (Updated May 14, 2015, 6:21 p.m.)
 
 
 Review request for mesos and Ben Mahler.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Travis builds are not supported/maintained; so it doesn't make sense to have 
 this file and TravisCI keep trying to build the project and send failure 
 notifications to the IRC channel.
 
 We have moved to Docker based builds on ASF to test Mesos on different 
 configurations.
 
 
 Diffs
 -
 
   .travis.yml 4991dd77a62b8bfc6045099ca99682b47aadaa97 
 
 Diff: https://reviews.apache.org/r/34225/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Vinod Kone
 




Re: Review Request 33643: Add EMPTY to stout hashset

2015-05-05 Thread Cody Maloney

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



3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
https://reviews.apache.org/r/33643/#comment133391

Any reason we can't do this as a function with a static in it? Solves the 
destruction order issues, doesn't leak, doesn't require the constant reference.


- Cody Maloney


On May 5, 2015, 9:50 p.m., Joris Van Remoortere wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33643/
 ---
 
 (Updated May 5, 2015, 9:50 p.m.)
 
 
 Review request for mesos and Benjamin Hindman.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp 
 d2b74393b7c4b65477698d9c810dfe3c8673c2ab 
 
 Diff: https://reviews.apache.org/r/33643/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Joris Van Remoortere
 




Re: Review Request 33849: mesos: use standard macros for compiler and vendor detection

2015-05-05 Thread Cody Maloney


 On May 5, 2015, 4:29 p.m., Cody Maloney wrote:
  configure.ac, line 575
  https://reviews.apache.org/r/33849/diff/1/?file=950367#file950367line575
 
  Can you check ax_cxx_compiler_version = Clang/LLVM 3.5 here? Or does 
  that not work on both OS X and Linux?
 
 James Peach wrote:
 Hmm. I don't have a Linux system with clang 3.5 and I'm not quite sure 
 what you are asking here. I do have a later version of OS X clang and this 
 change works (and automatically disables unused local typedef warnings).
 
 I tried to leave the compiler logic alone in this patch since I don't 
 have systems to test all the possible combinations. I agree that it would be 
 desirable to separate the typedef warnings from the compiler versions (though 
 I was confused that GCC and clang seem to have subtly different names for the 
 same warning). I'm happy to knock up a separate patch for that if you like.
 
 James Peach wrote:
 If you're asking whether we can drop the ``-Wno-unused-local-typedef`` 
 flags on later clangs, I'm not confident that I have the right set of build 
 dependencies to answer that. I tested dropping that warning on my version of 
 clang on OS X (later that 3.5) dropping; both boost and generated protobuf 
 code still spew that warning.
 
 Cody Maloney wrote:
 Apple Clang gives a different version string when you give it `clang 
 --version` than Linux clang
 
 Apple:
 ```
 Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
 Target: x86_64-apple-darwin14.3.0
 Thread model: posix
 ```
 
 Linux:
 ```
 clang version 3.6.0 (tags/RELEASE_360/final)
 Target: x86_64-unknown-linux-gnu
 Thread model: posix
 ```
 
 
 For the `-Wno-unused-local-typedef` - that is definitely a needed flag 
 for some of the Clang + GCC versions we support. It's much more of Lets try 
 compiling some code which checks if we'll generate a warning, then if the 
 compiler is clang add `-Wno-unused-local-typedef`, if it is gcc add 
 `-Wno-unused-local-typedefs` (Note the s).
 
 James Peach wrote:
 That sounds like you want to just unconditionally turn 
 ``-Wunused-local-typedef`` off. Either if you test whether it works, then 
 turn it off if it does, then the net effect is to always turn it off :)

The warning didn't exist in Clang 3.5 though I think, so one of our platforms 
doesn't need it. Other than that one compiler+version combo though it is always 
on


- Cody


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


On May 5, 2015, 5:52 p.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33849/
 ---
 
 (Updated May 5, 2015, 5:52 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2666
 https://issues.apache.org/jira/browse/MESOS-2666
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Import the AX_COMPILER_VERSION and AX_COMPILER_VENDOR macros from
 the autoconf archive and use them to detect and configure the
 supported copmilers.
 
 
 Diffs
 -
 
   configure.ac 14658f6f6920549f1948b8bd8890c67bc067e3dd 
   m4/ax_compiler_vendor.m4 PRE-CREATION 
   m4/ax_compiler_version.m4 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/33849/diff/
 
 
 Testing
 ---
 
 Make check on CentOS 7 and Mac OS X 10.10.3. Verified that the default CentOS 
 6 GCC toolchain is still rejected as too old.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 33849: mesos: use standard macros for compiler and vendor detection

2015-05-05 Thread Cody Maloney

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


A couple nits, but structurally looks good to me overall. Mainly just some 
things I'd like to see cleaned up while we're here


configure.ac
https://reviews.apache.org/r/33849/#comment133264

Can you check ax_cxx_compiler_version = Clang/LLVM 3.5 here? Or does that 
not work on both OS X and Linux?



configure.ac
https://reviews.apache.org/r/33849/#comment133263

Not something you need to do here, but would be nice if we used more or 
less the same check for 'Wno-unused-local-typedef' for both clang and gcc since 
you can easily tell which compiler it is now and update the added flag.



configure.ac
https://reviews.apache.org/r/33849/#comment133265

I know this is a mess I left, but it's not overly clean here that we bundle 
the gcc 4.8 version warning with the unused local typedef flag adding, could 
you pull out the is = gcc 4.8 check to be its own line, then unconditionally 
adding '-Wno-unused-local-typedefs', or using the clang check mentioned above.


- Cody Maloney


On May 5, 2015, 3:53 p.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33849/
 ---
 
 (Updated May 5, 2015, 3:53 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2666
 https://issues.apache.org/jira/browse/MESOS-2666
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Import the AX_COMPILER_VERSION and AX_COMPILER_VENDOR macros from
 the autoconf archive and use them to detect and configure the
 supported copmilers.
 
 
 Diffs
 -
 
   configure.ac 14658f6f6920549f1948b8bd8890c67bc067e3dd 
   m4/ax_compiler_vendor.m4 PRE-CREATION 
   m4/ax_compiler_version.m4 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/33849/diff/
 
 
 Testing
 ---
 
 Make check on CentOS 7 and Mac OS X 10.10.3. Verified that the default CentOS 
 6 GCC toolchain is still rejected as too old.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 33849: mesos: use standard macros for compiler and vendor detection

2015-05-05 Thread Cody Maloney


 On May 5, 2015, 4:29 p.m., Cody Maloney wrote:
  configure.ac, line 575
  https://reviews.apache.org/r/33849/diff/1/?file=950367#file950367line575
 
  Can you check ax_cxx_compiler_version = Clang/LLVM 3.5 here? Or does 
  that not work on both OS X and Linux?
 
 James Peach wrote:
 Hmm. I don't have a Linux system with clang 3.5 and I'm not quite sure 
 what you are asking here. I do have a later version of OS X clang and this 
 change works (and automatically disables unused local typedef warnings).
 
 I tried to leave the compiler logic alone in this patch since I don't 
 have systems to test all the possible combinations. I agree that it would be 
 desirable to separate the typedef warnings from the compiler versions (though 
 I was confused that GCC and clang seem to have subtly different names for the 
 same warning). I'm happy to knock up a separate patch for that if you like.
 
 James Peach wrote:
 If you're asking whether we can drop the ``-Wno-unused-local-typedef`` 
 flags on later clangs, I'm not confident that I have the right set of build 
 dependencies to answer that. I tested dropping that warning on my version of 
 clang on OS X (later that 3.5) dropping; both boost and generated protobuf 
 code still spew that warning.

Apple Clang gives a different version string when you give it `clang --version` 
than Linux clang

Apple:
```
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
```

Linux:
```
clang version 3.6.0 (tags/RELEASE_360/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
```


For the `-Wno-unused-local-typedef` - that is definitely a needed flag for some 
of the Clang + GCC versions we support. It's much more of Lets try compiling 
some code which checks if we'll generate a warning, then if the compiler is 
clang add `-Wno-unused-local-typedef`, if it is gcc add 
`-Wno-unused-local-typedefs` (Note the s).


- Cody


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


On May 5, 2015, 3:53 p.m., James Peach wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33849/
 ---
 
 (Updated May 5, 2015, 3:53 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. 
 Clair.
 
 
 Bugs: MESOS-2666
 https://issues.apache.org/jira/browse/MESOS-2666
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Import the AX_COMPILER_VERSION and AX_COMPILER_VENDOR macros from
 the autoconf archive and use them to detect and configure the
 supported copmilers.
 
 
 Diffs
 -
 
   configure.ac 14658f6f6920549f1948b8bd8890c67bc067e3dd 
   m4/ax_compiler_vendor.m4 PRE-CREATION 
   m4/ax_compiler_version.m4 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/33849/diff/
 
 
 Testing
 ---
 
 Make check on CentOS 7 and Mac OS X 10.10.3. Verified that the default CentOS 
 6 GCC toolchain is still rejected as too old.
 
 
 Thanks,
 
 James Peach
 




Re: Review Request 33193: Warn if g++ 4.8, C++ standard library is too old

2015-04-23 Thread Cody Maloney

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

(Updated April 23, 2015, 9:38 p.m.)


Review request for mesos, Benjamin Hindman, Joris Van Remoortere, and Michael 
Park.


Changes
---

tmp


Repository: mesos


Description
---

Warn if g++  4.8, C++ standard library is too old

Not ready for merging. Want the Clang 3.6 patchset to land first: 
https://reviews.apache.org/r/32749/

A whole bunch more of the C++11 checks can be removed, we can unconditionally 
use -std=c++11, among other things with this change. I'm trying to keep the 
patch relatively minimal though unless we hit a problem after application and 
have to roll it back.

Explicitly don't check clang version number, since extracting it is hard (OS X 
clang behaves differently than Linux clang), and 'clang -dumpversion' always 
reports 4.2.1 for compatibility with some random tools...


Diffs (updated)
-

  configure.ac 7f9e52916b9d78f2bbff9d6ed9871444a0fda629 

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


Testing
---

Basic hand testing gcc 4.9.2, gcc 4.4.7, clang 3.6 all on Windows


Thanks,

Cody Maloney



Re: Review Request 28257: Allow prefix paths in libprocess

2015-04-23 Thread Cody Maloney

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

(Updated April 23, 2015, 11:32 p.m.)


Review request for mesos, Benjamin Hindman, Dominic Hamon, and Joris Van 
Remoortere.


Changes
---

Sharing

Changed name to routeWithPrefix.

Added a helper addRoute for common implementation bits between route and 
routeWithPrefx


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


Repository: mesos


Description
---

Allow prefix paths in libprocess


Diffs (updated)
-

  3rdparty/libprocess/include/process/process.hpp 
392c74df3e8a122aecd3633dffdeec4bcbd1f097 
  3rdparty/libprocess/src/process.cpp cf4e36489be2c6aa01e838c1c71383f248deab5b 

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


Testing
---

make distcheck ubuntu 14.04

Manually browse the mesos web UI and verify that things seem to generally work


Thanks,

Cody Maloney