The create container dialog should accept a full "container url"

[jelly]

Some registries do not support searching as this is not a mandatory feature, as we build our "create container" dialog around searching we should allow users to input a full container url for example ghcr.io/github/pages-gem.

This now fails and shows an ugly error:

Reproducer:

• Click create new container
• As Image input: ghcr.io/github/pages-gem
• Try to create the container without the dropdown clearing the input field

Proposed solution

When a user provides a full container url, try to not search or if that's too complicated and search fails show a warning not an error. Also try to not show the dropdown with "no images found" as that is rather confusing.

Alternatively we need to make our download new image dialog prominent but to me that feels like adding some ducktape and working around the issue.

Related to: #819

https://issues.redhat.com/browse/RHEL-13022

[garrett]

Sounds good. I think we did talk about this at once point in time (or I could be misremembering).

Suggestions would go away (as it knows there's a host) and it just uses the specified container. In other words: no autocomplete dropdown.

If there's a way to know if a container exists at the URL or not, we should show an error as helper text under the form when it doesn't. (Something like HTTP HEAD if there isn't an API for checking if it exists.) If it's fine, we could have a green checkmark circle icon and say something like "Valid container location" as helper text under the entry. If it takes a second or more, we should have a spinner.

[jelly]

I believe we talked about it during the re-design of the "Create image dialog" but never came around implementing it.

[jelly]

This issue is a bit tricky, I don't think podman has a way to detect if an remote image exists without pulling it. Which we could do in the background but that feels a bit irky.

Check if an image exists fails, but we can use this if it's already pulled. Then it returns a 204. So that's one case we should handle.

[jelle@t14s][~/Notes]%curl -v -X GET -s -g --no-buffer --unix-socket /run/user/1000/podman/podman.sock 'http://localhost/v1.12/libpod/images/ghcr.io/github/pages-gem/exists'
*   Trying /run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /v1.12/libpod/images/ghcr.io/github/pages-gem/exists HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Api-Version: 1.41
< Content-Type: application/json
< Libpod-Api-Version: 4.4.3
< Server: Libpod/4.4.3 (linux)
< X-Reference-Id: 0xc0006bd778
< Date: Thu, 30 Mar 2023 09:50:58 GMT
< Content-Length: 131
<
{"cause":"failed to find image ghcr.io/github/pages-gem","message":"failed to find image ghcr.io/github/pages-gem","response":404}
* Connection #0 to host localhost left intact

Ideally this behaviour would not happen:

[jelly]

Seems we can use something similiar to skopeo manifest inspect docker://fo or podman manifest inspect ghcr.io/github/pages-gem. Gives a simple 404 or 200 or 500. As a check when we have a well formed container url (that will require some regex for validation)

https://samanpavel.medium.com/three-ways-to-check-a-docker-image-exists-in-registry-649eff4aef39

And using the API, it is a bit slow so probably requires a spinner somewhere?

[jelle@t14s][~]%curl -v -X GET -s -g --no-buffer --unix-socket /run/user/1000/podman/podman.sock 'http://localhost/v1.12/libpod/manifests/ghcr.io/github/pages-gem/json'
*   Trying /run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /v1.12/libpod/manifests/ghcr.io/github/pages-gem/json HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Api-Version: 1.41
< Content-Type: application/json
< Libpod-Api-Version: 4.4.3
< Server: Libpod/4.4.3 (linux)
< X-Reference-Id: 0xc000694210
< Date: Thu, 30 Mar 2023 10:25:01 GMT
< Content-Length: 104
<
{"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","manifests":null}
* Connection #0 to host localhost left intact
[jelle@t14s][~]%curl -v -X GET -s -g --no-buffer --unix-socket /run/user/1000/podman/podman.sock 'http://localhost/v1.12/libpod/manifests/ghcr.io/github/pages-gemgg/json'
*   Trying /run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /v1.12/libpod/manifests/ghcr.io/github/pages-gemgg/json HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Api-Version: 1.41
< Content-Type: application/json
< Libpod-Api-Version: 4.4.3
< Server: Libpod/4.4.3 (linux)
< X-Reference-Id: 0xc0000141a8
< Date: Thu, 30 Mar 2023 10:25:13 GMT
< Content-Length: 251
<
{"cause":"Requesting bearer token: invalid status code from registry 403 (Forbidden)","message":"reading image \"docker://ghcr.io/github/pages-gemgg:latest\": Requesting bearer token: invalid status code from registry 403 (Forbidden)","response":404}
* Connection #0 to host localhost left intact
[jelle@t14s][~]%curl -v -X GET -s -g --no-buffer --unix-socket /run/user/1000/podman/podman.sock 'http://localhost/v1.12/libpod/manifests/ghcr.io/github/pages-gem/json'
*   Trying /run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /v1.12/libpod/manifests/ghcr.io/github/pages-gem/json HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Api-Version: 1.41
< Content-Type: application/json
< Libpod-Api-Version: 4.4.3
< Server: Libpod/4.4.3 (linux)
< X-Reference-Id: 0xc00074eb48
< Date: Thu, 30 Mar 2023 10:25:17 GMT
< Content-Length: 104
<
{"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","manifests":null}
* Connection #0 to host localhost left intact
[jelle@t14s][~]%curl -v -X GET -s -g --no-buffer --unix-socket /run/user/1000/podman/podman.sock 'http://localhost/v1.12/libpod/manifests/docker.io/grafana/grafana/json'
*   Trying /run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /v1.12/libpod/manifests/docker.io/grafana/grafana/json HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Api-Version: 1.41
< Content-Type: application/json
< Libpod-Api-Version: 4.4.3
< Server: Libpod/4.4.3 (linux)
< X-Reference-Id: 0xc0006763f0
< Date: Thu, 30 Mar 2023 10:26:47 GMT
< Content-Length: 773
<
{"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.list.v2+json","manifests":[{"mediaType":"application/vnd.docker.distribution.manifest.v2+json","size":2207,"digest":"sha256:0f937ad695e3dd2029d111003d29d789c0ee06af3043b18c3010dffaf7db1366","platform":{"architecture":"amd64","os":"linux"}},{"mediaType":"application/vnd.docker.distribution.manifest.v2+json","size":2202,"digest":"sha256:6f5f0b6c261b9613abdb76a59857a85500a8bfe79ac3bcdc3f6009b2e899c515","platform":{"architecture":"arm64","os":"linux","variant":"v8"}},{"mediaType":"application/vnd.docker.distribution.manifest.v2+json","size":2202,"digest":"sha256:28d962ee48c9bb64af25a73499ecde8a6763621fd8482dbfba5af4f5adf866c6","platform":{"architecture":"arm","os":"linux","variant":"v7"}}]}
* Connection #0 to host localhost left intact

So to sum it up:

• Detect that an image has a full image url, what are valid options? Probably domain:port/whatever
• Fix that giving a full url which already exists locally should not give an error or show the dropdown it should be selected. Can be verified with /images/{name}/exists.
• Allow inputting a full url and then don't search for it. Or do we still? As it does show up:
• (Ab)Use the manifests API to figure out if an image exists
• Also how do we test this? We need to configure the registry container to disable the search API

[bc1bb]

Hi,

I +1 with this, currently, we can't pull ghcr.io's from Cockpit, is there any ETA on this ?

[podhorsky-ksj]

Workaround is download it with command line in cockpit manually as podman pull

I already gave up waiting and moved to podman quadlet files. They are better.

[bc1bb]

Oh well I ended up making a docker-compose.yml and start it with podman-compose, I guess this was an easier solution

[garrett]

@podhorsky-ksj, @bc1bb: BTW, there's podlet, which makes quadlet files from other formats (command line arguments, compose files, kube play files, etc.): https://github.com/containers/podlet

[podhorsky-ksj]

I know, I used it at the beginning. I like quadlet files, because of execstartpre/execstartpost, auto updates of containers, dependencies between containers. But I don't like you are not able to disable container from start, like you can on systemd unit files. Once quadlet file is in exact location, it will be run on startup.