Warn if registries.conf contains config keys the consumer does not intend to use

[brurucy]

Feature request description

Assume that the following can be found at $HOME/.config/containers/registries.conf, on macOS:

unqualified-search-registries = ['docker.io']

[[registry]]
prefix = "docker.io"
location = "docker.io"

[[registry.mirror]]
location = "<some-mirror-location>"

Running podman pull --log-level=debug <repo>/<image> yields the following:

INFO[0000] /$HOME/<podman-bin-path>/podman filtering at log level debug
DEBU[0000] Called pull.PersistentPreRunE(/$HOME/<podman-bin-path>/podman --log-level=debug pull <repo>/<image>)
DEBU[0000] DoRequest Method: GET URI: http://d/v4.4.2/libpod/_ping
DEBU[0000] Loading registries configuration "/$HOME/.config/containers/registries.conf"
DEBU[0000] DoRequest Method: POST URI: http://d/v4.4.2/libpod/images/pull
Resolving "<repo>/<image>" using unqualified-search registries (/etc/containers/registries.conf.d/999-podman-machine.conf)
Trying to pull docker.io/<repo>/<image>:latest...
Error: initializing source docker://<repo>/<image>:latest: reading manifest latest in docker.io/<repo>/<image>: requested access to the resource is denied
DEBU[0003] Shutting down engines

Notice how misleading it is to print out that: DEBU[0000] Loading registries configuration "/$HOME/.config/containers/registries.conf"

When on macOS, that is entirely ignored, that is, it will only work as intended, if the user creates a machine with that folder mounted on by default.

Suggest potential solution

To either:

1. Provide a flag, that will mount $HOME/.config/containers when creating a machine, providing the same behaviour across linux and Mac
2. Add a warning, or fix the debug print, that on Mac, that file is not taken into account

Have you considered any alternatives?

Yes. The alternative is to simply create a machine mounting $HOME//.config/containers, however, there doesn't seem to be explicit documentation about this. It took a lot of head-banging to figure out that registries.conf just isn't taken into account for Mac.

Additional context

I'm fine with tackling either of the solutions I've proposed, but I think that the second one might be easier and faster to put out.

[baude]

@rhatdan i know we went around and around on this topic of where do containers-common configuration files land like this. As the user reports, I agree it is unclear. Logically, if we support containers.conf in the macos filesystem, seems we ought to for registries.conf?

[baude]

btw, @brurucy excellent writeup. Thank you for taking the time to do so.

[vrothberg]

It's technically not possible to support registries.conf for remote clients since the images are pulled on the server side.

I think we should erase the code paths that lead to the config being loaded on the client side to get rid of the logs.

[rhatdan]

Agreed can not do this on the client side.

[Luap99]

Even for containers.conf most options will only be read on the server side. Only exception is the [machine] section the system connections, I am sure there might be some small others but generally speaking defaults should always come from the server: containers/podman@9770947

[vrothberg]

I had a look at the exact call path and found that registries.conf is actually being used by remote clients but only for authentication, the credential-helpers in particular. So we cannot get rid of loading these files, nor of the debug log.

So I want to move the conversation into the direction of how to avoid users from thinking other fields (e.g., registries) could be set on the Mac. Cc: @mtrmac

Should Podman be able to specify a slice of supported keys and sysregistriesv2 would bark when other keys are loaded?

[mtrmac]

Something like that would be possible, and it would make sense for configs built from scratch.

Consider a Linux system, with all the default configs set up for local use of Podman, running podman machine. Does it make sense to warn in that case?

---

Implementation: right now, sysregistriesv2 hides the actual config file load behind a fair amount of layers (caching, pre-processing, …). I’m not sure whether we want to re-load all of the data just to emit a warning, which would be the simplest way to implement this very local concern, without having to make this visible in SystemContext for all users.

[vrothberg]

Consider a Linux system, with all the default configs set up for local use of Podman, running podman machine. Does it make sense to warn in that case?

Maybe a debug log plus some doc/man page changes would improve the situation?

I’m not sure whether we want to re-load all of the data just to emit a warning, which would be the simplest way to implement this very local concern, without having to make this visible in SystemContext for all users.

We could cache the specified keys to avoid reloading.

[mtrmac]

… actually we probably can just read the cache for the warning.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg @mtrmac Should this be fixed in containers/image or Podman

[vrothberg]

In c/image