-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move most packages into internal
#3028
Comments
taking stock, as of today here's what kubernetes is importing:
|
and here's what cadvisor is importing:
|
Let's see if we can remove anything but
The only use is
This has some cgroup-related definitions; maybe we can move it to libcontainer/cgroups, leaving backward-compatible aliases in libcontainer/configs for smoother transition. Same for cadvisor.
This should go away once runc 1.0.0 GA is released (see kubernetes/kubernetes@9a86d92)
The only use is func getCgroupV1Path(cgroupPath string) (string, error) {
cgroupPath = libcontainerutils.CleanPath(cgroupPath) (and I admit that despite staring at cgroups code for quite a long time I don't fully understand yet why Now for cadvisor, the only pkg that has left is
this is very similar to cgroups and I guess we'll have to keep it public. |
docker, cri-o, buildah, podman etc uses a lot of stuff from libcontainer/devices, libcontainer/user and so on -- seems that kubernetes and cadvisor is just the tip of the iceberg. |
AFAIK the |
It was mostly an abundance of caution because we had cases where lexical path attacks were very trivial against runc, so we added |
I tried it in #3049 but I do need some input from @opencontainers/runc-maintainers on what the internal path should be (see #3049 (comment) and the following discussion). Basically, we have three options (under
My #3049 implemented approach number 1, while @hqhq thinks it's better to do number 2. Apparently, we need more opinions on that to move forward. Please speak up your mind. Surely this is not limited to the above three options -- some other variants (e.g. |
OK, this is obviously not ready for 1.1; moving to 1.2. Would appreciate some input from other @opencontainers/runc-maintainers on this. |
Although not related to this issue, I think we can move the main package into I opened a PR #3521 for it, WDYT. |
Moving this to 1.3.0 due to lack of input from @opencontainers/runc-maintainers wrt #3028 (comment) |
OK, as a small step forward, we now have |
Kubernetes is discussing dropping the runc imports here: kubernetes/kubernetes#128157. Some runc maintainers were tagged there. I'd like to align what we want for runc here. What do others think? I have mixed feelings with this and I'm not aware of the history (and maybe even if it caused a lot of pain in the past). On one hand, I think kubernetes, docker, cadvisor, etc. are very important users and we need to do the cgroup handling anyways, so we might as well try to move as much as possible to internal and polish the API that we want to expose for them. It's some work, but it seems completely doable. On the other hand, it seems containerd is already exposing cgroup handling as a standalone package (https://github.com/containerd/cgroups) and that might get almost all of what they need with that, so it doesn't sounds bad either. They are also considering to just fork our current libcontainer package, which IMHO might make sense but I'm not so sure it is a good outcome (it might, I haven't made my mind on that yet). But I'm lacking the history, to know what was painful and whatnot. What do others think? |
I am very much against forking libcontainer. I have seen parts of lxc, docker etc forked many times, and every time it happens some bugs are fixed in one place but not another, and I'm the one which needs the other fixed. I've outlined my vision there: kubernetes/kubernetes#128157 (comment) From our side, we need to decouple libcontainer/cgroups from the rest of it (mostly this is moving parts of libcontainer/configs used by cgroups to be a part of libcontainer/cgroup), move libct/cg to a separate repo and use it from there. A semi-related task is to sunset |
At the moment all of our internal packages are importable from anywhere. There are several historical reasons for this:
internal
package system didn't exist until Go 1.4, and it wasn't really widely publicised at the time (I only heard about it a few years ago).However, there are still modern users of our APIs:
HostDevices
comes to mind).So we can't just move everything into an
internal
package but we really should move most of it. We do have some users usinglibcontainer
as a library but it is fairly scary because it is fairly easy to misconfigure containers if you use theProcess
APIs for instance. We should move as many libraries as possible behind aninternal
package.This will also make it easier to explain our SemVer policy -- because right now I would argue that SemVer doesn't cover our Go APIs, but I imagine some users are not aware of that. Putting most of
libcontainer
inside aninternal
package would solve this problem entirely.The text was updated successfully, but these errors were encountered: