cri-tools failed to build from source in Fedora rawhide/f36 https://koji.fedoraproject.org/koji/taskinfo?taskID=81770453 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Please fix cri-tools at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, cri-tools will be orphaned. Before branching of Fedora 37, cri-tools will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 1853905 [details] build.log
Created attachment 1853906 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1853907 [details] state.log
I am confused, we're using modules now for cri-o and cri-tools. Do we also have to use the normal package?
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Blocks 2119788 - https://bugzilla.redhat.com/show_bug.cgi?id=2119788
FEDORA-2022-d4c0ad9653 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4c0ad9653
> I am confused, we're using modules now for cri-o and cri-tools. Do we also have to use the normal package? Non-modular packages cannot depend on modular packages[^1], and the vast majority of Fedora packages are non-modular. Additionally, modular packages are not very discoverable by users. In fact, the package was previously in violation of Fedora's modularity policy: > - Modular-only packages MUST NOT exist in Fedora. Modular versions MAY exist as alternatives to non-modular packages only. There is an exception to this rule: if the package does not function in non-modular Fedora (with a reasonable amount of work), it is permitted to have it in module only.[3] For the time being, such exceptions can be granted by FESCo. > > - Default streams MUST NOT be used in Fedora.[4] > > - Packagers SHOULD prefer compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability). > > [...] > 3. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora > 4. This rule may be revised in the future, especially if the functionality of default streams is improved. -- https://docs.fedoraproject.org/en-US/modularity/policies/ A non-modular version was already built in f37, so I went ahead and built it in f36 and f38 (rawhide), which already had distgit branches. Brad, if you need the package in f35 and Peter agrees, I can also branch cri-tools for that version. [^1]: I believe this works differently when default streams exist, but those are not allowed in Fedora.
thanks Maxwell G. I did a little checking and found this paragraph on the kubernetes web site: " You can download a compressed archive crictl from the cri-tools release page, for several different architectures. Download the version that corresponds to your version of Kubernetes. Extract it and move it to a location on your system path, such as /usr/local/bin/ ". This is basically the version linkage that cri-o has with kubernetes - match the major-minor version. CRI-O is modular, Anthony and I plan to shift to a modular kubernetes release for fedora. Upstream kubernetes currently supports 3 versions (1.22, 1.23, and 1.24 as I write; 1.25 is on the cusp of release). In kubernetes, kubeadm requires crictl which is part of cri-tools. kubeadm is in the fedora kubernetes-master package. I am less clear about the interdependencies between cri-o and cri-tools. CRI-O is one of several container runtimes that kubernetes can use so cri-o is not required for a successful kubernetes install but cri-tools is. I wonder if it would make sense to separate cri-tools from cri-o? For F35, at this point we have only released kubernetes 1.22. CRI-O 1.22 includes cri-tools 1.22 so user needs should be satisfied. Thanks for checking but no additional action is needed unless the cri-tools upstream releases 1.22.2 (which seems to be pretty rare for them).
FEDORA-2022-d4c0ad9653 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-d4c0ad9653` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4c0ad9653 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> CRI-O is modular, Anthony and I plan to shift to a > modular kubernetes release for fedora. I do not think this is a good idea. First, if cri-o or cri-tools is not available on certain releases as a non-modular package, this needs to be fixed and become in line with the guidelines. I'm sure what you mean by "shift to a modular kubernetes." You can't remove packages from the default repos in stable releases. You can't have modular-only packages (see the guidelines that I previously quoted). Moving the package to a module would mean that `dnf install kubernetes` no longer works. Overall, I don't think modularity will actually fix the problems you set out to fix. It will just introduce new ones. > In kubernetes, kubeadm requires crictl which is part of cri-tools. Currently, only the rawhide kubernetes package Requires cri-tools. cri-tools will be available from f36-f38 as a non-modular package once all the updates reach stable, so you'll be able to add `Requires: cri-tools` on f36 and f37, as well. > I wonder if it would make sense > to separate cri-tools from cri-o? They are already separate with non-modular packages. > For F35, at this point we have only released kubernetes 1.22. CRI-O > 1.22 > includes cri-tools 1.22 so user needs should be satisfied. Well, they're not satisfied. As per https://bugzilla.redhat.com/show_bug.cgi?id=2110153 , `kubeadm init` requires crictl. However, kubernetes is a non-modular package and it does not and cannot Require cri-tools from the CRI-O 1.22 module in Fedora 35. The current situation is broken, as the package doesn't Require all of its dependencies. If kubernetes in Fedora 35 needs cri-tools 1.22.x, that can and should be branched and provided as a non-modular package.
(In reply to Maxwell G from comment #11) I would like fedora (and fedora coreos) to become first class hosts for kubernetes. (please forgive any (re)statements of the obvious). The kubernetes team provides support for 3 concurrent versions of k8s. At this time, as noted above, 1.22, 1.23, and 1.24. As part of the first class host vision, I would like to see k8s rpms for all 3 k8s versions, on each supported version of fedora. I am far from an expert on dnf or rpm but the only mechanisms I see to enable this vision are modularity or careful use of the versionlock plugin (although this would break another fedora standard on versioning within a fedora release). Is there another possible approach I am missing? > > I do not think this is a good idea. First, if cri-o or cri-tools is not > available on > certain releases as a non-modular package, this needs to be fixed and > become in line with the guidelines. > I'm sure what you mean by "shift to a modular kubernetes." You can't > remove packages from the default repos in stable releases. You can't have > modular-only packages (see the guidelines that I previously quoted). > Moving the package to a module would mean that `dnf install kubernetes` > no longer works. Overall, I don't think modularity will actually fix the > problems you set out to fix. It will just introduce new ones. > You can likely tell that this would be my first attempt at modularity. Basically, there would need to be a rollout/communication plan that states which version of fedora the modular kubernetes would be available (e.g. f38) with the non-modular package still available and updated when needed for older versions, supported of fedora. > > Currently, only the rawhide kubernetes package Requires cri-tools. > cri-tools will be available from f36-f38 as a non-modular package once > all the updates reach stable, so you'll be able to add `Requires: > cri-tools` on f36 and f37, as well. Thanks.
You could use compat packages, but I'm not sure that would work well for this situation. This would be an appropriate use case for modules. I will warn you that they are bit complicated and annoying to deal with, and there is a fair amount of consternation re. modularity amongst Fedora packagers. I'm not an expert on modularity, so it's probably a good idea to read through the docs[1] :). [1]: https://docs.fedoraproject.org/en-US/modularity/ If you decide to go this route, you still have to provide a regular, non-modular kubernetes package. As with all modular packages (that follow the rules), the kubernetes modules would coexist with the the regular kubernetes package. Users would be able to choose to enable the module if they want a specific version. Note that the non-modular package still has to follow the normal rules re. updates and version bumps. The kubernetes module would depend on the appropriate version of the cri-o module and the kubernetes-adm package would Require cri-tools as usual. It is probably a good idea to publicize the new kubernetes modules, as modules aren't the most discoverable.
(In reply to Maxwell G from comment #13) Thanks Maxwell > > This would be an appropriate use case for modules. I will warn you that they > are bit complicated and annoying to deal with, and there is a fair amount of > consternation re. modularity amongst Fedora packagers. I'm not an expert on > modularity, so it's probably a good idea to read through the docs[1] :). > > [1]: https://docs.fedoraproject.org/en-US/modularity/ > > If you decide to go this route, you still have to provide a regular, > non-modular kubernetes package. As with all modular packages (that follow > the rules), the kubernetes modules would coexist with the the regular > kubernetes package. Users would be able to choose to enable the module if > they want a specific version. Note that the non-modular package still has to > follow the normal rules re. updates and version bumps. The kubernetes module > would depend on the appropriate version of the cri-o module and the > kubernetes-adm package would Require cri-tools as usual. All great points. On the to-do list now. > > It is probably a good idea to publicize the new kubernetes modules, as > modules aren't the most discoverable. I agree, Not sure what would be the best location yet. Thinking about a fedora magazine article and supporting web page (wiki?, fedora docs?) and some announcements on various mailing lists.
hello all, sorry for the radio silence: modules for cri-tools, cri-o and kubernetes is my preferred method (despite my having first hand knowledge about how finicky and difficult they are). I am fine decoupling cri-tools from cri-o. I think it would be really cool to have kubernetes have a `Requires: cri-implementation(>=1.24)` or something, and then cri-o and containerd can `Provides: cri-implementation = 1.24` for the kubernetes versions they support. Thank you for taking this on, I will try to keep my attention closer to this work to better collaborate :)
Greetings Peter, evryone. Thanks for providing your prospective. I will check in with Anthony and provide a short proposal. As Maxwell notes, creating a module does not preclude continuation of non-modular versions of the package. The implication for Fedora is we will need consensus between cri-o, kubernetes and (so to be) cri-tools maintainers on what version(s) to support for F36, F37, etc so that these non-modular rpms maintain version sync with each other. I am just winding up one project at home so will have some time to take write out some ideas.
FEDORA-2022-d4c0ad9653 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.