Files
podman/test/apiv2
Valentin Rothberg 5bdd571b1e compat API: allow enforcing short-names resolution to Docker Hub
The Docker-compatible REST API has historically behaved just as the rest
of Podman and Buildah (and the atomic Docker in older RHEL/Fedora) where
`containers-registries.conf` is centrally controlling which registries
a short name may resolve to during pull or local image lookups.  Please
refer to a blog for more details [1].

Docker, however, is only resolving short names to docker.io which has
been reported (see #12320) to break certain clients who rely on this
behavior.  In order to support this scenario, `containers.conf(5)`
received a new option to control whether Podman's compat API resolves
to docker.io only or behaves as before.

Most endpoints allow for directly normalizing parameters that represent
an image.  If set in containers.conf, Podman will then normalize the
references directly to docker.io.  The build endpoint is an outlier
since images are also referenced in Dockerfiles.  The Buildah API,
however, supports specifying a custom `types.SystemContext` in which
we can set a field that enforces short-name resolution to docker.io
in `c/image/pkg/shortnames`.

Notice that this a "hybrid" approach of doing the normalization directly
in the compat endpoints *and* in `pkg/shortnames` by passing a system
context.  Doing such a hybrid approach is neccessary since the compat
and the libpod endpoints share the same `libimage.Runtime` which makes
a global enforcement via the `libimage.Runtime.systemContext`
impossible.  Having two separate runtimes for the compat and the libpod
endpoints seems risky and not generally applicable to all endpoints.

[1] https://www.redhat.com/sysadmin/container-image-short-names

Fixes: #12320
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
2021-11-30 14:22:52 +01:00
..
2020-01-17 09:59:22 -07:00
2021-08-02 13:27:49 -04:00
2021-03-15 15:27:06 -06:00
2021-09-15 20:01:02 +02:00

API v2 tests

This directory contains tests for the podman version 2 API (HTTP).

Tests themselves are in files of the form 'NN-NAME.at' where NN is a two-digit number, NAME is a descriptive name, and '.at' is just an extension I picked.

Running Tests

The main test runner is test-apiv2. Usage is:

$ sudo ./test-apiv2 [NAME [...]]

...where NAME is one or more optional test names, e.g. 'image' or 'pod' or both. By default, test-apiv2 will invoke all *.at tests.

test-apiv2 connects to localhost only and via TCP. There is no support here for remote hosts or for UNIX sockets. This is a framework for testing the API, not all possible protocols.

test-apiv2 will start the service if it isn't already running.

Writing Tests

The main test function is t. It runs curl against the server, with POST parameters if present, and compares return status and (optionally) string results from the server:

t GET /_ping 200 OK
  ^^^ ^^^^^^ ^^^ ^^
  |   |      |   +--- expected string result
  |   |      +------- expected return code
  |   +-------------- endpoint to access
  +------------------ method (GET, POST, DELETE, HEAD)


t POST libpod/volumes/create name=foo 201 .ID~[0-9a-f]\\{12\\}
       ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^^
       |                     |        |   JSON '.ID': expect 12-char hex
       |                     |        +-- expected code
       |                     +----------- POST params
       +--------------------------------- note the missing slash

Notes:

  • If the endpoint has a leading slash (/_ping), t leaves it unchanged. If there's no leading slash, t prepends /v1.40. This is a simple convenience for simplicity of writing tests.

  • When method is POST, the argument(s) after the endpoint may be a series of POST parameters in the form 'key=value', separated by spaces: t POST myentrypoint 200 ! no params t POST myentrypoint id=$id 200 ! just one t POST myentrypoint id=$id filter='{"foo":"bar"}' 200 ! two, with json t POST myentrypoint name=$name badparam='["foo","bar"]' 500 ! etc... t will convert the param list to JSON form for passing to the server. A numeric status code terminates processing of POST parameters.

  • The final arguments are one or more expected string results. If an argument starts with a dot, t will invoke jq on the output to fetch that field, and will compare it to the right-hand side of the argument. If the separator is = (equals), t will require an exact match; if ~ (tilde), t will use expr to compare.