shortnames prompt should never be shown on the server

[Luap99]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Try to pull with the remote client an shortname image with no configured short name and the short name mode is set to enforcing or permissive(default).
The registries selection prompt is shown on the server. According to the documentation this is correct since I run the server in a tty but I don't see any reason why anyone ever would want this. The end goal should be to show the prompt on the remote client or if not possible to fail.

The reason I run into this is because I usually run the server process in the background with podman system service -t0 &. The problem is that the remote client will just hang until you select the registry on the server. The user does not know why it is hanging or what he needs to do to solve it.

[Luap99]

@vrothberg PTAL

[vrothberg]

The end goal should be to show the prompt on the remote client [...]

I think that's only attractive at first glance. All endpoints that may be pulling an image would have to support prompting. It pretty much excludes the Docker compat endpoints and all clients other than podman-remote.

While I think it would be nice if podman-remote would support prompting, it would be a huge challenge to get it to work while excluding many other use cases.

I truly believe the server must be correctly configured which in your example, as you mentioned, is not the case when running in the background.

The reason I run into this is because I usually run the server process in the background with podman system service -t0 &. The problem is that the remote client will just hang until you select the registry on the server. The user does not know why it is hanging or what he needs to do to solve it.

Yes, that's bad. The background service can still access the TTY but it's clearly not intended to be interactive.

The end goal should be to [...] or if not possible to fail.

IMHO prompting is not a viable option and we should fail. The prompt could time out (e.g., after 30 seconds) and fail.

@mtrmac what do you think?

[rhatdan]

We should separate out the two discussions. The server side should not be prompting on setting the flag to prompt, since it makes no sense there.
Currently I agree on no prompting on remote, although it certainly would be a nice feature to get. But wouldn't it require new APIs?

[vrothberg]

The server side should not be prompting on setting the flag to prompt, since it makes no sense there.

That's partly up the user. In permissive mode and when having access to a TTY, the prompt will be shown. There isn't much the server can do to prevent that scenario. But I think the server should error out after a given time out.

Currently I agree on no prompting on remote, although it certainly would be a nice feature to get. But wouldn't it require new APIs?

I think we could find a way to opt-in to using the prompt and not break the API (or require new endpoints) but it would be herculean task to get it done. There are so many APIs that may be pulling an image.

[mtrmac]

The server side should not be prompting on setting the flag to prompt, since it makes no sense there.

That's partly up the user. In permissive mode and when having access to a TTY, the prompt will be shown. There isn't much the server can do to prevent that scenario. But I think the server should error out after a given time out.

A daemon could easily close its TTYs, that’s actually expected behavior (compare daemon(3)). Is there any scenario in which that isn’t the right thing to do?

Currently I agree on no prompting on remote, although it certainly would be a nice feature to get. But wouldn't it require new APIs?

I think we could find a way to opt-in to using the prompt and not break the API (or require new endpoints) but it would be herculean task to get it done. There are so many APIs that may be pulling an image.

I mean, this was known during the original design discussions. When the decision was to proceed and handle the local case first, I didn’t think it meant “give up on the remote case altogether”.

IMHO a fairly reasonable way to handle this is to introduce an “this is a short name and you must make a choice from $alternatives” error in the API, have the server return this on short name pulls, and let the caller retry with a full name of choice. That would require a single change in the server; client call sites would all have to be wrapped/implemented, but that can be done slowly over time starting from the most important ones. (The build API is probably the most problematic in any model.) Original Docker clients wouldn’t handle that, but, shrug, users of that can, I suppose, opt in into the insecure projectatomic/docker model if they must continue to use old clients.

[vrothberg]

#8717 fixed it, closing