moby
Move filtered registry search out of the image service
- Related to #44032
Move filtered registry search logic out of the image service as querying a remote registry is unrelated to the functionality of the image service. Move the logic into the registry service as it is the source of truth for the registry configuration, which makes it the most cohesive place to put it which does not require more extensive refactoring.
I'm leaning towards keeping this more separate from the registry; "search" is a bit of an odd one, because search is not part of the OCI distribution specification.
Search was implemented in "docker registry v1" (the Docker Index (hence index.docker.io), which later became Docker Hub). When the registry V2 specification was created (which became the OCI Distribution Spec), search was deliberately left out of the implementation, because indexing and searching content was a separate concern, and it became clear that "what can be searched", "how" can be searched (and what properties to search for) could be very opinionated (different providers could have different things to search for).
So search did not become part of the OCI specs.
The search functionality in the daemon is still in place mostly for backward compatibility, and because the old (v1) search API is the only documented search API, so some other registry implementations also added support for it (by lack of other specifications for searching).
That said; some registries (including Docker Hub) provide other (more advanced) search functionality, and there's been some talk about defining a OCI spec for searching/indexing (not sure if that ever got actual progress though).
With the above in mind, I'd like to keep it separate with the potential to;
- Allow other implementations to be added (haven't given this much thought, but somehow making it pluggable?)
- (there's been various discussions about "better search" for images on Docker Hub at least; Docker Hub already has V2 and V3 search engines, which could provide some of that, but not sure if their API is publicly documented).
- Probably for backward-compat, the "fallback" would be to use the V1 search
In either case; my thinking was to "try to keep it as isolated as possible"
I'm leaning towards keeping this more separate from the registry; "search" is a bit of an odd one, because search is not part of the OCI distribution specification.
The search interface is separated from the image distribution interface. The implementation is tied to the registry service, but that was already the case. Think of this PR as more of "getting search out of the wrong place to unblock containerd integration" than "getting search into the perfect place." We can still make #44032 happen; this PR just takes the pressure off.