Bug 1934795

Summary: Unsetting repository architecture restriction doesn't reach clients
Product: Red Hat Satellite Reporter: Jonathon Turel <jturel>
Component: RepositoriesAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: Tasos Papaioannou <tpapaioa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: ehelms
Target Milestone: 6.10.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-16 14:10:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jonathon Turel 2021-03-03 20:14:08 UTC
 ... because Candlepin never gets updated!

The candlepin db state can be verified with this query:

SELECT product.uuid AS "Product UUID", product.name AS "Product Name", product.product_id, content.content_id, content.uuid, content.label, content.name, content.arches FROM cp_pool pool JOIN cp2_products product ON pool.product_uuid = product.uuid JOIN cp2_product_content pc ON product.uuid = pc.product_uuid JOIN cp2_content content ON content.uuid = pc.content_uuid ORDER BY product.name ASC;

The implication of this change is that, for example: accidentally setting i386 architecture and then unsetting it will permanently lock the Content in Candlepin to i386 while the UI will show that no restriction is set because the RootRepository has the correct value. The workaround is to recreate the repo which is not ideal.

The fix should include a migration to update Candlepin to reflect whatever is currently set on the RootRepository

Comment 1 Jonathon Turel 2021-03-03 20:14:11 UTC
Created from redmine issue https://projects.theforeman.org/issues/32008

Comment 2 Jonathon Turel 2021-03-03 20:14:13 UTC
Upstream bug assigned to None

Comment 3 Jonathon Turel 2021-03-03 20:15:53 UTC
I discovered this bug while investigating https://bugzilla.redhat.com/show_bug.cgi?id=1931027 which has an identical symptom but a different root cause.

Comment 4 Jonathon Turel 2021-03-03 20:17:53 UTC
The fix for this should be relatively small and since the impact can create a very frustrating user experience (and obviously clients not being able to get their intended content is bad) I recommending porting it back through 6.7.z

Comment 5 Bryan Kearney 2021-04-15 10:44:59 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/32008 has been resolved.

Comment 6 Tasos Papaioannou 2021-06-01 17:57:01 UTC
Verified on 6.10.0 snap 2.0.


1. Create and sync a custom yum repository.
2. Edit the repository and select 'i386' in the 'Restrict to architecture' field.
3. Register and subscribe an x86_64 content host.
4. Verify that the repo is not visible:

# subscription-manager repos --list-enabled
This system has no repositories available through subscriptions.

5. Change the 'Restrict to architecture' field to 'x86_64' or 'No restriction', and verify that the host now has access to the repo:

# subscription-manager repos --list-enabled
1 local certificate has been deleted.
    Available Repositories in /etc/yum.repos.d/redhat.repo
Repo ID:   [...]

Comment 9 errata-xmlrpc 2021-11-16 14:10:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Satellite 6.10 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.