Podman: Varlink no longer accessible in 2.0.2, requesting stable 2.0.0 package

[drewbailey]

/kind bug

Varlink is not supported message

I understand that podman is moving away from varlink in favor the the HTTP API, which I think is great. Unfortunately the switch is happening a bit too quickly for us to manage migrating. I think that the deprecation notice in 2.0.0 and then dropping it entirely in 2.0.2 was a little quick and unexpected for a patch release.

Is there anyway we could get a release channel/package that contains varlink (v2.0.0)?

→ podman varlink -t 100000 unix:/run/user/1000/podman/io.podman
Command "varlink" is deprecated, Please see 'podman system service' for RESTful APIs
Error: varlink is not supported

→ dpkg -s podman
Package: podman
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 72780
Maintainer: Lokesh Mandvekar <[email protected]>
Architecture: amd64
Version: 2.0.2~1
Depends: libseccomp2, libdevmapper1.02.1, libgpgme11, catatonit, conmon (>= 2.0.18~1), containers-common (>= 1.0.0~2), containernetworking-plugins (>= 0.8.6~1), runc | cri-o-runc, iptables, podman-plugins
Recommends: crun, slirp4netns, uidmap
Conflicts: podman-rootless
Conffiles:
 /etc/cni/net.d/87-podman-bridge.conflist a87c090f17c5274af878e7106e969b60
Description: Manage pods, containers and container images.
Homepage: https://github.com/containers/libpod.git

[mheon]

@baude @lsm5 What do we want to do here? Keep Varlink around until we deprecate for F33?

[lsm5]

@drewbailey I can add that back in for debian, no worries.

@mheon maybe we can have different rules for each distro? or conflicting subpackages like podman and podman-varlink, so people can install podman-varlink if podman ain't good enough?

[mheon]

Hm. We can probably keep the tag for 2.0.x and 2.1.x, then drop to a subpackage for 2.2.x, and finally remove around 2.3.x, maybe?

[lsm5]

Hm. We can probably keep the tag for 2.0.x and 2.1.x, then drop to a subpackage for 2.2.x, and finally remove around 2.3.x, maybe?

I'm fine with that approach, no idea about when exactly those should happen though. @baude @vrothberg @rhatdan @jnovy ??

[lsm5]

@drewbailey v2.0.2 is now on OBS with varlink. Let me know how that works. I'll close this...

[towe75]

Hey @lsm5, it's working. Thank you for the fix.

[TomSweeneyRedHat]

@mheon @baude, maybe a water cooler discussion, but could we keep varlink around until Podman 3.0 but have all kinds of "not supported" disclaimers as of 2.3 or some such?

[towe75]

@TomSweeneyRedHat My 2 cents from integrator/user perspective: it's not a problem to deprecate and eventually remove features with a clear and announced time line. It surely helps the team to keep the codebase lean.

This github issue is a result of having only 'the latest' deb/rpm/whatever asset in the repositories. Varlink support disappeared there within a minor update from one day to another and we did not even have the chance to recommend a pinned package version.

[rhatdan]

We are looking at removing the varlink support based on support. IE We want it gone before RHEL9 and RHEL8.4 is shipped. We also want it gone in Fedora 33. I would figure other distributions, if they are supplying support for Podman should want it gone in a longer term support cycle.

We also are no longer fixing minor issues in varlink.

Since we have no idea when a Podman 3.0 is going to happen, and no plans for functionality that would trigger such an event, I don't think we can wait for it, unless a Podman 3.0 is no more then removing varlink, which does not seem to justify a major bump. :^)

[rhatdan]

We have to support it until Fedora 32 goes away, and RHEL8.2 is is in support. But we have branches for this.
The question is do we remove support from podman 2.1? If we do, then we no longer can update Fedora 32 with this release.

I recommend that we ship varlink support in podman 2.1 and then drop support in podman 2.3 (At the time of the Fedora 33 Beta Branch)

[TomSweeneyRedHat]

My main reason for dropping it at 3.0 was the ease to remember when it went away. If we get out to 2.24 will we be able to remember if it was dropped in 2.3, 2.4, or 2.5? But perhaps by then it won't matter.

My main concern mirrors @towe75 , I just want to make sure we announce and publicize when it's going to be dropped well in advance and in many places.

[rhatdan]

Well I hope that does not happen. The real issue to me is the value of a Major version release. We want to have something to Market like APIV2. If we release V3.0 and all we announce is we are taking functionality away, it is kind of a dud of a release.