Goal:

Customers need to be able to upgrade their existing deployments.

Acceptance Criteria:

• A Satellite or Capsule server can be upgraded in place
• A Satellite or Capsule server can be upgraded using backup on the old server & restore on a fresh server
• The upgrade guides (connected & disconnected) are updated with the new instructions
• The upgrade helper (https://access.redhat.com/labs/satelliteupgradehelper/) is updated to the new instructions (depends on the guides being upgraded).
• Make sure https://access.stage.redhat.com/labs/satelliteupgradehelper/ is upgraded so the steps can be tested before going live
• Upgrades are tested using automation
• Supported parameters are migrated to foremanctl

Open questions:

• Should we update the backup & restore documentation? Perhaps part of the support backup & restore porting
• Should we use satellite-clone?
• How do we get the new disconnected ISOs?
• How do we handle unsupported parameters?
• How do we handle custom-hiera.yaml when the customer specified some items?
• How do we handle the Upgrade Capsule jobs in Remote Execution? (https://github.com/theforeman/foreman_ansible/blob/master/app/views/foreman_ansible/job_templates/capsule_upgrade_-_ansible_default.erb)

Implementation suggestions:

Any parameter that is documented is considered supported today. We need to have a migration strategy for that (https://github.com/theforeman/foremanctl/blob/master/docs/parameters.md can help). Parameters listed in KCS articles are likely unsupported because KCS articles should say applicable versions. Especially if we do a major version bump then it should set the customer expectations right.