Bug #37279
closedIt is possible to end up with the wrong remote type (uln vs. normal) for yum content
Description
When syncing yum content from upstream ULN servers, a different type of pulp_rpm remote must be used. The different remote types can be identified via their href's as follows:
```
/pulp/api/v3/remotes/rpm/rpm/...
/pulp/api/v3/remotes/rpm/uln/...
```
When updating a remote in a way that requires switching the remote type between uln and normal, Katello does not currently do so, and Pulp will not throw an error. The result will be a uln remote with data for a normal rpm sync, or vice versa. This will result in failed syncs.
Example reproducer workflow:
- Create a yum type repo with any repo URL, e.g.: `https://fixtures.pulpproject.org/rpm-signed/` * Check to see that the Katello repository created references a remote href beginning with `/pulp/api/v3/remotes/rpm/rpm/...`
- Now switch the URL to for example `uln://ol8_x86_64_oracle_instantclient` (you will also need to set login credentials but just set anything, we don't actually need to sync to see the problem) * Check the Katello repo again. It will still use the exact same rpm remote as before.
- Check the pulp_rpm remote with `pulp show --href <remote_href>`. * You will see that the rpm (not uln) type remote now has `"url": "uln://ol8_x86_64_oracle_instantclient"`. This cannot work for syncing!
PR to follow shortly.
Updated by The Foreman Bot 9 months ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/Katello/katello/pull/10942 added
Updated by Quirin Pamp 7 months ago
Note: I also created a pulp_rpm issue, to have Pulp add validation that throws a meaningful error at remote creation time, rather than a cryptic one at sync time, should we ever get this wrong again in the future: https://github.com/pulp/pulp_rpm/issues/3520
Updated by Quirin Pamp 7 months ago
- Status changed from Ready For Testing to Closed
Applied in changeset katello|97f8a09c3338b702c1d2735318e8c5e3b1b6b953.