Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client/updater design: mirror config redesign #1143

Closed
jku opened this issue Sep 14, 2020 · 2 comments
Closed

client/updater design: mirror config redesign #1143

jku opened this issue Sep 14, 2020 · 2 comments
Labels
client Related to the client (updater) implementation

Comments

@jku
Copy link
Member

jku commented Sep 14, 2020

This is a future wishlist item for client API (#1135), based on working on pip integration. I'm not sure what exactly should happen here, just documenting the issues

Warehouse may be an unusal setup but here's how it works (using server names of the pypi instance as examples):

Issues encountered while implementing a client for this:

  • There's no way in the client mirror config to say "this server has no metadata: don't request from here" (Updater: mirrors configuration tweaks #1079)
  • confined_target_dirs seems useless: it is not possible to use e.g. "packages/" or "simple/" as a confining directory in the above target file example because only files directly under those directories would then be accepted

This could be fixed in TUF... but reality is that pip does not really need a mirror config: it always knows which server it wants to use for a particular download. With current API this means I will end up storing two mirror configurations and choosing the correct one every time before a download happens.

jku pushed a commit to jku/pip that referenced this issue Sep 14, 2020
Current TUF Updater mirror config means queries to the wrong server:
theupdateframework/python-tuf#1143

Workaround by storing two separate mirror configurations: one for
index file downloads and one for distribution file downloads.
@joshuagl joshuagl added the client Related to the client (updater) implementation label Sep 21, 2020
@joshuagl joshuagl added this to the Client Refactor milestone Sep 21, 2020
jku pushed a commit to jku/pip that referenced this issue Oct 2, 2020
Current TUF Updater mirror config means queries to the wrong server:
theupdateframework/python-tuf#1143

Workaround by storing two separate mirror configurations: one for
index file downloads and one for distribution file downloads.
@jku
Copy link
Member Author

jku commented Oct 2, 2020

This could be fixed in TUF

After further meditation: this particular issue cannot be fixed in TUF client. Even if confined_target_dirs allowed subdirectory matching, pip could not use them to separate index files and distribution files: The directory names "simple" and "packages" are just implementation details of pypi.org, not part of the Warehouse API. Some other instance might use the same directory name on both servers.

This is essentially a result of not namespacing the target names of index files and distribution files in the Warehouse TUF implementation: it is impossible to tell the two targets apart without some heuristics.

jku pushed a commit to jku/pip that referenced this issue Oct 21, 2020
Current TUF Updater mirror config means queries to the wrong server:
theupdateframework/python-tuf#1143

Workaround by storing two separate mirror configurations: one for
index file downloads and one for distribution file downloads.
@sechkova sechkova mentioned this issue Mar 4, 2021
17 tasks
@jku
Copy link
Member Author

jku commented May 19, 2021

Mirrors have been annihilated in new client:

  • Metadata is only downloaded from one host
  • For targets, caller can give Updater a default download url prefix, and can override it case-by-case when calling download_target

@jku jku closed this as completed May 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client Related to the client (updater) implementation
Projects
None yet
Development

No branches or pull requests

2 participants