document OCI-mode SCIF support

[preminger]

Description of the Pull Request (PR):

This PR documents the support for SCIF in OCI-mode added in sylabs/singularity#2348

[preminger]

Hey @vsoch —

If you have the time / bandwidth / energy & feel like it, we'd be super grateful to get any feedback on this that you might have. Thx in advance!

[vsoch]

It looks good! So what is the relation to OCI, just that you are putting the different SCIF install commands in different layers?

[preminger]

It looks good! So what is the relation to OCI, just that you are putting the different SCIF install commands in different layers?

So, until now, we only supported SCIF in native mode. Which, as you know, meant that as part of the build process from .def file to SIF image, the installation of the various apps (based on the %app* sections in the .def file) would be performed, and therefore adding --app <appname> to a Singularity run / exec / shell command line would enable you to interact directly with individual SCIF apps.

In OCI mode, however, we're running a proper OCI container, using a low-level OCI runtime (crun or runc) under the hood. At present, OCI images must either be pulled directly from a repository, or else built straight from Dockerfile using the functionality that was added in sylabs/singularity#2280 and which will be included in the upcoming v4.1 release.

ETA: There is actually support for running native SIF files in OCI mode with some compatibility restrictions - see here - but interacting with SCIF when using this flow would still require an OCI-mode / Docker-like SCIF container, i.e., one that runs a scif executable by default.

Because Dockerfile syntax doesn't include any particular provisions for %app* sections, we can't use the same strategy for integrating SCIF that we used in native mode. After poking around in the documentation in https://sci-f.github.io/, we decided that the best way to hook our OCI-mode up with SCIF was to mimic what you discuss there for using SCIF with Docker - namely, assuming a container with a scif executable as its CMD / ENTRYPOINT, and hooking up the behavior of singularity {run / exec / shell} --oci --app <appname> <container> to that.

So the relation to OCI is:

1. The build flow & the nature of the resulting container.
2. The nature of the runtime being used (native vs. OCI-mode, the latter built atop crun/runc).

This then enables you to capitalize on Singularity functionality that only works in OCI-mode, and use it in tandem with SCIF (which would not have been possible until sylabs/singularity#2348). One example of such functionality is our support for CDI device mapping, added in sylabs/singularity#1459.

---

I hope this answers your question, though I'm not 100% sure I understood it correctly, so please feel free to follow up & I'll do my best to provide a better answer!

[vsoch]

No that's great! Thanks @preminger.

[dtrudg]

LGTM