Re: Review Request 38244: Renamed Filter to OfferFilter.

[Joris Van Remoortere]

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

Ship it!



src/master/allocator/mesos/hierarchical.hpp (line 191)


I see you adjusted this in a further review.



src/master/allocator/mesos/hierarchical.hpp (line 358)


Why did this get added? It isn't used. 
Further, this summary suggests we're only doing a rename, when hre we're 
changing the structure.



src/master/allocator/mesos/hierarchical.hpp (line 998)


See comment above.



src/master/allocator/mesos/hierarchical.hpp (lines 1024 - 1029)


``OfferFilter``
``HierarchicalAllocatorProcess::expire``



src/master/allocator/mesos/hierarchical.hpp (line 1302)


we can add a new line here.



src/master/allocator/mesos/hierarchical.hpp (line 1306)


line wrapping.



src/master/allocator/mesos/hierarchical.hpp (line 1308)


"Filtered offer with "



src/master/allocator/mesos/hierarchical.hpp (line 1311)


we can add a new line here.



src/master/allocator/mesos/hierarchical.hpp 


no need to remove this.


- Joris Van Remoortere


On Sept. 18, 2015, 10:55 p.m., Artem Harutyunyan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38244/
> ---
> 
> (Updated Sept. 18, 2015, 10:55 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Bugs: MESOS-3346
> https://issues.apache.org/jira/browse/MESOS-3346
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/master/allocator/mesos/hierarchical.hpp 
> 3374d63b8311cf10b3108f56b7b167c12a9d7a37 
> 
> Diff: https://reviews.apache.org/r/38244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Artem Harutyunyan
> 
>

Re: Review Request 38324: Added support for setting accept and decline filters on inverse offers.

[Joris Van Remoortere]

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

Ship it!



include/mesos/master/allocator.hpp (line 162)


Why don't we default to None here?



src/master/allocator/mesos/hierarchical.hpp (line 220)


See comment below.



src/master/allocator/mesos/hierarchical.hpp (line 402)


We don't need the slave id anymore.



src/master/allocator/mesos/hierarchical.hpp (line 403)


Since this is a specific implementation of an allocator, and the only time 
we send out inverse offers is at the slave level for maintenance primitives, I 
think we don't need to capture the unavailableResources for now.
We can leave a comment here explaining this.



src/master/allocator/mesos/hierarchical.hpp (line 411)


same here and in the implementation.



src/master/allocator/mesos/hierarchical.hpp (line 423)


We don't need to compare the slaveId anymore.



src/master/allocator/mesos/hierarchical.hpp (line 589)


I think we need to clear inverse offer filters as well?



src/master/allocator/mesos/hierarchical.hpp (lines 908 - 909)


Let's clear the inverse offer filters explicitly to force frameworks to 
reassess their calculations.



src/master/allocator/mesos/hierarchical.hpp (line 1130)


I think we need to clear inverse offers filters as well?



src/master/allocator/mesos/hierarchical.hpp (line 1331)


Adjusted to not include the unavailableResources.



src/master/allocator/mesos/hierarchical.hpp (lines 1331 - 1334)


we can move this above now that we don't need to construct 
unavailableResources to filter.



src/master/allocator/mesos/hierarchical.hpp (line 1335)


new line



src/master/allocator/mesos/hierarchical.hpp (lines 1401 - 1402)


wrapping


- Joris Van Remoortere


On Sept. 18, 2015, 10:55 p.m., Artem Harutyunyan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38324/
> ---
> 
> (Updated Sept. 18, 2015, 10:55 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Joseph Wu.
> 
> 
> Bugs: MESOS-3346
> https://issues.apache.org/jira/browse/MESOS-3346
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   include/mesos/master/allocator.hpp fb09e2a6502bc8c78ddcc8a595bcd9320da136ea 
>   src/master/allocator/mesos/allocator.hpp 
> 171548b2017a0b97124f052c21345668e274d117 
>   src/master/allocator/mesos/hierarchical.hpp 
> 3374d63b8311cf10b3108f56b7b167c12a9d7a37 
>   src/master/master.cpp 1c4e7af7448c05f54c1068d6496ed21c8c359ac5 
>   src/tests/mesos.hpp 3db97aca921c9216d90384e1eb17030849516454 
> 
> Diff: https://reviews.apache.org/r/38324/diff/
> 
> 
> Testing
> ---
> 
> Test in the next review.
> 
> 
> Thanks,
> 
> Artem Harutyunyan
> 
>

Re: Review Request 38530: CMake: Add preprocessor definitions required to build picojson 1.3.0.

[Alex Clemmer]

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

(Updated Sept. 20, 2015, 2:07 a.m.)


Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


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


Repository: mesos


Description
---

CMake: Add preprocessor definitions required to build picojson 1.3.0.


Diffs
-

  cmake/MesosConfigure.cmake b530da4c1e6f202b682ad7d6892da95d2181f8c8 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Re: Review Request 38529: CMake: Only compile proc_tests.cpp for Linux platforms.

[Alex Clemmer]

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

(Updated Sept. 20, 2015, 2:07 a.m.)


Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


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


Repository: mesos


Description
---

CMake: Only compile proc_tests.cpp for Linux platforms.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/tests/CMakeLists.txt 
baa648aacfd5204c33e102b58126862729fbb612 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Re: Review Request 38473: Add flag to disable hostname lookup.

[Marco Massenzio]

> On Sept. 18, 2015, 10:57 p.m., Cong Wang wrote:
> > Why not just set --host_name=$LIBPROCESS_IP for your case since you anyway 
> > need to provide a flag?
> 
> Guangya Liu wrote:
> I also have the same question with Cong, @Marco, can you please show more 
> detail for why not using the solution as above? What is the benefit of this 
> compared to using --host_name=$LIBPROCESS_IP? Thanks.

`$LIBPROCESS_IP` may not be set by the time we run the binary - it is actually 
set in the `main()` method (of both Master/Agent) after parsing the `--ip` (and 
`--ip_discovery_command`) flags.

The reason I use `LIBPROCESS_IP` here is to ensure that the IP used by 
`libprocess` (which is initialized before creating the `Master` or `Slave` 
object) is consistent with what the `Master/Agent` will be configured with.

Please also refer to the conversation about the introduction of 
`--ip_discovery_command` as to why we need a "dynamic" way of configuring 
hostname/IP - it all boils down to make Mesos play nice in various Cloud (and 
Enterprise data centers) where the DNS resolution (and hostname configuration 
of VMs) is vastly different and may not necessarily conform to the generally 
assumed scenario, where IP/hostname are kept in sync / resolved by the OS 
and/or external services (DHCP/DNS).


- Marco


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


On Sept. 19, 2015, 1:25 a.m., Marco Massenzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38473/
> ---
> 
> (Updated Sept. 19, 2015, 1:25 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Cody Maloney, and Neil Conway.
> 
> 
> Bugs: MESOS-3457
> https://issues.apache.org/jira/browse/MESOS-3457
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Under certain circumstances, dynamic lookup of hostname, while
> successful, provides undesirable results; we would also like, in
> those circumstances, be able to just set the hostname to the chosen
> IP address (possibly set via the --ip_discovery_command method).
> 
> The flag we add here, --[no]-hostname_lookup is `true` by default
> (which is the existing behavior) and will work under most
> circumstances: however, by disabling lookup (using, for example,
> --no_hostname_lookup) the hostname used will be the same as the
> one configured (possibly, via --ip or MESOS_IP) in `LIBPROCESS_IP`.
> 
> This change affects both Master/Agent nodes.
> 
> WARNING - the `Address::hostname()` method always does a dynamic
> hostname lookup, which may in fact return inconsistent results
> wrt the Master's configuration (this is *not* affected by
> this change) and should be avoided; use instead
> `Master::info()::hostname()` which is always consistent with
> the Master's configuration.
> 
> 
> Diffs
> -
> 
>   docs/configuration.md dd7f4aa806a3c1a8653a0fda9a326a3707308e7c 
>   src/master/flags.hpp e4b1df3f5a33049defff4688463274067f1f1ebf 
>   src/master/flags.cpp 80879611fbcfd764c9fc8f60a31613a9c8fc2364 
>   src/master/master.cpp ca4d5876dcd427964111428edc22d567ddaede0b 
>   src/slave/flags.hpp e31a4183170c3442ac4a15365c229391e7e91480 
>   src/slave/flags.cpp add4196dfd06c0f602ff5ebd39960dc05c4cd11f 
>   src/slave/slave.cpp ad710d7b930a2f115d503ceb8f8fd7421ad30287 
>   src/tests/cluster.hpp 114583de8c867495a2b7a953e6826708838e5d23 
>   src/tests/master_tests.cpp a477794df37c658b80d79dea8555b001415f7b6a 
>   src/tests/mesos.hpp 3db97aca921c9216d90384e1eb17030849516454 
> 
> Diff: https://reviews.apache.org/r/38473/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38456, 38457]

All tests passed.

- Mesos ReviewBot


On Sept. 20, 2015, 2:03 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
> 
> (Updated Sept. 20, 2015, 2:03 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Bugs: MESOS-3250
> https://issues.apache.org/jira/browse/MESOS-3250
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> A few third-party libraries (libev, gmock) do not have `make install`
> commands available, so below we have to add our own "install" commands.
> 
> The reason is: if we do not, we get runtime library load problems on OS
> X. In particular, `dydl` will look for these libraries at the prefix we
> passed to `configure` (or in `/usr/local` if we did not pass a prefix
> in), but since they don't have a `make install` step, they never get
> placed in the prefix folder.
> 
> Our solution is to:
>   (1) make a lib directory inside the Mesos folder for each of the
>   libraries that has no install step, and
>   (2) copy all such libraries into their respective directories.
> 
> (Note that step (1) is not only convenient, but important: make will add
> a `lib` to the end of your prefix path when linking, and since the built
> libraries end up in a `.libs` folder, it's not enough to simply pass the
> build directory into `configure` as a prefix; so if we're going to move
> the libraries, we might as well move them to a library folder.)
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/CMakeLists.txt 
> b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d 
> 
> Diff: https://reviews.apache.org/r/38457/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Review Request 38528: Disable perf test when perf version is not support.

[haosdent huang]

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

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


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


Repository: mesos


Description
---

Disable perf test when perf version is not support.


Diffs
-

  src/tests/environment.cpp e40cde23daba25b0b61b567ee73682c67e7acbdc 

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


Testing
---

# On CentOS 6.6
sudo make check -j8


Thanks,

haosdent huang

Re: Review Request 38528: Disable perf test when perf version is not support.

[haosdent huang]

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

(Updated Sept. 19, 2015, 7:30 p.m.)


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


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


Repository: mesos


Description
---

Disable perf test when perf version is not support.


Diffs
-

  src/tests/environment.cpp e40cde23daba25b0b61b567ee73682c67e7acbdc 

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


Testing (updated)
---

# On CentOS 6.6
sudo make -j8 check


Thanks,

haosdent huang

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Alex Clemmer]

> On Sept. 17, 2015, 4:44 p.m., Marco Massenzio wrote:
> > I'm excited about this!
> > Tested on OSX and (at least, as far as stout_tests go, it works, yay!)
> > 
> > A quick question: why, instead of moving the files, we don't simply add a 
> > symlink that will "look right" to the linker etc.
> > (this may be an exceedingly dumb question, due to my extremely limited 
> > understanding of the build system)
> > 
> > Thanks, Alex, for doing this - can't wait to bid farewell to CDT for good.

I don't know that there's a particular reason to _not_ use a symlink, but the 
reasons I went with a hard copy are:

(1) It's not clear that it was easier or cleaner to symlink.
(2) Every other install command does a hard copy and it might lead to weird 
problems if we're not consistent.
(3) Not 100% sure about the differences between Windows and Linux symlinks, and 
it's better to be safe than sorry.

Would love to hear from you if you think these are not good reasons, as I 
actually (in spite of how it may appear) basically have no idea what I'm doing.


- Alex


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


On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
> 
> (Updated Sept. 17, 2015, 10:03 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> A few third-party libraries (libev, gmock) do not have `make install`
> commands available, so below we have to add our own "install" commands.
> 
> The reason is: if we do not, we get runtime library load problems on OS
> X. In particular, `dydl` will look for these libraries at the prefix we
> passed to `configure` (or in `/usr/local` if we did not pass a prefix
> in), but since they don't have a `make install` step, they never get
> placed in the prefix folder.
> 
> Our solution is to:
>   (1) make a lib directory inside the Mesos folder for each of the
>   libraries that has no install step, and
>   (2) copy all such libraries into their respective directories.
> 
> (Note that step (1) is not only convenient, but important: make will add
> a `lib` to the end of your prefix path when linking, and since the built
> libraries end up in a `.libs` folder, it's not enough to simply pass the
> build directory into `configure` as a prefix; so if we're going to move
> the libraries, we might as well move them to a library folder.)
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/CMakeLists.txt 
> d13ba666740b4f2e382a0b1852724cfd519f8f64 
> 
> Diff: https://reviews.apache.org/r/38457/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Marco Massenzio]

> On Sept. 17, 2015, 4:44 p.m., Marco Massenzio wrote:
> > I'm excited about this!
> > Tested on OSX and (at least, as far as stout_tests go, it works, yay!)
> > 
> > A quick question: why, instead of moving the files, we don't simply add a 
> > symlink that will "look right" to the linker etc.
> > (this may be an exceedingly dumb question, due to my extremely limited 
> > understanding of the build system)
> > 
> > Thanks, Alex, for doing this - can't wait to bid farewell to CDT for good.
> 
> Alex Clemmer wrote:
> I don't know that there's a particular reason to _not_ use a symlink, but 
> the reasons I went with a hard copy are:
> 
> (1) It's not clear that it was easier or cleaner to symlink.
> (2) Every other install command does a hard copy and it might lead to 
> weird problems if we're not consistent.
> (3) Not 100% sure about the differences between Windows and Linux 
> symlinks, and it's better to be safe than sorry.
> 
> Would love to hear from you if you think these are not good reasons, as I 
> actually (in spite of how it may appear) basically have no idea what I'm 
> doing.

(1) it is probably "cleaner" to the extent you only have a copy of the actual 
files - everything else points to that "source of truth"
(while I type this, I realize that in the era of 5TB for < 100 bucks HDs, I 
sound like my great-granpa :)

(2) I have my own opinion about consistency... (I totally know you'll love it: 
I did when I was at G)
http://despair.com/collections/demotivators/products/consistency

(3) You're on your own there - I only found out Windows had symlinks last year 
(and I only found out because they didn't work the way one expected them to :)

In general, I prefer *soft* links (`ln -s`) in Linux as they are fast and 
inexpensive and easy to manage - copying files always leaves me with the worry 
the copies will go out of sync.

But #3 seems like a winner in the argument.

For now, I'd say, let's go with copies - let's get it to a "known good state" 
where it all works, then we can tinker with it to our heart's content later on 
and optimize it, if need be.

Thanks!


- Marco


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


On Sept. 20, 2015, 2:03 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
> 
> (Updated Sept. 20, 2015, 2:03 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Bugs: MESOS-3250
> https://issues.apache.org/jira/browse/MESOS-3250
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> A few third-party libraries (libev, gmock) do not have `make install`
> commands available, so below we have to add our own "install" commands.
> 
> The reason is: if we do not, we get runtime library load problems on OS
> X. In particular, `dydl` will look for these libraries at the prefix we
> passed to `configure` (or in `/usr/local` if we did not pass a prefix
> in), but since they don't have a `make install` step, they never get
> placed in the prefix folder.
> 
> Our solution is to:
>   (1) make a lib directory inside the Mesos folder for each of the
>   libraries that has no install step, and
>   (2) copy all such libraries into their respective directories.
> 
> (Note that step (1) is not only convenient, but important: make will add
> a `lib` to the end of your prefix path when linking, and since the built
> libraries end up in a `.libs` folder, it's not enough to simply pass the
> build directory into `configure` as a prefix; so if we're going to move
> the libraries, we might as well move them to a library folder.)
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/CMakeLists.txt 
> b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d 
> 
> Diff: https://reviews.apache.org/r/38457/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Re: Review Request 38528: Disable perf test when perf version is not support.

[haosdent huang]

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

(Updated Sept. 20, 2015, 2:49 a.m.)


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


Changes
---

Update error messsage.


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


Repository: mesos


Description
---

Disable perf test when perf version is not support.


Diffs (updated)
-

  src/tests/environment.cpp e40cde23daba25b0b61b567ee73682c67e7acbdc 

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


Testing
---

# On CentOS 6.6
sudo make -j8 check


Thanks,

haosdent huang

Re: Review Request 38528: Disable perf test when perf version is not support.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38528]

All tests passed.

- Mesos ReviewBot


On Sept. 20, 2015, 2:49 a.m., haosdent huang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38528/
> ---
> 
> (Updated Sept. 20, 2015, 2:49 a.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Michael Park.
> 
> 
> Bugs: MESOS-3471
> https://issues.apache.org/jira/browse/MESOS-3471
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Disable perf test when perf version is not support.
> 
> 
> Diffs
> -
> 
>   src/tests/environment.cpp e40cde23daba25b0b61b567ee73682c67e7acbdc 
> 
> Diff: https://reviews.apache.org/r/38528/diff/
> 
> 
> Testing
> ---
> 
> # On CentOS 6.6
> sudo make -j8 check
> 
> 
> Thanks,
> 
> haosdent huang
> 
>

Re: Review Request 38528: Disable perf test when perf version is not support.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38528]

All tests passed.

- Mesos ReviewBot


On Sept. 19, 2015, 7:30 p.m., haosdent huang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38528/
> ---
> 
> (Updated Sept. 19, 2015, 7:30 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Michael Park.
> 
> 
> Bugs: MESOS-3471
> https://issues.apache.org/jira/browse/MESOS-3471
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Disable perf test when perf version is not support.
> 
> 
> Diffs
> -
> 
>   src/tests/environment.cpp e40cde23daba25b0b61b567ee73682c67e7acbdc 
> 
> Diff: https://reviews.apache.org/r/38528/diff/
> 
> 
> Testing
> ---
> 
> # On CentOS 6.6
> sudo make -j8 check
> 
> 
> Thanks,
> 
> haosdent huang
> 
>

Re: Review Request 38531: CMake: Update CMake config to build Mesos against picojson v1.3.0.

[Alex Clemmer]

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

(Updated Sept. 20, 2015, 2:07 a.m.)


Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


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


Repository: mesos


Description
---

CMake: Update CMake config to build Mesos against picojson v1.3.0.


Diffs
-

  3rdparty/libprocess/cmake/ProcessConfigure.cmake 
a5f8d399e151acad87bb72ecb1f7372b2c467423 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Alex Clemmer]

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

(Updated Sept. 20, 2015, 1:25 a.m.)


Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


Repository: mesos


Description
---

A few third-party libraries (libev, gmock) do not have `make install`
commands available, so below we have to add our own "install" commands.

The reason is: if we do not, we get runtime library load problems on OS
X. In particular, `dydl` will look for these libraries at the prefix we
passed to `configure` (or in `/usr/local` if we did not pass a prefix
in), but since they don't have a `make install` step, they never get
placed in the prefix folder.

Our solution is to:
  (1) make a lib directory inside the Mesos folder for each of the
  libraries that has no install step, and
  (2) copy all such libraries into their respective directories.

(Note that step (1) is not only convenient, but important: make will add
a `lib` to the end of your prefix path when linking, and since the built
libraries end up in a `.libs` folder, it's not enough to simply pass the
build directory into `configure` as a prefix; so if we're going to move
the libraries, we might as well move them to a library folder.)


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/CMakeLists.txt 
b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d 

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


Testing
---


Thanks,

Alex Clemmer

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Alex Clemmer]

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

(Updated Sept. 20, 2015, 2:03 a.m.)


Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


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


Repository: mesos


Description
---

A few third-party libraries (libev, gmock) do not have `make install`
commands available, so below we have to add our own "install" commands.

The reason is: if we do not, we get runtime library load problems on OS
X. In particular, `dydl` will look for these libraries at the prefix we
passed to `configure` (or in `/usr/local` if we did not pass a prefix
in), but since they don't have a `make install` step, they never get
placed in the prefix folder.

Our solution is to:
  (1) make a lib directory inside the Mesos folder for each of the
  libraries that has no install step, and
  (2) copy all such libraries into their respective directories.

(Note that step (1) is not only convenient, but important: make will add
a `lib` to the end of your prefix path when linking, and since the built
libraries end up in a `.libs` folder, it's not enough to simply pass the
build directory into `configure` as a prefix; so if we're going to move
the libraries, we might as well move them to a library folder.)


Diffs
-

  3rdparty/libprocess/3rdparty/CMakeLists.txt 
b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d 

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


Testing
---


Thanks,

Alex Clemmer

Re: Review Request 38531: CMake: Update CMake config to build Mesos against picojson v1.3.0.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38456, 38457, 38529, 38530, 38531]

All tests passed.

- Mesos ReviewBot


On Sept. 20, 2015, 2:07 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38531/
> ---
> 
> (Updated Sept. 20, 2015, 2:07 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Bugs: MESOS-3345
> https://issues.apache.org/jira/browse/MESOS-3345
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> CMake: Update CMake config to build Mesos against picojson v1.3.0.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/cmake/ProcessConfigure.cmake 
> a5f8d399e151acad87bb72ecb1f7372b2c467423 
> 
> Diff: https://reviews.apache.org/r/38531/diff/
> 
> 
> Testing
> ---
> 
> Compiled and ran made sure libprocess and stout tests ran and passed on the 
> following platforms:
> 
> * OS X 10.10
> * Windows 10
> * Ubuntu 14.04.2
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Re: Review Request 38527: Fix UserCgroupIsolatorTest failed on CentOS 6.6.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38527]

All tests passed.

- Mesos ReviewBot


On Sept. 19, 2015, 7:23 p.m., haosdent huang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38527/
> ---
> 
> (Updated Sept. 19, 2015, 7:23 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Michael Park.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fix UserCgroupIsolatorTest failed on CentOS 6.6.
> 
> 
> Diffs
> -
> 
>   src/tests/containerizer/isolator_tests.cpp 
> a25ae97a519feb8ead6177da160df8a276ca15bf 
> 
> Diff: https://reviews.apache.org/r/38527/diff/
> 
> 
> Testing
> ---
> 
> sudo ./bin/mesos-tests.sh --gtest_filter="UserCgroupIsolatorTest*" --verbose
> 
> 
> Thanks,
> 
> haosdent huang
> 
>

Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.

[Alex Clemmer]

> On Sept. 18, 2015, 9:10 p.m., Joseph Wu wrote:
> > You should consider adding a CMake macro to make this more maintainable.
> > 
> > A macro that does something like:
> > ```
> > mkdir -p ${INPUT_SRC}-lib/lib 
> > && cp -r ${INPUT_SRC}-build/lib/.libs/. ${INPUT_SRC}-lib/lib
> > ```

I actually think we shoudl re-evaluate whether to do this later. The commands 
generated are different enough between libev and gmock that it's not clear we 
gain anything by having a macro or function expand this out.


- Alex


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


On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
> 
> (Updated Sept. 17, 2015, 10:03 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> A few third-party libraries (libev, gmock) do not have `make install`
> commands available, so below we have to add our own "install" commands.
> 
> The reason is: if we do not, we get runtime library load problems on OS
> X. In particular, `dydl` will look for these libraries at the prefix we
> passed to `configure` (or in `/usr/local` if we did not pass a prefix
> in), but since they don't have a `make install` step, they never get
> placed in the prefix folder.
> 
> Our solution is to:
>   (1) make a lib directory inside the Mesos folder for each of the
>   libraries that has no install step, and
>   (2) copy all such libraries into their respective directories.
> 
> (Note that step (1) is not only convenient, but important: make will add
> a `lib` to the end of your prefix path when linking, and since the built
> libraries end up in a `.libs` folder, it's not enough to simply pass the
> build directory into `configure` as a prefix; so if we're going to move
> the libraries, we might as well move them to a library folder.)
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/CMakeLists.txt 
> d13ba666740b4f2e382a0b1852724cfd519f8f64 
> 
> Diff: https://reviews.apache.org/r/38457/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Review Request 38527: Fix UserCgroupIsolatorTest failed on CentOS 6.6.

[haosdent huang]

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

Review request for mesos.


Repository: mesos


Description
---

Fix UserCgroupIsolatorTest failed on CentOS 6.6.


Diffs
-

  src/tests/containerizer/isolator_tests.cpp 
a25ae97a519feb8ead6177da160df8a276ca15bf 

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


Testing
---

sudo ./bin/mesos-tests.sh --gtest_filter="UserCgroupIsolatorTest*" --verbose


Thanks,

haosdent huang

Re: Review Request 38246: Added propagation of Resources and Unavailability from the InverseOffer protobuf to the allocator.

[Joris Van Remoortere]

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

Ship it!



include/mesos/master/allocator.hpp (line 156)


Let's clarify why unavailableResources is added here.



include/mesos/master/allocator.hpp (line 160)


typo


- Joris Van Remoortere


On Sept. 18, 2015, 10:55 p.m., Artem Harutyunyan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38246/
> ---
> 
> (Updated Sept. 18, 2015, 10:55 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Joris Van Remoortere, and Joseph 
> Wu.
> 
> 
> Bugs: MESOS-3346
> https://issues.apache.org/jira/browse/MESOS-3346
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   include/mesos/master/allocator.hpp fb09e2a6502bc8c78ddcc8a595bcd9320da136ea 
>   src/master/allocator/mesos/allocator.hpp 
> 171548b2017a0b97124f052c21345668e274d117 
>   src/master/allocator/mesos/hierarchical.hpp 
> 3374d63b8311cf10b3108f56b7b167c12a9d7a37 
>   src/master/master.cpp 1c4e7af7448c05f54c1068d6496ed21c8c359ac5 
>   src/tests/mesos.hpp 3db97aca921c9216d90384e1eb17030849516454 
> 
> Diff: https://reviews.apache.org/r/38246/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Artem Harutyunyan
> 
>

Review Request 38529: CMake: Only compile proc_tests.cpp for Linux platforms.

[Alex Clemmer]

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

Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


Repository: mesos


Description
---

CMake: Only compile proc_tests.cpp for Linux platforms.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/tests/CMakeLists.txt 
baa648aacfd5204c33e102b58126862729fbb612 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Review Request 38531: CMake: Update CMake config to build Mesos against picojson v1.3.0.

[Alex Clemmer]

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

Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


Repository: mesos


Description
---

CMake: Update CMake config to build Mesos against picojson v1.3.0.


Diffs
-

  3rdparty/libprocess/cmake/ProcessConfigure.cmake 
a5f8d399e151acad87bb72ecb1f7372b2c467423 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Review Request 38530: CMake: Add preprocessor definitions required to build picojson 1.3.0.

[Alex Clemmer]

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

Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph 
Wu.


Repository: mesos


Description
---

CMake: Add preprocessor definitions required to build picojson 1.3.0.


Diffs
-

  cmake/MesosConfigure.cmake b530da4c1e6f202b682ad7d6892da95d2181f8c8 

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


Testing
---

Compiled and ran made sure libprocess and stout tests ran and passed on the 
following platforms:

* OS X 10.10
* Windows 10
* Ubuntu 14.04.2


Thanks,

Alex Clemmer

Review Request 38532: Add error message when cgroup don't support memory.pressure_level.

[haosdent huang]

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

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


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


Repository: mesos


Description
---

Add error message when cgroup don't support memory.pressure_level.


Diffs
-

  src/tests/containerizer/cgroups_tests.cpp 
75a3bc0009c037dc18ce319db2eb44630f083e8c 

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


Testing
---


Thanks,

haosdent huang

Re: Review Request 38251: FrameworkInfo should only be updated if the re-registration is valid

[Joris Van Remoortere]

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

Ship it!


Refactored a little as per Anand's suggestion.

- Joris Van Remoortere


On Sept. 14, 2015, 2:19 a.m., Guangya Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38251/
> ---
> 
> (Updated Sept. 14, 2015, 2:19 a.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere and Vinod Kone.
> 
> 
> Bugs: MESOS-3169
> https://issues.apache.org/jira/browse/MESOS-3169
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> FrameworkInfo should only be updated if the re-registration is valid
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp 4b60e637b19e749e27c4a8eb9b0a95c7e9305c5f 
> 
> Diff: https://reviews.apache.org/r/38251/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Guangya Liu
> 
>

Re: Review Request 38475: Maintenance Primitives: Add test for inverse offer filters.

[Joseph Wu]

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

(Updated Sept. 19, 2015, 6:14 p.m.)


Review request for mesos, Artem Harutyunyan and Joris Van Remoortere.


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


Repository: mesos


Description
---

Checks that filters change which inverse offer is sent when.


Diffs
-

  src/tests/master_maintenance_tests.cpp 
9892bc329ff850f638e9f5e79d047efaf2fcb037 

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


Testing
---

`make check`


Thanks,

Joseph Wu

Re: Review Request 38519: Change function quiesce() to suppressRes()

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38514, 38516, 38519]

All tests passed.

- Mesos ReviewBot


On Sept. 19, 2015, 1:26 a.m., Guangya Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38519/
> ---
> 
> (Updated Sept. 19, 2015, 1:26 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-3037
> https://issues.apache.org/jira/browse/MESOS-3037
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The reason that I was not using suppress() is because suppress is
> already defined in
> 3rdparty/libprocess/3rdparty/stout/include/stout/os/signals.hpp
> 
> 
> Diffs
> -
> 
>   src/master/http.cpp 7cca8b1d3118fe99de79cfaf5360825012d830da 
>   src/master/master.hpp 6805177d7c03b701708e1d217a7bc0ac7c79889e 
>   src/master/master.cpp 64e5fb9e27b2e6797b2ce87c0e1a3ef8a2943e27 
> 
> Diff: https://reviews.apache.org/r/38519/diff/
> 
> 
> Testing
> ---
> 
> Platform: Ubuntu:14.04
> make
> make check
> 
> 
> Thanks,
> 
> Guangya Liu
> 
>

Re: Review Request 37585: Maintenance primitives: Add a user doc.

[Mesos ReviewBot]

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


Bad patch!

Reviews applied: [37585]

Failed command: ./support/apply-review.sh -n -r 37585

Error:
 2015-09-19 06:46:30 URL:https://reviews.apache.org/r/37585/diff/raw/ 
[13712/13712] -> "37585.patch" [1]
error: missing binary patch data for 
'docs/images/maintenance-primitives-modes.png'
error: binary patch does not apply to 
'docs/images/maintenance-primitives-modes.png'
error: docs/images/maintenance-primitives-modes.png: patch does not apply
Failed to apply patch

- Mesos ReviewBot


On Sept. 19, 2015, 1:27 a.m., Joseph Wu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37585/
> ---
> 
> (Updated Sept. 19, 2015, 1:27 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Artem Harutyunyan, 
> Joris Van Remoortere, and Vinod Kone.
> 
> 
> Bugs: MESOS-2083
> https://issues.apache.org/jira/browse/MESOS-2083
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Heavily based on the design doc 
> (https://docs.google.com/document/d/16k0lVwpSGVOyxPSyXKmGC-gbNmRlisNEe4p-fAUSojk/).
> 
> Includes a diagram of the maintenance mode transitions.
> 
> 
> Diffs
> -
> 
>   docs/images/maintenance-primitives-modes.png PRE-CREATION 
>   docs/maintenance.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/37585/diff/
> 
> 
> Testing
> ---
> 
> Copied to: https://gist.github.com/kaysoky/b9789c88ee204e3b49a2
> Checked for markdown correctness.
> 
> 
> File Attachments
> 
> 
> Same as the image in the binary diff. (Uploaded for reviewer convenience.)
>   
> https://reviews.apache.org/media/uploaded/files/2015/09/01/7d3153ca-37f4-4948-acce-b140a3eb71a9__maintenance-primitives-modes.png
> 
> 
> Thanks,
> 
> Joseph Wu
> 
>

Re: Review Request 38473: Add flag to disable hostname lookup.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [38473]

All tests passed.

- Mesos ReviewBot


On Sept. 19, 2015, 1:25 a.m., Marco Massenzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38473/
> ---
> 
> (Updated Sept. 19, 2015, 1:25 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Cody Maloney, and Neil Conway.
> 
> 
> Bugs: MESOS-3457
> https://issues.apache.org/jira/browse/MESOS-3457
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Under certain circumstances, dynamic lookup of hostname, while
> successful, provides undesirable results; we would also like, in
> those circumstances, be able to just set the hostname to the chosen
> IP address (possibly set via the --ip_discovery_command method).
> 
> The flag we add here, --[no]-hostname_lookup is `true` by default
> (which is the existing behavior) and will work under most
> circumstances: however, by disabling lookup (using, for example,
> --no_hostname_lookup) the hostname used will be the same as the
> one configured (possibly, via --ip or MESOS_IP) in `LIBPROCESS_IP`.
> 
> This change affects both Master/Agent nodes.
> 
> WARNING - the `Address::hostname()` method always does a dynamic
> hostname lookup, which may in fact return inconsistent results
> wrt the Master's configuration (this is *not* affected by
> this change) and should be avoided; use instead
> `Master::info()::hostname()` which is always consistent with
> the Master's configuration.
> 
> 
> Diffs
> -
> 
>   docs/configuration.md dd7f4aa806a3c1a8653a0fda9a326a3707308e7c 
>   src/master/flags.hpp e4b1df3f5a33049defff4688463274067f1f1ebf 
>   src/master/flags.cpp 80879611fbcfd764c9fc8f60a31613a9c8fc2364 
>   src/master/master.cpp ca4d5876dcd427964111428edc22d567ddaede0b 
>   src/slave/flags.hpp e31a4183170c3442ac4a15365c229391e7e91480 
>   src/slave/flags.cpp add4196dfd06c0f602ff5ebd39960dc05c4cd11f 
>   src/slave/slave.cpp ad710d7b930a2f115d503ceb8f8fd7421ad30287 
>   src/tests/cluster.hpp 114583de8c867495a2b7a953e6826708838e5d23 
>   src/tests/master_tests.cpp a477794df37c658b80d79dea8555b001415f7b6a 
>   src/tests/mesos.hpp 3db97aca921c9216d90384e1eb17030849516454 
> 
> Diff: https://reviews.apache.org/r/38473/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>