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


Looks very close! Just some minor nits and suggested rewordings, plus a request 
to better document/test the behavior for inexact matches (substrings/wildcards).


3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137769>

    FirewallRule shouldn't know what happens when apply() returns false. That's 
up to the caller. Maybe a future caller wants to redirect instead of reject/403.
    Leave this part of the comment in the specific caller or a 
docs/firewall.md, and just explain what the @return value means from the 
context of FirewallRule and a generic caller.



3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137770>

    Again, you're describing the caller's behavior, not this function's 
behavior and how its results should be interpreted.



3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137767>

    Please capitalize "The" beginning of each @param description.



3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137778>

    Why not return a Try? Then the rule has the option of providing an error 
message, and the caller will read like:
    Try<Nothing> applied = rule->apply();
    if(applied.isError()) {
      LOG << applied.error();
    }



3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137771>

    "Simple firewall rule to reject any connection requesting a path [exactly 
matchine one] in the provided list of disabled endpoints."



3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137772>

    Would be good to document that this is an exact match only, so it does not 
match substrings or wildcards. For example, if `/files` or `/files/*` is 
disabled, connections to `/files/browse.json` will still be allowed through.



3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137773>

    s/will be test/will be tested/



3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137774>

    s/the appear/they appear/



3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137775>

    "@param rules The list of firewall rules which will be applied to incoming 
connections."



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/33295/#comment137776>

    s/rule/rules/



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/33295/#comment137779>

    Looks like this code is duplicated a few times now. Any chance you can 
dedupe it?



3rdparty/libprocess/src/tests/process_tests.cpp
<https://reviews.apache.org/r/33295/#comment137780>

    Why the default "id" value? All your callers already specify a processId.



3rdparty/libprocess/src/tests/process_tests.cpp
<https://reviews.apache.org/r/33295/#comment137781>

    Would like to see a test for nested endpoints, and maybe even wildcards, so 
that it's clear whether or not those work.


- Adam B


On May 26, 2015, 1:22 a.m., Alexander Rojas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33295/
> -----------------------------------------------------------
> 
> (Updated May 26, 2015, 1:22 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Bugs: MESOS-2620
>     https://issues.apache.org/jira/browse/MESOS-2620
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Introduces the interface `FirewallRule` which will be matched against 
> incoming connections in order to allow them to be served or being blocked. 
> For details, check the [design 
> doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/Makefile.am 
> 8aab0593f296c7aae71289f9bd6cf3eb3578a721 
>   3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/process.hpp 
> 392c74df3e8a122aecd3633dffdeec4bcbd1f097 
>   3rdparty/libprocess/src/process.cpp 
> e3de3cd6b536aaaf59784360aed546512dd04dc9 
>   3rdparty/libprocess/src/tests/process_tests.cpp 
> 67e582cc250a9767a389e2bd0cc68985477f3ffb 
> 
> Diff: https://reviews.apache.org/r/33295/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Reply via email to