-
Notifications
You must be signed in to change notification settings - Fork 0
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
remove slirp4netns
from the default package set
#61
Comments
The reason it wasn't removed was because of migration for existing users isn't automatic so for an upgrade they would end up without networking which is probably not a great user experience. |
OK, I understand that perspective. How long should we carry the package in IoT? I don't expect to see any migration tools emerge from the containers stack, but I also don't think carrying the package indefinitely is the right move either. |
Well the podman 5 feature which changed the default was only part of F-40, AKA the current stable release. What should we consider a reasonable time? Also how should we educate IoT users of this sort of "your stuff will break if you don't update" sort of change?
Never said it should be carried indefinitely, is 1 full cycle, 2 cycles considered reasonable? Do other variants such as CoreOS have a policy here? |
That's what I was trying to get from you! 😛 Just trying to solicit opinions on this kind of topic.
The policy CoreOS uses is somewhat vague as documented. In practice, they often work to have migration code/workarounds in place, then deprecate/remove items along the usual next/testing/stable cadence (optimistically 6 weeks from next to stable). (See: coreos/fedora-coreos-tracker#1130, coreos/fedora-coreos-tracker#676) (In the case of Six weeks doesn't seem feasible for IoT, so I would strawman announcing the deprecation in release X and actually doing the removal in X+2. That allows us to make the change in |
As a data point, we provide both on the Atomic Desktops to keep existing toolbox / containers working: https://pagure.io/workstation-ostree-config/blob/main/f/common.yaml#_61 |
@travier do you have a policy how long you keep the deprecated options for? |
Not really. In this case as it's 95kB, I think we'll keep it until support is dropped in podman. |
Yes, agreed, and also it's not conflicting or breaking newer features so I'm not sure it's worth breaking current users. @miabbott where do you think we should go from here? |
Thanks for the addition data points, Timothee! To be honest, I didn't know how small the package was, so it keeping it in IoT doesn't seem like as big of an issue as I originally thought. The plan for keeping it around until |
I think it's a useful conversation to have recorded so thanks all. |
As part of the investigation of moving to support bootable containers, there was some discussion about the inclusion of
slirp4netns
as part of a base image - https://gitlab.com/fedora/bootc/base-images/-/merge_requests/51There was debate about why that package was included, which goes back to the early days of supporting rootless containers in the
podman
stack.We can see evidence of that rationale when it was originally included in IoT - https://pagure.io/fedora-iot/ostree/c/41b6b08aa577ecb827996296712210ce1889040c?branch=master
Since
podman
v5, the default rootless networking tool has beenpasta
- https://blog.podman.io/2024/03/podman-5-0-breaking-changes-in-detail/This rolled out as part of Fedora 40 (I think?) and has had significant time to soak in Fedora and Fedora IoT.
Nothing in IoT depends on
slirp4netns
anymore, with the introduction of thepasta
tool:In an effort to keep IoT both slim and modern, I'd advocate that we should remove the package from the default set.
The text was updated successfully, but these errors were encountered: