search

opencontainers / runc

CLI tool for spawning and running containers according to the OCI specification
https://www.opencontainers.org/
Apache License 2.0
11.76k stars 2.09k forks source link

[post 1.0] RFC: separate out libcontainer/cgroups, maybe merge with containerd/cgroups #3007

Open kolyshkin opened 3 years ago

kolyshkin commented 3 years ago

Despite the warnings we have, libcontainer is used by lots of other projects, like kubernetes, cri-o etc. One particular piece is libcontainer/cgroups.

I think we should separate libcontainer/cgroups out to say opencontainers/cgroups, and possibly merge with containerd/cgroups (which from the first glance has better API but probably not as practical implementation esp for cgroup v2). Maybe the way to go is

  1. move containerd/cgroups under opencontainers
  2. port all the good parts of libcontainer/cgroups to the new opencontainers/cgroups
  3. adopt runc and other users of libcontainer/cgroups to the new opencontainers/cgroups

This is a big and potentially disruptive project but it should clear things up a lot, resulting in better code, clearer APIs, and less effort duplication.

(Ultimately, all of libcontainer should either be separated out or moved into internal, but this is a larger goal)

WDYT @opencontainers/runc-maintainers @crosbymichael @thaJeztah @estesp @dmcgowan

mrunalp commented 3 years ago

:+1:

thaJeztah commented 3 years ago

Definitely 👍. I don't see benefit in multiple projects maintaining code for handling this, so if we can share the effort in maintaining it, would (IMO) benefit everyone. Handling cgroups is already "hairy" (with lots of oddities). Happy to help with this (even if only to "chop wood / carry water")

AkihiroSuda commented 3 years ago

Separating out the go module might be fine, but separating the repo will cause "vendoring hell", so I still prefer monorepo

thaJeztah commented 3 years ago

@AkihiroSuda any specific repositories where you think this would become vendoring hell? (Thinking of circular dependencies). Of course, the repo would need to try to stick to SemVer(isn) (no breaking changes).

AkihiroSuda commented 3 years ago

The repo of runc and libct/cgroups themselves will face issues, as testing runc requires libct/cgroups and vice versa.

For similar reason, we merged back libnetwork into Moby.

cyphar commented 3 years ago

Alternatively we can just move all of libcontainer into an internal package (which Go won't let you import) and we just leave libcontainer/cgroups in an importable path. I had planned to do something like this for a while. Same goes with libcontainer/user (Docker uses this, as well as a few other functions).

I think this would be far more preferable to having a separate repo -- and if we plan to have more regular releases than that isn't a strong argument to have a separate repo either.

AkihiroSuda commented 3 years ago

Alternatively we can just move all of libcontainer into an internal package (which Go won't let you import) and we just leave libcontainer/cgroups in an importable path. I had planned to do something like this for a while.

SGTM

kolyshkin commented 3 years ago

Yeah, moving parts of libcontainer (that are not used by other projects) to under internal would be a good thing to do, we should try that after 1.0

rhatdan commented 3 years ago

Can we still consolidate the cgroup handling from containerd and libcontainer?

kolyshkin commented 3 years ago

Can we still consolidate the cgroup handling from containerd and libcontainer?

Ultimately this is still my goal, although it's not yet clear how to do it in a monorepo. Maybe we can just steal/adopt containerd/cgroups API, while mostly retaining libcontainer/cgroups implementation. All this is after https://github.com/opencontainers/runc/issues/3007#issuecomment-856712966 is implemented.

dims commented 3 years ago

@kolyshkin can we please do this for libcontainer/user as well? will help us in containerd ( https://github.com/containerd/containerd/pull/5635#issuecomment-865957207 )