search

fedora-iot / iot-distro

Issue tracking for the Fedora IoT Edition
BSD 3-Clause "New" or "Revised" License
3 stars 0 forks source link

remove `slirp4netns` from the default package set #61

Closed miabbott closed 1 month ago

miabbott commented 2 months ago

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/51

There 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 been pasta - 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 the pasta tool:

[core@localhost ~]$ rpm -q --whatrequires slirp4netns
no package requires slirp4netns
[core@localhost ~]$ rpm -q --whatrecommends slirp4netns
no package recommends slirp4netns

In an effort to keep IoT both slim and modern, I'd advocate that we should remove the package from the default set.

nullr0ute commented 2 months ago

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.

miabbott commented 2 months ago

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.

nullr0ute commented 2 months ago

OK, I understand that perspective.

How long should we carry the package in IoT?

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?

I also don't think carrying the package indefinitely is the right move either.

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?

miabbott commented 2 months ago

What should we consider a reasonable time?

That's what I was trying to get from you! :stuck_out_tongue:

Just trying to solicit opinions on this kind of topic.

Do other variants such as CoreOS have a policy here?

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: https://github.com/coreos/fedora-coreos-tracker/issues/1130, https://github.com/coreos/fedora-coreos-tracker/issues/676)

(In the case of slirp4netns, they still carry it as of this writing, with no deprecation plans as far as I can tell: https://github.com/coreos/fedora-coreos-config/blob/cabe5eed396d10db449628b63935122b4464eea7/manifests/fedora-coreos-base.yaml#L108. They also expliclitly include passt - https://github.com/coreos/fedora-coreos-config/blob/cabe5eed396d10db449628b63935122b4464eea7/manifests/user-experience.yaml#L46-L47)

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 fedorar/rawhide/x86_64/iot, get promoted to fedora/devel/x86_64/iot and then rolled out as fedora/stable/x86_64/iot. (You could convince me to do it in X+1 pretty easily)

travier commented 1 month ago

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

nullr0ute commented 1 month ago

@travier do you have a policy how long you keep the deprecated options for?

travier commented 1 month ago

Not really. In this case as it's 95kB, I think we'll keep it until support is dropped in podman.

nullr0ute commented 1 month ago

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?

miabbott commented 1 month ago

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 podman drops support feels wise to me.

nullr0ute commented 1 month ago

I think it's a useful conversation to have recorded so thanks all.