mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Review Request 63652: Added d_type check in containerizer backend validation.
Date Fri, 10 Nov 2017 17:07:59 GMT

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




src/slave/containerizer/mesos/provisioner/provisioner.cpp
Lines 126 (patched)
<https://reviews.apache.org/r/63652/#comment268345>

    I think we can just always perform this test. Is it not XFS-specific and all filesystems
using `overlayfs` are required to have `d_type` support.



src/slave/containerizer/mesos/provisioner/provisioner.cpp
Lines 134 (patched)
<https://reviews.apache.org/r/63652/#comment268344>

    You don't need to make a temporary directory, you can use the one you already have (i.e.
the `.` entry should be `DT_DIR`).
    
    I'm assuming that filesystems won't fake up special cases for `.` and `..`; is that true?



src/slave/containerizer/mesos/provisioner/provisioner.cpp
Lines 150 (patched)
<https://reviews.apache.org/r/63652/#comment268348>

    Always add brances and propagate the error:
    ```
    if (supportDType.isError()) {
      return Error("Cannot verify filesystem attributes: " + supported.message);
    }
    
    ```



src/slave/containerizer/mesos/provisioner/provisioner.cpp
Lines 153 (patched)
<https://reviews.apache.org/r/63652/#comment268346>

    ```
    Error error(....);
    LOG(WARNING) << error.message;
    return error;
    ```



src/slave/containerizer/mesos/provisioner/utils.hpp
Lines 33 (patched)
<https://reviews.apache.org/r/63652/#comment268349>

    Since this is a general utility, I'd say it belongs in `src/linux/fs.hpp`. Please also
add a brief header comment describing its purpose.



src/slave/containerizer/mesos/provisioner/utils.cpp
Lines 30 (patched)
<https://reviews.apache.org/r/63652/#comment268341>

    You don't need this header here.



src/slave/containerizer/mesos/provisioner/utils.cpp
Lines 141 (patched)
<https://reviews.apache.org/r/63652/#comment268342>

    I'd prefer if you explicitly scoped the libc APIs to make it very clear to the reader
that you are not expecting similarly-named stout APIs.
    
    i.e. `::opendir`, `::closedir`, `::readdir`.



src/slave/containerizer/mesos/provisioner/utils.cpp
Lines 144 (patched)
<https://reviews.apache.org/r/63652/#comment268343>

    Let's make all these error messages consistent:
    
    Failed to open 'foo'
    Failed to read 'foo'
    Failed to close 'foo'


- James Peach


On Nov. 10, 2017, 1:07 a.m., Meng Zhu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63652/
> -----------------------------------------------------------
> 
> (Updated Nov. 10, 2017, 1:07 a.m.)
> 
> 
> Review request for mesos, Gilbert Song and James Peach.
> 
> 
> Bugs: MESOS-8121
>     https://issues.apache.org/jira/browse/MESOS-8121
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> In unified containerizer, the d_type cannot be 1
> if we are using the overlay fs backend.
> In particular, XFS can be mounted with ftype = 0
> which renders d_type == 0. Raise error if user
> specifies overlayfs as backend. Fallback to other
> backends in the default case and raise a warning.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/mesos/provisioner/provisioner.cpp 450a3b32d69d2882973a6ed4e94e169a0256056b

>   src/slave/containerizer/mesos/provisioner/utils.hpp 5b6c162fe4ade16131b2207d707e76228b0ec51a

>   src/slave/containerizer/mesos/provisioner/utils.cpp 7fd7315dda99f49f967a665afe27c8db7835c04c

> 
> 
> Diff: https://reviews.apache.org/r/63652/diff/2/
> 
> 
> Testing
> -------
> 
> Manually tested slave creation with default and overlayfs backends on XFS based work_dir
with different ftype mount options.
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message