I'm seeing the same behavior in `docker search` from upstream Docker except that if you specify more than 100, it tells you you're out of range.  I think adding at least an error would be good to emulate Docker.
Dan, what do you think about doing more?

Sure lets just check to make sure that --limit X X can not be greater then 100, if that is all registries will return.

Qi can you take care of this please?  We'll just need to add a warning message when we find more than 100 entries.

(In reply to Tom Sweeney from comment #4)
> Qi can you take care of this please?  We'll just need to add a warning
> message when we find more than 100 entries.

ok, will work on this.

@Daniel, Tom and Qi,

as I understand, there currently is a limiting the number of shown entries and I was wondering if that would lead to items/results/images never shown?

Is the number returned by the various registries fixed at 100 or is it flexible and can vary?

Johannes,

My understanding is registries are currently fixed at 100 entries returned from a search.  Dan Walsh might have a better understanding and will change my thinking.

Miloslav or Valentin would know better then me.

Just to be clear, the ask is that podman follows the Link header, which is effectively adding pagination support.  Currently, with podman and registry.fedoraproject.org, doing a search hits the /v2/_catalog API endpoint and returns 100 results and a link to the next page of results.  By default, podman only shows the first 25 results.  If the user specifies 'podman search --limit 200 ...' today the limit allows us to display 200 results, but we only ever read in 100 from the server.  

Also, the registry will accept a value for the number of results to return at once, and if you pass 200 (curl -L https://registry.fedoraproject.org/v2/_catalog?n=200) it will return all ~130 results at once (with no paging needed).

Mitr, what do you think of passing this onto containers/image?

Sure, c/image should add support for pagination. Separately, we should consider whether “give me unlimited number of results” should be possible, and if so, both Podman and c/image need updating.

As a user I would be very surprised at how limited this is.  Finding a few thousand images, should not be out of the question.

The “catalog” API is IMHO unreasonable (download the full list of repositories to the client, and then search locally) for large registries where thousands of images may exist, and pagination does little to fix that. (And it’s unclear to me what the user would do with thousands of images — substring search seems risky for any kind of automated processing.) Still, sure, it’s better to implement a suboptimal API than not to have that functionality.

Qi any movement on this?

(In reply to Daniel Walsh from comment #15)
> Qi any movement on this?

containers/image should provide an API, I will add this to my list.

From https://bugzilla.redhat.com/show_bug.cgi?id=1866153#c2 it sounds like this bug might also be fixed (assuming it made it into podman-2.0.5)


Looking upstream

$ git checkout v2.0.5
Note: switching to 'v2.0.5'.

[...]

HEAD is now at 776abc521 Bump to v2.0.5


$ git log 524ae12977 -1
commit 524ae12977d3eb93bd8b2eac4a15c84a05a66dbb
Author: Valentin Rothberg <rothberg>
Date:   Tue Aug 18 16:19:59 2020 +0200

    vendor c/image v5.5.2
    
    Enable pagination until the search result reaches the limit, instead of
    returning default 100 limit from registry API.
    
    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1866153
    Signed-off-by: Valentin Rothberg <rothberg>



Seems like both of these bugs would be fixed by an update to 2.0.5

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: container-tools:rhel8 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4694