macos: podman 2.0.6 remote support is broken

[ssbarnea]

While recent versions of podman improved the remoting support they also introduced some critical bugs, like

export CONTAINER_HOST=ssh://[email protected]/run/podman/podman.sock
podman build .
# returns success (0), no output, but it failed to do anything

Trying to increase verbosity has not effects.

Both client (macos) and remote (fedora-32) are using same version of podman 2.0.6

[vrothberg]

@ashley-cui PTAL

[ashley-cui]

@ssbarnea is this a duplicate of #7498 ?

[ssbarnea]

It seems like but there are two different issues: lack of logging and lack of returning the result code from the command. I would treat them differently, later one being critical.

[afbjorklund]

Same situation on Linux. It was working in 2.0.0-2.0.4, but broken in 2.0.5-2.0.6

Since older versions are no longer available, it is not possible to downgrade either.

[ashley-cui]

@ssbarnea got it, thanks
@afbjorklund thanks for the info, that'll definitely be helpful. I'll take a look at this soon

[afbjorklund]

Hopefully some regression tests can be added for podman 2.1, for a better release ?

As it is now, we will probably will stay on podman 1.9.3 for the rest of the year or so.

[rhatdan]

We are going to start release candidates on Monday for podman 2.1 so @ashley-cui Could you try each one out.

[rhatdan]

@ssbarnea We added a new method to handle connections in podman 2.0
podman system connect

# podman system connect --help
Manage podman

Description:
  Manage podman

Usage:
  podman system [command]

Available Commands:
  connection  Manage remote ssh destinations
  df          Show podman disk usage
  info        Display podman system information
  migrate     Migrate containers
  prune       Remove unused data
  renumber    Migrate lock numbers
  reset       Reset podman storage
  service     Run API service

[ashley-cui]

@rhatdan yep, looks like this is a real regression. i'll see if i can get this done.

[ashley-cui]

huh, i was able to reproduce once for the linux podman-remote and then later it worked.. odd

$ podman-remote build ~/tst
Getting image source signatures
Copying blob sha256:50644c29ef5a27c9a40c393a73ece2479de78325cae7d762ef3cdc19bf42dd0a
Copying blob sha256:4ca545ee6d5db5c1170386eeb39b2ffe3bd46e5d4a73a9acbebc805f19607eb3
Copying config sha256:f69e15d34b6bdf5d326269510a1863eda431a4c6b0965a1918d6ec68a4934799
Writing manifest to image destination
Storing signatures
--> f69e15d34b6
f69e15d34b6bdf5d326269510a1863eda431a4c6b0965a1918d6ec68a4934799

FROM alpine
CMD echo "hello world"
COMMIT
Successfully built f69e15d34b6bdf5d326269510a1863eda431a4c6b0965a1918d6ec68a4934799

[afbjorklund]

We added a new method to handle connections in podman 2.0

I will take a look to see if this new podman system connection command can replace the variables.

I don't fully understand how it would work with two machines/shells, but I see that it has "names".

Usage:
  podman system connection add [flags] NAME DESTINATION

However, there doesn't seem to be a variable for which connection to use - or am I missing something ?

So each command would have to use podman --remote --connection name, if not using the default name.

No $PODMAN_NAME for param ?

The user can have several VMs...

It seems like by default, they would both use the ~/.config/containers/containers.conf configuration file.

So if I use podman system connection default NAME in one shell, it would also affect the other shell.

See https://minikube.sigs.k8s.io/docs/commands/podman-env/

https://minikube.sigs.k8s.io/docs/handbook/pushing/#3-pushing-directly-to-in-cluster-cri-o-podman-env

EDIT: Opened #7623 for this request

[rhatdan]

I suppose we could add a connection name environment variable to override the default, if this is something you would want.