Project

Profile

Help

Issue #6948

closed

Add a log message if the user asks for a component that does not exist

Added by msinghal over 2 years ago. Updated over 1 year ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version - Debian:
Platform Release:
Target Release - Debian:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

If user wants to add components that doesn't exist an exception should be raised.

For example,

http post :/pulp/api/v3/remotes/deb/apt/ name=tuxedo_remote distributions="bionic" components=null architectures="i386 amd64" url="http://deb.tuxedocomputers.com/ubuntu/"

Null component doesn't exist so an exception should be raised.

Actions #1

Updated by quba42 over 2 years ago

I have two comments:

First, this probably applies to the other options (architectures, distributions, etc.) as well. (It raises the larger question how much validation of user input we want to do).

The second issue is one of implementation. I think it is probably not a good idea to validate remotes right at the time of creation (It could be a plausible use case to create a remote for a upstream repository that is currently unavailable, and then to use it at a later time, and upstream repos could change). Instead, I think any validation should happen when the remote is actually used to synchronize a repository. At that point it would be nice to have clear errors explaining there is something wrong with the remote being used, rather than just creating a broken repository.

Actions #2

Updated by pulpbot over 2 years ago

  • Status changed from NEW to POST
Actions #3

Updated by quba42 over 2 years ago

  • Sprint/Milestone set to Wishlist
Actions #4

Updated by quba42 over 2 years ago

  • Sprint/Milestone deleted (Wishlist)
Actions #5

Updated by quba42 over 2 years ago

  • Sprint/Milestone set to Wishlist
Actions #6

Updated by quba42 over 2 years ago

This comment is copied from the discussion on the PR:

I have been thinking about this a bit more. For reasons of both usage and implementation I do not think asking for structured user input is practical.

The only solution I can come up with to satisfy all use cases is making the behaviour configurable (globally and/or per remote). Lets say a remote could have "strict": true or "strict": false.

A strict remote would throw a hard error whenever a remote repository is missing a distribution known to the remote, or when one of the distributions is missing a component or architecture known to the remote. A non strict remote would log a warning instead.

Personally I would vote that strict remotes are the default behaviour (since I think most users should keep their pulp repos simple (for example by keeping it one distribution per repo) and would benefit from sanity checking on the remotes they create. However, that is debatable since the non strict remote is more "liberal" in what use cases and input it accepts (https://en.wikipedia.org/wiki/Robustness_principle).

Any thoughts on the general approach?

Actions #7

Updated by quba42 over 1 year ago

  • Subject changed from Raise exception if the user asks for a component that does not exist to Add a log message if the user asks for a component that does not exist

I am amending this issue to a log message instead of an exception.

This is easy to implement right now, does not break any use cases, but provides some mitigation for the frequent occurance of users configuring invalid components and struggling to figure out what went wrong.

Added by quba42 over 1 year ago

Revision 1792ad03

Log warning if component or architecture does not exist

Closes #6948 https://pulp.plan.io/issues/6948

Actions #9

Updated by quba42 over 1 year ago

  • Status changed from POST to MODIFIED
Actions #10

Updated by quba42 over 1 year ago

  • Sprint/Milestone changed from Wishlist to 2.14.0
Actions #11

Updated by pulpbot over 1 year ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF