Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When importing an exported archive Satellite will fail if the redhat repositories in the archive cannot be enabled. Due to this constraint `disconnected` customers have to come up with strategies like
1) creating a content view per disconnected satellite
2) Keeping track of what subs are possible in that disconnected satellite and manage each content view accordingly etc.
This can be a lot book keeping depending on the number of disconnected satellites.
A better approach to reduce this complexity is to allow for "Flexible" Imports. This means when Importing from an archive Satellite relaxes the rules and says "If this repo cannot be enabled don't copy it, but import the rest."
This would mean the upstream customer can
1) create 1 content view with all the necessary repositories across,
2) publish
3) export that archive
4) Share the same archive to all the disconnected satellites
And in the downstream the import process will ignore non-possible repos and warn the user that it had to ignore.
Additional notes
This RFE has merit and can be useful but one drawback scenario.
1) Customer does a full export and passes the same archive for import to downstream satellites
2) The downstream satellite does not enable some repositories.
3) Customer then does an incremental export end of the quarter to export updates
4) The subs have changed in one of the downstream satellites. So a new repo that is part of this archive can be enabled in that satellite. The archive only has an incremental data though. So satellite will not be able to import contents of this repo from its previous iterations.
Possible Solutions:
1) Add a warning that not all repositories were imported from this archive.
2) On an incremental export warn the user if a new repository was enabled.