Chapter 1. Introduction

The two primary strategies for migrating from Red Hat Satellite 5 to Satellite 6 are passive transition and active transition, both of which involve developing a Satellite 6 architecture alongside your Satellite 5 architecture.

Passive Transition

In a passive transition scenario, the existing workloads remain on Satellite 5, and only new workloads and projects are targeted for management by Satellite 6. This strategy is most appropriate if your Satellite deployment is complex and involves significant integration with other applications via APIs or other processes. In this case, Red Hat Satellite 6 is deployed to manage only new workloads and projects, whereas Red Hat Satellite 5 is maintained in order to manage existing workloads until they are retired. Satellite 5 data models might or might not be transitioned to Satellite 6. A passive transition gives administrators the most freedom to reconsider their infrastructure with the least possibility of any disruption to services.

Active Transition

In an active transition scenario, the intention is that all workloads will be moved to Satellite 6. The originating Satellite 5 is then free to be migrated into an archived state and shut down. There are two variations of this strategy:

Post-installation components refers to anything specific to Satellite 5 that you configured or created after installation. For example, system groups, activation keys and channels.

Active Transition with Post-Installation Components

Build a new Satellite 6 based upon Satellite 5, and migrate clients after translating the Satellite 5 data models to Satellite 6 and registering systems to the new Satellite. This method allows data models to remain somewhat similar and familiar, with all workloads migrated to the new Red Hat Satellite. This method uses the sat5to6 script. See Performing the Transition Using the sat5to6 Script.

Active Transition without Post-Installation Components

Build a new Satellite 6 not based upon Satellite 5, but using the new features of Satellite 6. Existing workloads are only migrated after a period of testing and planing has taken place. No clients profiles are migrated in this scenario, advantage is taken of the new features provided by Puppet. Red Hat gives customers a whole year of duplicate Satellite subscriptions so that you can build and test a Satellite 6 Server before migrating only the Satellite 5 clients to the new system. This version of the active migration strategy is now strongly recommended. This method uses the bootstrap script to migrate the clients. See Chapter 3, Migrating Existing Systems Using The Bootstrap Script.

Can I perform an in-place upgrade from Satellite 5 to Satellite 6?

The underlying technologies between Satellite 5 and 6 are significantly different. For this reason, the in-place upgrade process (such as from version 4.x to 5.x or from 5.x to 5.y) does not apply for version 5 to 6. Satellite 6 needs to be installed on a new server as part of the side-by-side transition process. Consequently, this is referred to as a transition process and not an upgrade process.

Which versions of Satellite 5 are supported for the transition?

The transition path begins with Satellite 5.6 or 5.7. If you are running an earlier version of Satellite you first need to upgrade to at least version 5.6.

Future releases of Satellite will also be supported as platforms for moving from Satellite 5.

Which versions of Red Hat Enterprise Linux will Satellite 5 and Satellite 6 support as client systems?

The following support matrix currently applies:

What is the quick version of how to transition from Satellite 5 to Satellite 6?

Will the transition tools work with a disconnected server?

Yes, the transition tools are designed such that a disconnected environment is assumed, and neither Satellite 5 nor 6 can directly communicate with each other or the Internet in general.

Will the transition tools transition all data from Satellite 5 to Satellite 6?

No. In some situations, Satellite 5 and Satellite 6 take different approaches to the tasks of synchronizing and provisioning hosts, managing entitlements, and dealing with disconnected environments. Some configuration, system, and host data is also created and stored differently. Consequently, not all data can be successfully transitioned.

In Satellite 6, the following information cannot be transitioned:

Can I run the transition tools and process multiple times?

Yes, the transition tools are idempotent. You can reuse the tools to create Satellite 6 data and preserve previous information. A small data file on the Satellite 6 Server preserves the history of previous runs and tracks what has already been imported.

Can I delete imported entities?

Yes. You can use the hammer import command to delete any or all of the entities imported to Satellite 6 from the Satellite 5 export file. This is useful if the import fails for some reason, and you need to update the CSV file and repeat the import. You can also use this procedure to test your import process in a development environment before using it in production.

You can delete a subset of imported entities, for example, users, or you can delete all imported entities. If you delete all imported entities, you effectively revert your Satellite 6 system to its original state before you started the import process.

The following example describes how to delete all imported users.

$ hammer import user --csv-file /tmp/exports/users.csv --delete --verbose
Deleting from /tmp/exports/users.csv
Deleting imported user [1->4].
Deleting imported user [2->5].
Deleting imported user [3->6].
Deleting imported user [5->7].
Deleting imported user [6->8].
Deleting imported user [7->9].
Deleting imported user [4->10].
Summary
Deleted 7 users.

To delete all imported entities, use the following command:

# hammer import all --delete

Can I use the export tools on my production Satellite 5 system?

Yes, assuming that you run the tools with sufficient disk space. Disk space will vary, from 20 MB to several Gigabytes, depending on the total amount of non-Red Hat content stored on the Satellite in /var/satellite/redhat/ and being selected for export by the export tool. When exporting custom or cloned channels, the tool searches for non-Red Hat content associated with the channels, to copy into the export archive. Other than some short-term CPU and memory consumption, the tool only performs read-only file system, and SQL queries on the database to gather data, write the resulting data to files on disk, and create a tar archive of the data.