Replies: 2 comments 3 replies
-
I would probably word this as something like "the client may choose to adopt the given namespace registry mappings temporarily (for the current operation) or permanently". A general-purpose tool might choose to only consider mappings that come from its "home" / default registry, and possibly with some configurability (never/always/prompt). |
Beta Was this translation helpful? Give feedback.
-
|
I believe this should only apply to "top-level" queries, right? If a client is fetching dependencies then it should expect the top-level package's origin registry to serve all dependencies directly. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Proposing a new
Warg-Registry-Hintresponse header that clients may use to make further requests with theWarg-Registryrequest header. Just for the response ofPOST /v1/fetch/logsAPI endpoint.For namespaces not defined in the operator log, the client should still attempt to fetch those logs from the registry. If the registry responds with one or more
Warg-Registry-Hintheaders of the form,Warg-Registry-Hint: <namespace>=<hostname>, then the client may choose to adopt the given namespace registry mappings temporarily (for the current operation) or permanently, proceeding with subsequent fetch logs requests using theWarg-Registry: <hostname>request header for the respective<namespace>.This would be a non-breaking, additive change. Only clients that looked for the
Warg-Registry-Hintheader would adopt the behavior. It is a way of addressing usability concerns when users are trying to download packages that are known to a Warg registry service but aren't yet apart of the operator log namespace imports.Beta Was this translation helpful? Give feedback.
All reactions