[bboreham]

> given CNI which touches some deep bits of runc's particular behaviour

Could you explain? I’m a maintainer of CNI and I know almost nothing about runc, so I’m not clear where they touch.

The first CNI implementation came out of rkt, pre-dating runc by a year or two.

[cyphar]

I mean that it likely makes certain assumptions about how runc sets up containers which aren't true of LXC. I'm sure you could get CNI to work with LXC (in fact, someone might've already done that -- I'm not sure tbh) but it wouldn't be something you'd be able to drop-in without at least a bit of extra work. For instance, LXC's hooks run in different contexts to OCI hooks (though we recently discovered that runc runs hooks in different contexts to the OCI spec, but that's another topic).

And historically, yes it might predate the runc binary but the libcontainer code that is now part of runc predated CNI -- and all of our fun idiosyncrasies are in libcontainer.

[bboreham]

> likely makes certain assumptions about how runc sets up containers

Nope. CNI takes as parameters a “container ID” (any string) and a network namespace path. No knowledge is needed or implied about how those things fit with actual containers.

[cyphar]

There are some circumstances where that might not work as seamlessly as possible (such as with user namespaces -- runc and LXC set those up slightly differently and run hooks in slightly different orders and contexts) but it wouldn't be too hard to get it to work. I did a quick search, and it turns out that making CNI work under LXC did require some patches (though I'm not sure if they were CNI or LXC patches -- the blog post doesn't link to either) but they were all merged a bit less than 2 years ago[1].

[1]: https://s3hh.wordpress.com/2017/10/19/cni-for-lxc/