feat: Implement autoupdate endpoint in libpod REST API

[StefanNienhuis]

This PR implements a new libpod REST API endpoint providing the autoupdate functionality, as it is included in the podman CLI. It accepts the same options as the CLI version. The end goal of this is to allow applications, such as cockpit-podman, to perform container updates in a similar manner to what is possible with the CLI.

This PR also modifies the swagger-check script. Since the endpoint is /libpod/autoupdate, the linter expected the response to be named autoupdateListResponse. The name autoupdateResponse made more sense in my mind so I added an exception for this in the swagger-check script. If this is not intended, I can remove it and use the suggested name instead.

Does this PR introduce a user-facing change?

Added auto update endpoint to the REST API

[StefanNienhuis]

Regarding tests, this will require running a container from a systemd unit and performing tests on the api. Is this currently supported in the test system, and if so, can someone with more knowledge of the project point me in the right direction?

[Honny1]

The simplest way to test this feature is by adding an auto-update capability to the remote client and then enabling the test for it.

Remote client code

[Luap99]

I agree with podman-remote we can reuse the existing tests, and podman-remote used the remote APi so that is tested as well.

There are api only tests in test/apiv2 but there is no good way to run systemd unit containers there at the same time so I would definitely prefer the podman-remote option.

[StefanNienhuis]

These changes implement autoupdate support for podman-remote. Using the existing test for this is a good idea I think. Looking through the test file it interacts with systemd, but wouldn't these commands be executed on the client side?

If not, is it enough to just remove the skip_if_remote statement in the setup?

[Luap99]

If not, is it enough to just remove the skip_if_remote statement in the setup?

yes removing the skip_if_remote will make the test run via podman-remote. And yeah systenctl command are still local but we only test these tests locally so remote and server are the same system so that should work fine.

One note though the podman-auto-update --authfile will need the skip_if_remote now though as the local registry only work with the local podman.

[StefanNienhuis]

If not, is it enough to just remove the skip_if_remote statement in the setup?

yes removing the skip_if_remote will make the test run via podman-remote. And yeah systenctl command are still local but we only test these tests locally so remote and server are the same system so that should work fine.

Okay, that's good.

One note though the podman-auto-update --authfile will need the skip_if_remote now though as the local registry only work with the local podman.

Not exactly sure what you mean here. I took some inspiration from here to add the registry auth to the request. I see now that I don't handle this in the api endpoint like here. I assume I'll need to add that in and would that not make the test case work too?

[Luap99]

One note though the podman-auto-update --authfile will need the skip_if_remote now though as the local registry only work with the local podman.

Not exactly sure what you mean here. I took some inspiration from here to add the registry auth to the request. I see now that I don't handle this in the api endpoint like here. I assume I'll need to add that in and would that not make the test case work too?

podman/test/system/255-auto-update.bats

Line 648 in 9f7c6c3

start_registry

start_registry will only ever work locally, so this test needs skip_if_remote for just that one test, i.e. compare

podman/test/system/156-pull-policy.bats

Lines 5 to 7 in 9f7c6c3

	@test "podman pull with policy flag" {
	skip_if_remote "tests depend on start_registry which does not work with podman-remote"
	start_registry

[StefanNienhuis]

Apologies for the delay, I had a few busy weeks. Last three commits do the following:

• Use authfiles from the client machine, like is done for other remote commands.
  • Previously it would take the path from the client and attempt to find a file on the server, now it actually takes the authfile on the client and uses the MakeXRegistryAuthHeader function to send it to the server.
• Report pull errors back to the client
  • Previously the API would only return the auto update reports, causing pull errors to not be shown on the client.
• Enable the auto update tests for podman-remote, skipping for registries as suggested.

[StefanNienhuis]

@Luap99 could you help me out with these last failing test cases? It seems to be failing on something related to the local cache registry, from the containers-cached.conf file. It is rewriting the location but it is somehow ignoring the insecure flag and the test cases fail on it being a http repository.

I do see some references like skip_if_remote "containers.conf settings not set for remote connections" in some test cases (like 150-login.bats). Could it be that the cached registry is not supported for podman-remote?

[Luap99]

Oh and please squash the commits into one once you are done.

[StefanNienhuis]

That seems to fix those cases. Thanks a lot!

These two failing test cases seem unrelated to this PR. Is that right?

[Luap99]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, StefanNienhuis

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99]

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

[Luap99]

machines tests are quite flaky I restarted them they are definitely unrelated to your changes.

[StefanNienhuis]

Okay. I rebased on main. Not really familiar with the PR process here, but looking through the document linked by the bot it seems I need a LGTM from someone?

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[StefanNienhuis]

Now all systemd units are failing to start. Can't reproduce it when running tests locally though.

[Luap99]

We require two reviews so the second person is merging the PR normally.

Looking at the tests the big rework from #24601 likely broke it, I need to figure out how to deal with that