[Investigation] Remove Containerd dependency from root go.mod
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- go
- Domain
- build-system
Research direction
Start with the root go.mod and the imports used by cmd/containerd-shim-runhcs-v1, then inspect the containerd dependency and its transitive modules. Determine whether the shim can retain the task and error definitions without the root dependency, and verify that Kubernetes vendoring no longer encounters the described replace-directive conflict.
Written by the indexing model from the issue text.
Description
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 https://github.com/containerd/containerd/pull/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.
- Dominant language
- Go
- Stars
- 694
- Forks
- 304
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 28
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/hcsshim
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 62/100
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
All issues in microsoft/hcsshim
Similar issues
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
JakeChampion/lang#10213 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100