Bug 2028377

Steps to reproduce should be:
# hammer repository list --name 'Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server'
---|-------------------------------------------------------|---------------------------------|--------------|--------------------------------------------------------------------
ID | NAME                                                  | PRODUCT                         | CONTENT TYPE | URL
---|-------------------------------------------------------|---------------------------------|--------------|--------------------------------------------------------------------
2  | Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server | Red Hat Enterprise Linux Server | yum          | https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os
---|-------------------------------------------------------|---------------------------------|--------------|--------------------------------------------------------------------

#  hammer repository export --id 2
Error: No such sub-command 'export'.

See: 'hammer repository --help'.


Ability to export individual repos for different customers needs to be restored in SAt6.10 - not in referenced format - but rather SAT6.9 and previous rpm format for import into disconnected Satellites <6.10, and ability to import into disconnected satellites that don't have same subscriptions as connected one.  This ability should have never been removed.

Note: This was NOT noted in https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html/release_notes/release_information#deprecated_functionality. 
Please re-enable this functionality ASAP - content-view export/import only is a nightmare to manage with several OS versions and various disconnected satellites (and large customers) with various subscriptions.

According to https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/upgrading_and_updating_red_hat_satellite/index section 3.1.3:
 The hammer import and export commands have been replaced with hammer content-import and hammer content-export tooling.

If you have scripts that are using hammer content-view version export, hammer content-view version export-legacy, hammer repository export, or their respective import commands, you have to adjust them to use the hammer content-export command instead, along with its respective import command. 

Well it looks as if content-export and content-import are NOT available either in 6.10 - only 6.9 - but 6.9 and all earlier also have 'hammer repository export'!

Correction  content-export and content-import are in 6.10 not 6.9 and earlier (was in wrong X-window when looking at help) - but will only export content-views not repositories - need ability to export repositories like 6.9 and earlier have always had.

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

Upstream bug assigned to paji

Upstream bug assigned to paji

I agree with JohnG - the removal of hammer repository export severely hampers Red Hat's strategic position with regulated environment customers i.e. NAPS, Finance, Healthcare, etc. For example, my project is to provide hundreds of disconnected customers with an ACL-controlled disconnected CDN.  Access to Red Hat's content is controlled by the customer's entitlement manifest.  It would not be feasible to generate hundreds of CV exports that require different entitlements (which we won't have), different export dates (which would require a several 8x5 consultants to coordinate), and all of the related CV export deliveries. Then there are the expected CV export mistakes that we couldn't roll back, the CV import errors we can't fix, and the CV deliveries that are lost en route. What's more, most of these customers won't be able to connect to our disconnected Satellite due to regulations covering things like data ex filtration and need-to-know. 

In short, the disconnected CDN that feeds customer's Satellite servers is much, much simpler to maintain, removes Red Hat's out-of-contract-scope responsibility from being involved in our customer's patching cadence, and reduces Red Hat's potential exposure to data ex filtration liabilities.

I took a look at https://github.com/Katello/katello/pull/9925, and I don't see the difference from the existing Satellite 6.10 content view export method.  

Unless the resulting tarball has the proper file tree i.e. content/rel8/x86_64/baseos/os/{Packages,repodata} format with a full copy of the latest repository metadata we cannot use Satellite 6.10 to support disconnected customers who are running their own Satellite servers.  These Satellite servers expect an available CDN server to supply them with content regardless of what their Satellite Organization(s) are named, and what is in their Organization's entitlement manifest. 

Is there a plan for this use case?  We have a lot of customers, 83 at the current state with hundreds more to come, who are depending on it.

Here's what we need:

Full repository exports containing a full copy of each repository's metadata that is both Satellite Organization, Content View, and software entitlement manifest neutral. 
Incremental repository exports containing a full copy of each repository's metadata that is both Satellite Organization, Content View, and software entitlement manifest neutral.
Single full or incremental repository exports containing a full copy of each repository's metadata that is both Satellite Organization, Content View, and software entitlement manifest neutral. This is to address critical CVEs that have mission critical impact. Think heart bleed and log4j.

As GleenS stated:
This fix for should allow repo export product to be the same as Sat6.9 and earlier!  It needs to be able to allow disconnected satellite import via sync as if connected to CDN - NOT a kludge like the 6.10.x content-view export.  All rpm's/repo should be available via directory structure - i.e Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server would be located under ${export_dir}/content/dist/rhel/server/7/7Server/x86_64/os - just like an import from REDHAT CDN.

I don't think the CV export/import function is a kludge as it's been part of Satellite 6.x for quite some time.  The problem is that is is a 1:1 update method. Every CV created, in every Satellite Organization, needs its own CV import.  The connected Satellites must have sufficient entitlements for every Satellite Organization, and identical Satellite Organizations and CVs, and then the imports aren't guaranteed to work.  That greatly increases system administrator workload. Maintaining a disconnected CDN server is much less expensive in terms of work hours.

I would add that Red Hat Satellite's Disconnected Deployment documentation talks about using the Red Hat Content ISOs. However these files are infrequently updated, they don't cover all RHEL architectures, they don't provide a full suite of Red Hat applications i.e. JBoss, and the Content ISO page indicates that these files are deprecated. 

Documentation link: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html/installing_satellite_server_from_a_disconnected_network/performing-additional-configuration#configuring-satellite-to-synchronize-content-with-a-local-cdn-server_satellite

Hi John, Glenn,

Please be aware that bug 2069306 has been created to track the repository exports in the 'yum repo' format.

Thanks!

Complete and incremental export of single repository into tar.gz (hammer content-export complete repository ... / hammer content-export incremental repository ...) and subsequent import (hammer content-import repository ...) on disconnected Satellite went OK.

Please note that yum-format exports are tracked in bug 2069306

VERIFIED with Satellite 6.11 SNAP 21 @ RHEL8.6

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

https://access.redhat.com/errata/RHSA-2022:5498