Project

General

Profile

Bug #28555

enabling a repository set without providing a basearch yields unexpected results

Added by Evgeni Golov 5 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
API
Target version:
Difficulty:
Triaged:
Yes
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

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.


Related issues

Related to Katello - Bug #25224: Some repositories from the CDN no longer has variants and repository page shows "Unspecified"Closed
Related to Katello - Bug #25901: [Subscription] - Not able to add RHEL8 repositories into KatelloClosed
Related to Foreman - Tracker #27680: API bugs that need workarounds in foreman-ansible-modulesNew

Related to Katello - Bug #28644: inconsistent repository enabled state for RHEL8 repository sets in the APIClosed

History

#1 Updated by Evgeni Golov 5 months ago

  • Related to Bug #25224: Some repositories from the CDN no longer has variants and repository page shows "Unspecified" added

#2 Updated by Evgeni Golov 5 months ago

  • Related to Bug #25901: [Subscription] - Not able to add RHEL8 repositories into Katello added

#3 Updated by Evgeni Golov 5 months ago

  • Related to Tracker #27680: API bugs that need workarounds in foreman-ansible-modules added

#4 Updated by Evgeni Golov 5 months ago

  • Related to Bug #28644: inconsistent repository enabled state for RHEL8 repository sets in the API added

#5 Updated by Jonathon Turel 5 months ago

  • Triaged changed from No to Yes
  • Target version set to Katello 3.15.0

#6 Updated by Partha Aji 4 months ago

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.

#7 Updated by Evgeni Golov 4 months ago

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?

#8 Updated by Partha Aji 4 months ago

  • 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.

Also available in: Atom PDF