As with testing the upstream subscription code against simulated Red Hat subscription infrastructure (Hosted Candlepin) - see INSTALLER-2684 - we should test the Satellite support in the same way.

This might be a bit more challenging, as we are currently lacking a suitable Candlepin simulator to the one developed by Pino Toscano, but as we have demonstrated the ability to quite easily provision Satellite development snapshots during RHEL 10 installed development, a similar process could be used to setup Satellite instances on demand for CI.

Lets go into some more detail.

Requirements

What needs to be in place for a test run that tests Satellite support in upstream Anaconda codebase:

• a rawhide image that has subscription management dependencies installed (regular Rawhide image disables the subscription module in Anaconda and lack subscription management packages)
• a Satellite instance,
  • ideally the latest release or even a Snapshot release, so that we can also detect regressions on the Satellite side, not just in our code -this is not a theoretical concern, we have found already 2 blocking bugs in Satellite in the RHEL 10 cycle so far:
    • SAT-26868
    • SAT-27416
  • the instance should have accounts setup to support testing via organization id & activation key, as that's what is supported in kickstart
    • username + password is only supported in the GUI & would be hard to test automatically due to the lack of automated GUI testing support with our GTK3 UI
  • there should be also some Fedora content provided via Satellite repositories
• a test run - this could be just a kickstart test, but there needs to be a mechanism that ensures the Satellite instance will be available - either pre-provisioned, or ideally provisioned on-demand for the test run
• a trigger mechanism - as we want to mainly spot regressions, the test should run regularly, possibly in the daily kickstart test batch; there should be also a way to trigger it manually during active development

Test run example

1. test run is triggered automatically/manually
2. a satellite instance is provisioned (either dynamically or already in place)
3. installation is started & installer is configured to talk to Satellite
4. installer authenticates to Satellite & uses Satellite provided repos for the installation
5. a %post script can do a pre-liminary check if all appears to be fine (registration status, repo configuration, etc.)
6. after a successful installation, the machine is rebooted and the booted system is briefly tested (IIRC kickstart test should already support this)
   • check registration status of the installed system
   • check repo configuration
   • if possible, try to install a sample package & check for return code (this verifies the system has access to content from Satellite as intended)

Benefits

• we can make sure upstream subscription support is ready for the next RHEL major release or a full or partial Anaconda rebase
• we can touch subscription related code during unrelated work without fear of breaking code that can't be easily tested
• we might be able to spot regressions in Satellite earlier than only at the last minute then the next major RHEL is branched
• automated end-to-end test cover will make much easier the expected migration from the RHSM API to rhc API in the future, same for any other bigger subscription management changes