• What is the nature and description of the request?

From the Satellite docs, we were under the impression that ISS could sync content views and lifecycle environments to downstream Satellites, but this does not seem to be the case in reality.

• Why does the customer need this?

Significant improvement in user experience by having native functionality to sync configurations and such to downstream Satellites to ensure consistency across a global deployment

• How would the customer like to achieve this?

Our desire is to be able to have a "primary" Satellite where we can do our content view and lifecycle environment creation and management, and have our downstream Satellites sync the state of these automatically, so that we don't need to manually (or through Ansible playbooks for example) create these views and push them out to whatever Satellites we have deployed. Having this as native-to-Satellite functionality would provide greater confidence in consistency and significantly reduce the overhead of managing complex Satellite deployments.

Ideally, this could be expanded to include anything defined in Satellite including:

• Lifecycle environments
• Content views
• Activation Keys
• 3rd party/internal repositories, their content, and associated views
• Partition table definitions
• Provisioning templates

As a reference, our intended Satellite topology is to have a primary Satellite that syncs from Red Hat, and from where regionally-distrubted Satellites around the world pull their content from. It will be a non-trivial effort to ensure that content we vett and test in our lab/testing environments is consistent with what gets pushed to our production environments without this kind of functionality.

The main reason we are having to deploy multiple Satellites is due to the use of Satellite for provisioning - if we have a single Satellite for covering our global datacenters, then if the Satellite goes down for any reason (e.g. localized power failures), then we lose global provisioning capability which would be catastrophic for us. This is because the Capsule API is simply a reverse proxy back to the Satellite, so their is no way to ensure high availability of provisioning functionality.

• For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

ISS would be able to natively sync the below:

• Lifecycle environments
• Content views
• Activation Keys
• 3rd party/internal repositories, their content, and associated views
• Partition table definitions
• Provisioning templates

• Does the customer have any specific timeline dependencies and which release would they like to target

The customer is looking to deploy Satellite by the end of Q3 2024.

• Would the customer be able to assist in testing this functionality if implemented?

Yes.