Nix ❤ OCI - and vice versa?

Development
1

Hey!

I want to share an idea that I’ve been playing with for some time now.

To me it looks like the ideal stepping stone to pave the way for mass adoption of nix: marry the nix and container ecosystems.

Therefore, I decided to reach out to the container folks and ask for guidance on how to include nix principles into the OCI specification. In that, I think I could need some guidance, help and maybe even “rallying-behind-the-flag”-support.

For now, I just share the upstream issue here:

https://github.com/opencontainers/image-spec/issues/922

Last time a similar issue resulted in the creation of builtkit-nix. So why not give it a try? :blush:

5 Likes
2

You should to the Tvix people who have worked on trying to do derivation sandboxing in some OCI-standard way.

1 Like
3

This makes me think that we might actually benefit from defining our own Artifacts. Something like application/vnd.nix.packge....

Sylabs has done it with SIF (Singularity Project).

4

I think defining artifacts is on-scope anyway as this upstream question on the issue indicates (which I assume refers to OCI Artifact manifests):

Is there a manifest definition for using these blobs? I’m curious if it’s one manifest per blob, or if you are taking them as a group.

I don’t quite know what to anser to this quedtion, though:

But +gzip might not be reproducible, right?
We probably want to have a reproducible compression format before bringing NAR into OCI.

Maybe there is a requirement that the “transported” artifact is hashed and not the unpacked one?

My (incomplete) understanding was that cache could serve gziped content at will and that the nix client would be able to deal with it.

5

For the purpose of sandboxing builds OCI images are completely irrelevant. We are only concerned with the runtime spec.

6

I had a seat in the OCI weekly and I think we came up with a pretty clean design for a first iteration.

This would still depend on somewhat if a custom implementation of a registry and an initial patchset to containerd.

If input-adressability turns out to be a problem, then maybe the registry implementation needs to cheat (and calculate the content hash on the fly) until CA has wide enough adoption.

4 Likes
7

OCI Weekly Discussion

… from the:

Nov 17, 2022

Attendees

  • John Ericsson (Nix Community / Obsidian Systems)
  • David Arnold (Nix Community / IOHK)
  • Brandon Mitchell
  • Ramkumar Chinchani (zot/Cisco)
  • Brandon Klein (SNL)

Note Taker:

  • add note taker

Actionable Agenda Items:

  • Who’s taking notes?
  • add your items

Presentation/Discussion Agenda Items:

  • Ways to bring the Nix ecosystem closer to OCI
    • Maybe a new “non-conflicting” layer type?
    • Could work for other, too: eg. Guix

Notes:

  • Nix/Guix “layers”
    • Non-conflicting (disjoint mount points)
    • Immutable
    • Need to support numerous tiny images, no artificial limits.
    • Nix/Guix ideomatic usage
      • No “base image”
        • Turtles all the way down!
    • Read-only paths can be done with https://github.com/opencontainers/runtime-spec/blob/494a5a6aca782455c0fbfc35af8e12f04e98a55e/config-linux.md#readonly-paths
    • Jon Johnson: Seems like two things to consider:
      1. How to represent these images (image-spec)
      2. How to unpack these differently from overlay (runtime-spec)
    • Tianon Gravi: runtime-spec doesn’t specify unpacking though, that’s runtime-specific (runtime-spec just specifies “rootfs” and it’s implementation defined how to create that from an image) O:)
    • Nisha Kumar: The problem with regarding to running a /store like rootfs is putting the right binary in the right place such that the container runtime can find it
    • Brandon Mitchell: I’m wondering if the implementation could be as easy as an annotation that indicates the name of the non-conflicting path, which has the potential to be backwards compatible.
      • John Ericson: Sounds great!!
1 Like