-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[Investigation] Remove Containerd dependency from root go.mod #1148
Comments
Looks like the option is to trim from containerd and hcsshim as expected (thanks @liggitt) kubernetes/kubernetes#104827 (comment) |
Poking around, it seems almost all the needed imports are to get access to either Specifically, there's some constants in
After that, there's only a couple of constants ( Anyway, this is almost all containerd-side changes I'm proposing, which would mean containerd 1.6 at best. There probably needs to be a tracking bug on the containerd side for "stabilising Go API for shim implementers"? |
The containerd/containerd repo brings in quite a lot of transitive dependencies for what we actually use the import for. We currently use it for the task definitions, error definitions and a couple of other things for our shim that's built out of this repository. If the shim had it's own go.mod this may be alleviated, although with adding a bit of annoyance to maintenance.
A real pain point of this however that we'd encountered in the wild is when trying to update kubernetes/kubernetes to a new tag of hcsshim, which was that Containerd 1.5+ (before 1.5 containerd was not on go modules) currently errors out when trying to get vendored into k8s. This is due to Containerd having dependencies on a lot of the k8s subprojects that live in the staging directory in kubernetes/kubernetes and the projects in the staging directory having dependencies on each other through replace directives. I'm not sure of the root problem here or what's the best solution long term, but for our case removing this dep from the root go.mod will solve quite a lot.
Containerd has already done some work to try and alleviate some scenarios where the only thing you might need from Containerd is just api definitions, see containerd/containerd#5716 (thanks @dims!!!) but we use the dep for a bit more than what this change offers.
Perhaps there can be some work done in kubernetes itself to alleviate some of these issues, as it doesn't seem uncommon to have a project that depends on some of the subprojects that needs to be vendored into k8s itself. I've made a dead simple repo that just depends on a couple of the sub projects at the same tags that ctrd 1.5 was on, and the same issue arises on trying to add this as a dependency to K8s https://github.com/dcantah/deps.
The text was updated successfully, but these errors were encountered: