Document what is missing

[davidchisnall]

It would be great to have a to-do list that people who want to contribute can look at and see what still needs doing. I am not sure that I fully understand the separation of concerns between containerd and runj, so I don't know if things are missing from runj because containerd implements them or if they still need doing.

[samuelkarp]

My initial plan was to open issues for the things that needed work done and mark whether I had planned to do them myself or wanted help, but I seem to have not done that yet so here's a list off the top of my head:

• Anything that isn't Linux-specific (including things that are nominally in the Linux-related structs but could be made to work on FreeBSD) in https://github.com/opencontainers/runtime-spec/blob/ab23082b188344f6fbb63a441ea00ffc2852d06d/specs-go/config.go. This includes things like:
  • Hooks
  • Annotations
  • Current working directory
  • User
  • Read-only rootfs
  • Basic network isolation
• Anything that FreeBSD jails can do that should be modeled in the OCI spec. This includes things like:
  • racct/rctl support (https://github.com/samuelkarp/runj/issues/8)
• Things that might be useful that leverage some composition to get done:
  • Configuring network routing (but this should possibly be in a CNI plugin)
  • Configuring network sharing between jails (I believe nested jails may be able to accomplish this? runj could grow support for transparently dealing with nested jails or for specifying a parent jail in the OCI bundle?)

I do still want to do a bunch of this work myself; I've just struggled to find the free time to work on runj over the past several months. Per the contribution policy, if you're interested in working on something please create an issue describing what you'd like to do first so we can talk about it (and I can decide whether I'd like help on that front).

Happy to discuss more here if anything is unclear.

[davidchisnall]

Thanks. I'm interested (time permitting) in working on some of the network integration (vnet + pf). Pot already seems to manage this reasonably well, so should provide a good reference. I don't have a very good understanding of how the various bits (containerd / runj / CNI) fit together (all of the docs seem to assume that you know everything already and throw terminology at you).

You shouldn't need nested jails for jail-to-jail networking, you 'just' need to set up the routing.

[gizahNL]

Thanks. I'm interested (time permitting) in working on some of the network integration (vnet + pf). Pot already seems to manage this reasonably well, so should provide a good reference. I don't have a very good understanding of how the various bits (containerd / runj / CNI) fit together (all of the docs seem to assume that you know everything already and throw terminology at you).

You shouldn't need nested jails for jail-to-jail networking, you 'just' need to set up the routing.

You could take a look at my moby port. It has (barebones) working network and barebones pf support.

The strategy I used is creating a base jail that allows for a child jail to be spawned that does the vnet network, and a child jail that is the actual container. The rationale being that Linux containers lack the tools to configure the FreeBSD network stack, and Kubernetes pods assuming a shared network namespace.

I still have a PR open here that needs more work on it, but unfortunately I've been swamped with other commitments.

[samuelkarp]

I've opened https://github.com/samuelkarp/runj/issues/20 to specifically cover networking and leave this issue open for its original purpose.