We are the authors of Charliecloud, a competing container solution, as well as the tech report describing it (here, citation 30).

The purpose of this comment is to address several errors about Charliecloud in this article. We would have preferred to do so informally while the article was in preparation, but we did not learn about it until after publication. Below, we list the most important errors that we identified and provide brief correction. Interested readers can follow up in our tech report, documentation, and the Charliecloud source code.

1. — Support for “current production Linux distros” (Table 1, p. 4; p. 6). Charliecloud is targeted to user namespaces, which are already available in many distributions, including Fedora starting with version 21 (released 2014-12-09), SLES 12.1 (2015-12-22), and Ubuntu 16.04 (2016-04-21). They are in RHEL 7.2 (2015-11-19) as a “tech preview”; Los Alamos already runs Charliecloud on a RHEL derivative and CentOS by installing a newer kernel.

We anticipate broader availability in the near future. For example, Red Hat’s roadmap for RHEL, presented at Red Hat Summit 2017, suggests that user namespaces will be fully supported in 7.4 [1].

Subsequent to publication of this article, we added a setuid mode to Charliecloud to allow evaluation on kernels that do not support user namespaces.

2. — “Table 1 has been extended and adopted [sic] from” our tech report (p. 4). We’re pleased to see our work being built upon, but we believe simply “adapted” is a better descriptor for this table, omitting “extended”, because several columns and rows in our table are not present here. The omitted rows we believe are most important, all of which we assessed “no” for Singularity, are industry-standard image build, no root operations on center resources, and no cache, configuration or other state. This evidence shows that Singularity does not provide a superset of Charliecloud’s features, in contrast to Table 1’s implication.

3. — Support for GPUs (Table 1, p. 4). The table implies that Charliecloud does not support GPUs. This is not true; GPUs work fine if users include the appropriate libraries in their container image.

4. — “Designed for general scientific use cases” (Table 1, p. 4). As the requirements described in our tech report show, Charliecloud is designed specifically for scientific computing.

5. — Permissions of container environment (Table 1, p. 4; p. 6). It is unclear what this claim means. By default, Charliecloud uses the same UID and primary GID inside the container as outside; the user can select a different UID/GID mapping if they wish, and access is still controlled by the native, outside-container UID/GID. Accessing files via supplementary groups will require such a selection.

6. — Portability and modifiability of container images (Table 1, p. 4; p. 6). Charliecloud’s tarball container images can be used on any machine provided they include libraries appropriate for the hardware, the same as Singularity. Charliecloud mounts images read-only; they are not modified by use. Images are not “configured” by the C runtime (ch-run) or any other part of post-Docker workflow, just moved around and/or unpacked.

7. — “Admins can control and limit capabilities” (Table 1, p. 4). Again, this criticism is unclear to us. Because Charliecloud leverages user namespaces, processes in a container have exactly the same access to files, network, devices, and other resources as any other process owned by the same user. Thus, existing methods to define that access still apply.

8. — Lines of code and “user-driven features” (p. 6). Charliecloud is designed to be parsimonious, in keeping with the UNIX philosophy to “make each program do one thing well”, avoiding feature creep and bloat. We do, however, emphasize usability and regularly add features in response to user demand; the setuid evaluation mode is an example.

In summary, we believe that competition is good, and we are glad to see multiple options for containers in HPC. We also believe that this competition should happen based on technical merit, and so we appreciate the opportunity to correct the record about Charliecloud.

Reid Priedhorsky
Tim Randles
High Performance Computing Division
Los Alamos National Laboratory

[1]: https://rh2017.smartevent...