Bug 2166435

Summary:	Exporting repositories that have architecture restrictions results in bogus data that can't be properly imported
Product:	Red Hat Satellite	Reporter:	Joniel Pasqualetto <jpasqual>
Component:	Inter Satellite Sync	Assignee:	Partha Aji <paji>
Status:	CLOSED ERRATA	QA Contact:	David Moore <damoore>
Severity:	medium	Docs Contact:
Priority:	high
Version:	6.12.1	CC:	ahumbe, damoore, jlenz, paji, pcreech, vsedmik, wpinheir
Target Milestone:	6.14.0	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rubygem-katello-4.9.0.2-1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-11-08 14:18:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Joniel Pasqualetto 2023-02-01 20:01:43 UTC

Description of problem:

When exporting a repository that has the option "Restrict to architecture" set, results in bogus metadata. The exported content, when being imported, only generates an empty repository.

Version-Release number of selected component (if applicable):

Observed on Satellite 6.11 and 6.12

How reproducible:
Always

Steps to Reproduce:
1. Enable a repository and configure it to immediate download
2. Edit the repository options and define "Restrict to architecture" to x86_64
3. Export the repository
4. Try importing the exported repository in another Satellite. 

Actual results:
The task itself success (no errors are reported), but the result is an empty repository.
On pulp logs, we can see a warning like this:

~~~
Feb 01 19:51:52 sat611.jpasqualetto.local pulpcore-worker-1[99534]: pulp [749ed56e-880f-4d1b-ac19-e17e6b18cadf]: pulpcore.app.tasks.importer:WARNING: Could not find destination repo for Red_Hat_Satellite_Client_6_for_RHEL_9_x86_64_RPMs-127736. Skipping.
~~~

Looking at the task details on dynflow, one can see a very small number of steps being executed. 

Expected results:

Should be able to import the data into another Satellite and bring the content.

Additional info:

Comment 1 Joniel Pasqualetto 2023-02-01 20:11:29 UTC

Workaround for those hitting the problem: remove the restrictions from the repositories and export them again.

Comment 2 Brad Buckingham 2023-02-02 15:06:52 UTC

Does this only apply to Custom (i.e. not Red Hat) repositories?

Thanks!

Comment 3 Joniel Pasqualetto 2023-02-02 15:18:09 UTC

Hello Brad

No! I actually didn't test on custom, only on Red Hat repositories. The customers I saw facing this issue were also using Red Hat repositories.

Comment 5 Partha Aji 2023-06-06 14:07:54 UTC

Connecting redmine issue https://projects.theforeman.org/issues/36477 from this bug

Comment 6 Bryan Kearney 2023-06-10 00:02:53 UTC

Upstream bug assigned to paji

Comment 7 Bryan Kearney 2023-06-10 00:02:55 UTC

Upstream bug assigned to paji

Comment 8 Bryan Kearney 2023-06-30 00:02:40 UTC

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/36477 has been resolved.

Comment 13 errata-xmlrpc 2023-11-08 14:18:30 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 (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHSA-2023:6818