Bug #28555
open
enabling a repository set without providing a basearch yields unexpected results
Added by Evgeni Golov almost 5 years ago.
Updated 3 months ago.
Description
PUT /katello/api/products/:product_id/repository_sets/:id/enable does not mark
basearch as required, however, when one does enable a reposet
without providing the basearch, the repo is displayed as "noarch" in
/katello/sync_management (see attached screenshot)
the same does not happen when you enable that repo via the UI, as the UI will force the basearch to be set, even if the repository does not provide it in its substitutions
I think instead of the UI doing the injection, the API/controller should do it.
Files
- Related to Bug #25224: Some repositories from the CDN no longer has variants and repository page shows "Unspecified" added
- Related to Bug #25901: [Subscription] - Not able to add RHEL8 repositories into Katello added
- Related to Tracker #27680: API bugs that need workarounds in foreman-ansible-modules added
- Related to Bug #28644: inconsistent repository enabled state for RHEL8 repository sets in the API added
- Target version set to Katello 3.15.0
- Triaged changed from No to Yes
The inconsistency in the behaviour between UI and API should now addressed by https://projects.theforeman.org/issues/28644 .
So the reason you see a noarch in the "Sync Status" page is because we could not decipher the arch when we created the repository. Investigating further I noticed the subscription manifest should have arches listed for each content, but the problem is that there can be multiple arches associated to the same content and hence we are back to the same boat. In some cases there may zero arches even from the content.
I am open to alternatives to "noarch", may be "Unknown". Just that it will need a non trivial migration script to update the arches en masse.
I think I'd prefer "Unknown" or "Archtecture not set" or whatever, as "noarch" is a valid "arch" in RPM terms.
But if it's too much work, so be it.
Given that without your fix from #28644, most repos actually will have an arch set, we probably could get away with no migration and just sorting the newly enabled repos into the "Unset arch" bucket, leaving the old ones in x86_64 etc?
- Target version changed from Katello 3.15.0 to Katello Backlog
Ok from your comments it looks like we'd need to
- Update the arch substitution in repositories table to nil where it used to be no arch
- Update the RH Repos + Sync Status page list arch as "Not Specified" if repo has no arch substitution
Since this is more a usability change than a functionality change going to move it to backlog. Please let me know if you have any reservations.
- Target version deleted (
Katello Backlog)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by