Process for reviewing classic confinement snaps

[nuccitheboss]

@jdstrand

HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves). Note: many HPC/orchestration applications can run with strict confinement and classic should only be granted if snapd does not support the specific use case (eg, the need for user accounting ).

This section is a bit confusing/overly condensed by parenthesis for me. It gives me the idea that HPC software qualifies for classic confinement, but only very specific HPC software that folks may or not be familiar with the internals of. A frequent challenge with High-Performance Computing software applications is that clusters typically have arbitrary directory structure; they don’t follow the Linux Filesystem Hierarchy. This isn’t modeled nicely by snapd/AppArmor. I can use the system-files interface, but now I have a “boil the ocean” problem where I need to add a declaration for every possible mount/file system setup that my users have.

I propose that we make the above clause simpler so that it’s more clear for what kind of HPC/orchestration software falls into this category. Let me know what you think of my attempt here:

Supercomputing software or orchestration agents that execute workloads on systems where the system itself is managed by an external application outside the control of the software/agent; the supercomuting software/orchestration agent simply manages the workloads running on the system, not the system itself.

• Note: It is possible to strictly confine supercomputing software and orchestration agents. You should first attempt to strictly confine your application before requesting classic confinement. Classic confinement will only be granted if snapd does not support a specific use case such as dropping privileges to become a specific uid/gid on the system, or the application requires read/write access to files and directories outside the Linux Filesystem Hierarchy Standard to function as end-users would expect it to.

A couple notes about my proposed revision:

1. I replaced HPC with supercomputing. Not everyone is familiar with the HPC acronym, especially if you don’t work in the industry or directly work with supercomputers. I think supercomputer paints a better picture of ‘this isn’t your typical consumer-grade device’.
2. I removed the reference to the thread need for user accounting. That thread is quite dense and there is not a clear resolution that can be easily pointed to as an example of why Slurm was granted classic confinement. There’s a lot of back and forth which makes the justification for why Slurm was granted classic confinement but maybe not other HPC applications opaque.
3. I added a blurb about the Filesystem Hierarchy Standard. Almost every HPC workflow management application requires access to directories located outside of the /home/<usr> directory. HPC applications will typically be chucked into a file system location like /opt or other location, create user-specific configurations under home, and then access various kinds of mounted file systems such as NFS, Lustre, Ceph, etc.

Welcome to feedback on this!