podman info - field to check whether it's a remote client

[vrothberg]

podman info should have a field indicating whether it's a remote client or not (see kubernetes-sigs/kind#2235 (review)).

[Luap99]

The remoteSocket field is only added by the local client:

$ podman info | grep remoteSocket
  remoteSocket:
$ podman-remote info | grep remoteSocket

[vrothberg]

@Luap99, that's not a reliable source:

~ $ podman-remote info |grep emote
  remoteSocket:
~ $ podman info |grep emote
  remoteSocket:

[Luap99]

It looks like this behaviour changed after v3.1.2.

[afbjorklund]

It would be even more strange if podman-remote didn't have a socket ?

So far we have mostly been using podman version to tell them apart.

$ podman version
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64
$ podman-remote version
Client:
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Server:
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

But it could be good with an explicit field.

Like the current "rootless", or something ?

$ podman info | grep rootless
    rootless: true
$ sudo podman info | grep rootless
    rootless: false

---

Actually we just hardcoded runtime.GOOS != "linux"

Made it hard to test podman-remote on Linux, though...
kubernetes/minikube#8003

But the lack of networking stopped using podman remote.

podman-remote run -p 127.0.0.1:8000:80 -d docker.io/library/nginx
curl http://localhost:8000

[afbjorklund]

@Luap99 :

So if you run podman-remote, it does not have a socket ?

podman-remote info

But if you log in to the machine and run podman local, it does ?

podman machine ssh podman info

@@ -42,6 +42,9 @@
       spec: 1.0.0
       +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
   os: linux
+  remoteSocket:
+    exists: true
+    path: /run/user/1000/podman/podman.sock
   security:
     apparmorEnabled: false
     capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT

That is quite counter-intuitive.

[jwhonce]

@Luap99 @afbjorklund I suggest adding the field host.serviceIsRemote (bool) unless there is an objection. It would be set in the podman client vs. the service. The client already "knows" how it is connecting to libpod (registry.IsRemote()). remoteSocket has come to mean the socket the service is listening on. This is a quick addition and makes it very obvious what is going on.

/cc @rhatdan @baude

[jwhonce]

/cc @vrothberg

[rhatdan]

SGTM

[afbjorklund]

Yes, something new sounds good to me. I guess downstream will have to compare versions or something.

And go back to heuristics, if the podman version is too low - or maybe just when the new field is missing ?

podman version | grep Server

I don't think looking at $CONTAINER_HOST would work anymore, since it could be using a "connection"

[jwhonce]

@afbjorklund FYI A HEAD on /_ping returns the header Libpod-Api-Version which clients could use to determine which method to use.

[afbjorklund]

I think we have mostly given up on using the API for podman, and resort to using the CLI instead...

And it seems to give consistent results, for the older versions (tested with podman1/podman2/podman3)

$ podman-remote info --format "{{.Host.ServiceIsRemote}}"
Error: template: info:1:7: executing "info" at <.Host.ServiceIsRemote>: can't evaluate field ServiceIsRemote in type *define.HostInfo
$ echo $?
125

So one can use the new info feature for podman4 (or whenever it is included), and fall back on version.

We normally call it anyway, not so much for the actual version - but more as a quick way to check it's alive...

$ podman-remote info --format "{{.Host.ServiceIsRemote}}"
true$ echo $?
0

[afbjorklund]

@jwhonce : assuming that podman is the regular daemonless version, where would one send the /_ping ?

Otherwise, we could just look at the binary. If it is podman-remote, it is remote. (not using podman --remote)

So I think the proposed info field for remoteness is fine.

---

If i understand correctly, they had some different original requirements anyway:

		// Unlike `docker info`, `podman info` does not print available cgroup controllers.
		// So we parse "cgroup.subtree_control" file by ourselves.

So maybe they were more interested in cgroupVersion, and some new fields ?

	MemoryLimit     bool     `json:"MemoryLimit"`
	PidsLimit       bool     `json:"PidsLimit"`
	CPUShares       bool     `json:"CPUShares"`

kubernetes-sigs/kind#2233