podman-remote: default PullPolicy must be missing instead of empty str

[flouthoc]

If registry is remote default pull policy must be missing instead of
remote. Since empty str == pullpolicy {always} for more context on
this behaviour check #10739

[NO TESTS NEEDED]

Closes: #12201

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: flouthoc
To complete the pull request process, please assign luap99 after the PR has been reviewed.
You can assign the PR to them by writing /assign @luap99 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[flouthoc]

@afbjorklund @vrothberg It seems we are passing empty string in case of podman-remote which is not expected. Default policy must be missing always. @afbjorklund Could you try above patch please.

[afbjorklund]

Could you try above patch please.

I don't see any changes in behaviour.

Possibly the old server (3.2.1) didn't have any API field to send the "policy" flag in, it seems it was added in 3.4.1 ?

[flouthoc]

@afbjorklund I think yes it was introduced after #10739. Could you try with version 3.4.1 or above. I don't know if there are any plans of back-porting the field though.

[afbjorklund]

The moral of the story is that you always need to match the podman client with the server, I suppose.

[afbjorklund]

Could you try with version 3.4.1 or above.

Podman 3.2.1 was the latest version for Ubuntu 21.10

https://packages.ubuntu.com/search?keywords=podman

Otherwise one would have to go back to the vendor packages (Kubic) again, instead of using the system packages ? Or use the static binaries perhaps, for the older clients.

[flouthoc]

@afbjorklund were you able to try this out with 3.4.1

[Luap99]

I think the default policy must be set on the server side and never the client. We control podman-remote but other API users face the same problem.

[Luap99]

@vrothberg PTAL

[vrothberg]

I concur with @Luap99. We may need a similar check in the handlers.

What exactly in #10739 adds context to this issue? The two issues look substantially different to me.

[flouthoc]

@vrothberg I think PR added a default to always when empty policy string is specified i am not entirely sure though https://github.com/containers/podman/pull/10739/files#diff-ff4f6ad01da9e06c3f164f840cc9376e3cbc746c74e5811ae59690323eb1fa37R152 but i agree with @Luap99 we can move defaults to server side.

[rhatdan]

I agree this should be handled on the remote side of the connection.

[afbjorklund]

Need to try again with 3.4.1 client towards a 3.4.1 server, but I suspect that it works (or else that release does not) ?

I was expecting a pull policy of "missing" for run and "always" for pull. Think I need a 3.2.1 client for the 3.2.1 server.

[afbjorklund]

@flouthoc

Confirm that the 3.4.1 server works with the 3.4.1 client:

DEBU[0000] DoRequest Method: GET URI: http://d/v3.4.1/libpod/_ping 
DEBU[0000] Loading registries configuration "/etc/containers/registries.conf" 
DEBU[0000] DoRequest Method: POST URI: http://d/v3.4.1/libpod/images/pull 
DEBU[0000] DoRequest Method: POST URI: http://d/v3.4.1/libpod/containers/create 

And also that the 3.4.1 server works with the 3.2.1 client:

DEBU[0000] DoRequest Method: GET URI: http://d/v3.2.1/libpod/_ping 
DEBU[0000] DoRequest Method: GET URI: http://d/v3.2.1/libpod/images/docker.io%2Fbusybox/exists 
DEBU[0000] DoRequest Method: POST URI: http://d/v3.2.1/libpod/containers/create 

The problem is with the 3.2.1 server and the 3.4.1 client.

Unfortunately, that is also the scenario with lima and brew...

[rhatdan]

If this gets fixed in the server, then only the server will matter.