RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1976283 - podman search does not return an exact match
Summary: podman search does not return an exact match
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: podman
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: beta
: ---
Assignee: Jindrich Novy
QA Contact: Yuhui Jiang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-25 16:52 UTC by Fernando Lozano
Modified: 2021-11-09 19:44 UTC (History)
12 users (show)

Fixed In Version: podman-3.2.3-0.6.el8 or newer
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-09 17:38:44 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:4154 0 None None None 2021-11-09 17:39:21 UTC

Description Fernando Lozano 2021-06-25 16:52:56 UTC 
Description of problem:

I tested against quay.io but I assume I'd get similar results from other registry server.

I have a public image that's the sampe app from a very popular blog post in Red Hat Developers
https://quay.io/repository/flozanorht/php-ubi

But if I search for its complete and exact name, that is "flozanorht/php-ubi", podman search does not list it as part of the search results.

Version-Release number of selected component (if applicable):


How reproducible:
Always (with that specific image) but the failure may show or not for other images

Steps to Reproduce:
1. podman search quay.io/flozanorht/php-ubi
2.
3.

Actual results:
flozanorht/php-ubi is nowhere in the search results.


Expected results:
flozanorht/php-ubi is among the first results


Additional info:

Maybe there's no possible fix from the podman side, as a client to registry servers, but at least documentation should be explicit about how search results are underfined and might not return what you'd expect.

The fact that I cannot trust search results and cannot find any info about how they are sorted and how the search term is matched makes the search feature useless and may trick customers into believing that content does not exist.

After a thread in the containers-tech mailing lust (subject: "What's wrong with podman search on quay.io?") it looks that there's no real spec about how search works, it is server-dependent, and actually a "hack" against any server except for servers using the obsolete registry v1 API. It might only provide any consistent results for docker.io and not for anything else.

Having that feature available and documented without warnings about what can be expected -- and cannot be --- is a disservice to customers. At minimum podman man page and RHEL product docs should be very clear that search might not work as you'd expect and search results might not include what you'd intuitively believe are the best matches.
Comment 1 Tom Sweeney 2021-06-28 17:16:09 UTC 
Valentin,

Could you take a look at this please?  This smells like it might be related to the registries.conf issue you're hunting down.
Comment 2 Fernando Lozano 2021-06-28 20:06:51 UTC 
Just to highlight that my sample search specifies the registry, so registry.conf search path should not make a difference. In my environment, it is the installation default of RHEL 8.4.
Comment 3 Valentin Rothberg 2021-06-29 07:28:52 UTC 
Thanks for pulling me in.  We talked about this issue on the containers-tech list already and there is nothing much Podman can do.  Podman sends the search term verbatim to the registry and presents the results as returned by the registry. The output of Podman and Docker is identical.

I agree that this should be mentioned in the documentation.

@Tom: How shall we proceed?  I can open a PR upstream for the man pages but shall I backport it to specific releases?  Shall we pull in the docs team?
Comment 5 Tom Sweeney 2021-06-29 19:09:47 UTC 
Valentin, I'll take the chicken's way out and will let @gnecasov decide the best way to document this.  It would be nice to get into RHEL 8.4.0.2 if we can, but certainly RHEL 8.5.  Gabi?
Comment 6 Fernando Lozano 2021-06-29 19:24:02 UTC 
Did I get it wrong that, for registry V2+ compliant registry servers, podman does the filtering on the client side? If true, it is not just about sending the "search term verbatim to the registry" but that would apply only to registry servers that implement the old, deprecated v1 registry API and I guess that would apply only to docker.io.
Comment 7 Valentin Rothberg 2021-06-30 09:05:40 UTC 
(In reply to Fernando Lozano from comment #6)
> Did I get it wrong that, for registry V2+ compliant registry servers, podman
> does the filtering on the client side? 

That's correct.  v1 is server-side, v2 "catalog" is client-side but extremely slow so Podman (and others) prefer the v1/search if supported by the registry.

> If true, it is not just about sending
> the "search term verbatim to the registry" but that would apply only to
> registry servers that implement the old, deprecated v1 registry API and I
> guess that would apply only to docker.io.

Quay.io allows supports v1/search.
Comment 8 Gabriela Nečasová 2021-06-30 14:55:09 UTC 
Tom, thank you for notifying me. Yes, I can update docs, when the issue will be resolved.
Comment 9 Fernando Lozano 2021-06-30 15:32:53 UTC 
(In reply to Valentin Rothberg from comment #7)
> > Did I get it wrong that, for registry V2+ compliant registry servers, podman
> > does the filtering on the client side? 
> 
> That's correct.  v1 is server-side, v2 "catalog" is client-side but
> extremely slow so Podman (and others) prefer the v1/search if supported by
> the registry.

Maybe we need a way to force one or the other (v1 search vs v2 catalog) and also a way of knowing what happened at runtime (client or server-side filtering) without turning on full debug output?

Anyway these possibilites, and the implications of each, should be documented in the podman search man page and RHEL product docs.

I still see no way of ensusing search results include an exact match, or the closest match (whatever that means) for any registry. IMHO this has to be clear and explict. Users should know what to expect, or in this case what not to expect... and be advised to use the interactive web search of each registry server, like Red Hat Marketplace, instead of podman search.


> 
> > If true, it is not just about sending
> > the "search term verbatim to the registry" but that would apply only to
> > registry servers that implement the old, deprecated v1 registry API and I
> > guess that would apply only to docker.io.
> 
> Quay.io allows supports v1/search.

Isn't v1 deprecated and about to be removed from quay?

What's the approach from other registries such as Nexus, GitHub, Google, etc?

Isn't the assumption of using v1/search when available something that would apply just to docker.io?
Comment 10 Tom Sweeney 2021-06-30 19:14:34 UTC 
Valentin, PTAL at https://bugzilla.redhat.com/show_bug.cgi?id=1976283#c9
Comment 11 Valentin Rothberg 2021-07-01 08:24:50 UTC 
(In reply to Fernando Lozano from comment #9)
> [...]
> Maybe we need a way to force one or the other (v1 search vs v2 catalog) and
> also a way of knowing what happened at runtime (client or server-side
> filtering) without turning on full debug output?
> 
> Anyway these possibilites, and the implications of each, should be
> documented in the podman search man page and RHEL product docs.

I agree.  Let's start with docs.

> [...]
> Isn't v1 deprecated and about to be removed from quay?

I do not know of that plan.  Once the endpoint is gone, Podman would use v2/catalog.

> What's the approach from other registries such as Nexus, GitHub, Google, etc?

catalog is not part of the OCI distribution spec [1], so I assume that some registries may chose not to support such a feature at all.

[1] https://github.com/opencontainers/distribution-spec/blob/main/spec.md#endpoints
Comment 12 Fernando Lozano 2021-07-02 21:41:42 UTC 
JFYI there's a bug for quay because I believe it has it's own search issues, not necessarily related to the discussion about how podman should handle and document them:
https://issues.redhat.com/browse/PROJQUAY-2165
Comment 13 Valentin Rothberg 2021-07-06 06:59:05 UTC 
The following upstream extending the man pages has been merged: https://github.com/containers/podman/pull/10842

Assigning the bug to Gabi: Gabi, can you add the information mentioned in the PR to the RHEL docs?
Comment 24 errata-xmlrpc 2021-11-09 17:38:44 UTC 
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-2021:4154
Note You need to log in before you can comment on or make changes to this bug.