-
Notifications
You must be signed in to change notification settings - Fork 375
Errors will happen when upgrading the libraries #2786
Comments
Hi @KateGo520. Thanks for raising. I'm rather confused by the issue though :) I think you tried to manually update some depedencies and that failed? Can you explain out of interest why you were trying to update the deps? The main focus of development is now this branch: And yes, we are using go modules there. See kata-containers/kata-containers#199 (specifically see kata-containers/kata-containers@e540648). Maybe @bergwolf saw the problem you are reporting? Either way, it sounds like we may need to backport the |
@jodh-intel Thanks for your reply. This report is a warm prompt for you to prevent or combat this issue. Just let you know that the problems if you upgrade these dependencies in the future. The report also provides two solutions when encountering the upgrading issues. Thanks again. |
@fidencio Is there something we can do with this information? |
@ariel-adam, please, feel free to ping me if I don't react to an issue alert. I think we could preemptively migrate to using go modules here, but I wouldn't do unless it's strictly required. |
We tried to move to go modules in the past and it was awkward. However, @bergwolf managed it for the 2.0 runtime so maybe we need to backport those changes from kata-containers/kata-containers#199. |
This issue is being automatically closed as Kata Containers 1.x has now reached EOL (End of Life). This means it is no longer being maintained.
This decision was discussed by the @kata-containers/architecture-committee and has been announced via the Kata Containers mailing list:
If you believe this issue still applies to Kata Containers 2.x, please open an issue against the Kata Containers 2.x repository, pointing to this one, providing details to allow us to migrate it. |
(The purpose of this report is to alert
kata-containers/runtime
to the possible problems whenkata-containers/runtime
try to upgrade the following dependencies)An error will happen when upgrading libraries containerd/cgroups, urfave/cli, opencontainers/runc and cri-o/cri-o :
For example----
github.com/containerd/cgroups
-Latest Version: Master branch,latest commit 80c669f (Latest commit 80c669f 10 days ago)
-Where did you use it:
https://github.com/kata-containers/runtime/search?q=containerd%2Fcgroups&unscoped_q=containerd%2Fcgroups
-Detail:
This problem was introduced since _containerd/cgroups commit 06e7180 on 21 Dec 2019 _ . If you try to upgrade containerd/cgroups to commit
06e7180
on 21 Dec 2019 and above, you will get an error--- no package exists at "github.com/coreos/go-systemd/v22" and "github.com/godbus/dbus/v5"Similar issues can also happen when upgrading libraries opencontainers/runc, urfave/cli, cri-o/cri-o .
I investigated the libraries' (containerd/cgroups, opencontainers/runc, urfave/cli and cri-o/cri-o) release information and found the root cause of this issue is that----
These dependencies all added Go modules in the recent versions.
They all comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:
physical path
. So earlier versions of Go (including those that don't have minimal module awareness) plus all tooling (like dep, glide, govendor, etc) don't haveminimal module awareness
as of now and therefore don't handle import paths correctly See golang/dep#1962, golang/dep#2139.Solution
1. Migrate to Go Modules.
Go Modules is the general trend of ecosystem, if you want a better upgrade package experience, migrating to Go Modules is a good choice.
Migrate to modules will be accompanied by the introduction of virtual paths(It was discussed above).
Then the downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide, govendor…).
2. Maintaining v2+ libraries that use Go Modules in Vendor directories.
If
kata-containers/runtime
want to keep using the dependency manage tools (like dep, glide, govendor, etc), and still want to upgrade the dependencies, can choose this fix strategy.Manually download the dependencies into the vendor directory and do compatibility dispose(materialize the virtual path or delete the virtual part of the path). Avoid fetching the dependencies by virtual import paths. This may add some maintenance overhead compared to using modules.
As the import paths have different meanings between the projects adopting module repos and the non-module repos, materialize the virtual path is a better way to solve the issue, while ensuring compatibility with downstream module users. A textbook example provided by repo
github.com/moby/moby
is here:https://github.com/moby/moby/blob/master/VENDORING.md
https://github.com/moby/moby/blob/master/vendor.conf
In the vendor directory,
github.com/moby/moby
adds the /vN subdirectory in the corresponding dependencies.This will help more downstream module users to work well with your package.
3. Request upstream to do compatibility processing.
The
containerd/cgroups
have 156 module-unaware users in github, such as: demonoid81/cri, stefanberger/imgcrypt,OSH-2020/containerd-rvisor…https://github.com/search?q=containerd%2Fcgroups+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json
Summary
You can make a choice when you meet this DM issues by balancing your own development schedules/mode against the affects on the downstream projects.
For this issue, Solution 1 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.
References
Do you plan to upgrade the libraries in near future?
Hope this issue report can help you ^_^
Thank you very much for your attention.
Best regards,
Kate
The text was updated successfully, but these errors were encountered: