How to be prepared for changes in Red Hat Smart Management and Satellite

In my work as a Red Hat Technical Account Manager (TAM), one of my responsibilities is ensuring my customers are aware of the roadmap for various Red Hat products. This includes informing customers of upcoming changes to products, such as features being deprecated, and helping them plan for these changes. 

The Satellite 6.7 release notes listed that several items are deprecated and would be removed in a future release of Satellite. This post will cover several of these items, and what customers can do to prepare for these changes. I would recommend reviewing the release notes to see if any of the other items might affect your Satellite environment. 

In this post, we’ll be covering the following items announced as being deprecated:

• Puppet

• The Katello agent (goferd)

• The background download policy

• OSTree repository support

For each of these items, we will cover the recommended actions to take at this time. 

Smart Management and Satellite Roadmap

The Red Hat Management strategy and roadmap presentation during the 2020 Red Hat Summit covered the roadmap for upcoming Smart Management and Satellite releases. We are targeting a release of Satellite 6.8 in the late 2020 timeframe, and targeting Satellite 7.0 for around the Summit 2021 timeframe. These are just target timeframes and are subject to change. 

The Red Hat Satellite team is currently developing a plan and guidance for minimizing downtime during the Satellite 6 to Satellite 7 upgrade.

This roadmap has direct impact to the Puppet, Katello agent, background download policy, and OSTree repository deprecations because these pieces of functionality are planned to no longer be available in Satellite 7.0. 

Planning for Satellite Puppet Deprecation

Satellite 6.0 was originally released in September of 2014 and used Puppet to support host configuration management. Support for Puppet will continue for the duration of the Satellite 6.x product lifecycle, which as previously mentioned, is currently planned to end with Satellite 6.8. 

With Satellite 7.0, Puppet will no longer be available for host configuration management. If you currently use Puppet within Satellite, there are two possible options available: migrate to Ansible, or migrate to a Puppet implementation outside of the Satellite environment. 

In October 2015, Red Hat announced we were acquiring Ansible, and shortly after that planning began to make Ansible available as an additional option for host configuration management in Satellite 6. 

Satellite 6.4, released in October of 2018, introduced Ansible as a host configuration option in addition to Puppet. Since then, each Satellite release has improved the Ansible functionality within Satellite:

• Satellite 6.5 introduced the ability to use Ansible RHEL system roles.

• Satellite 6.6 improved Ansible variable functionality and added the ability to deploy the OpenSCAP agent with Ansible, support for Ansible 2.8, and support for Ansible Runner.

• Satellite 6.7 introduced the Cloud Connector, which allows customers to run Insights Ansible Remediation playbooks right from the Insights web interface on cloud.redhat.com. Satellite 6.7 also fully switched to the Ansible Runner implementation. 

One feature of Ansible is that it is agentless. If you already have remote execution properly configured in your Satellite environment, you are ready to start using Ansible in Satellite. Remote execution will be discussed in more detail in the next section regarding the Katello agent deprecation.

I have previously written several blog posts related to using Ansible in Satellite that will help you get started:

• Getting started with Ansible in Satellite

• Satellite Host Configuration with RHEL System Roles Powered by Ansible

• Deploying OpenSCAP on Satellite using Ansible

• Advanced Ansible variables in Satellite

Before getting started with Ansible on Satellite, one very important piece of information to understand is the Scope of Support for Ansible Components included with Red Hat Satellite 6. Depending on what your use case and needs are, a Red Hat Ansible Automation Platform subscription might be more appropriate. In this case, Satellite supports integrating with Ansible Tower (which is part of the Ansible Automation Platform subscription). I have also written a couple of blog posts that cover this integration in detail:

• Satellite and Ansible Tower integration part 1: Inventory integration

• Satellite and Ansible Tower Integration part 2: Provisioning callbacks

If you are not familiar with Ansible, one of the things you’ll need to learn is how to write Ansible Playbooks and Roles. The good news is that Ansible Playbooks are written in the YAML format and it is easy to learn how to write them. There is also a very large library of Ansible Roles available at Ansible Galaxy, so in many cases you will be able to find an existing role and not need to write one from scratch. 

There is Ansible documentation covering an introduction to playbooks. Red Hat also offers several training courses for Ansible. 

Recommended action to take:

• Become familiar with Ansible support in Satellite 6 by reviewing the previously covered blog posts.

• Review the Scope of Support for Ansible Components included with Red Hat Satellite 6 and the Red Hat Ansible Automation Platform, and based on your environment and use case, determine if the Ansible support within Satellite will meet your needs, or if a Red Hat Ansible Automation Platform subscription would be a better fit. 

• Consider taking Red Hat training on Ansible. 

• Start learning how to write Ansible Playbooks and start migrating your previous Puppet modules to Ansible. 

Planning for Katello agent deprecation

When Satellite 6.0 was originally released, the Katello agent was installed on each Satellite client system to enable communication between the clients and the Satellite Server. This allowed the Satellite Server to trigger the execution of package updates or installs on clients, and also allowed the Satellite Server to collect information from the clients. 

Satellite 6.2 introduced the remote execution functionality, which gave customers the option to enable communication between the Satellite Server and Satellite clients over SSH. This provided the ability to choose between using the Katello agent on clients, using remote execution, or a combination of both.

For an overview of remote execution in Satellite, please review the previous post I wrote, "Getting started with Red Hat Satellite remote execution."

Using Satellite without the Katello agent is also referred to as a “goferless” configuration (goferd being the daemon that the Katello agent uses). 

There are many benefits of using a goferless Satellite configuration, which is supported in Satellite 6.2 and later, and which will be required in Satellite 7:  

• The katello-agent package no longer needs to be installed or maintained on the Satellite clients.

• Reduces the attack vector of client servers as there is one less daemon running on each server.

• The vast majority of servers are already running the SSH daemon so there is minimal time and effort needed to configure Remote Execution. 

If you are currently using the Katello agent in your Satellite environment, it is recommended to start transitioning to the remote execution functionality. 

For more information on configuring remote execution, and distributing the SSH key, see the Running Jobs on Hosts section of the Satellite documentation. 

The Goferless Host Management  and Goferless Infrastructure Clean-up & How To articles cover an overview of how to migrate to a goferless Satellite configuration. 
Recommended action to take:

• If you are not familiar with Remote Execution, review the blog post Getting started with Red Hat Satellite remote execution and the Satellite documentation on Remote Execution. 

• If you don’t already have Remote Execution setup in your environment, follow the documentation Running Jobs on Hosts to get it set up. 

• Validate that remote execution is working on all your hosts by running a simple “uptime” command on all Satellite clients. If any of these fail, investigate and resolve the issue. 

• Plan a transition to a goferless Satellite environment by following the steps in the Goferless Host Management  and Goferless Infrastructure Clean-up & How To articles. 

Planning for background download policy deprecation

Satellite currently has three sync policies that determine how Satellite syncs yum repository content:

• Immediate

• On demand

• Background

For an explanation of each of these sync policies, see this section of the Satellite 6.7 documentation. 

The Background sync policy is deprecated and will be removed in Satellite 7. As part of the upgrade to Satellite 7, any repositories configured with the background sync policy will be converted to the immediate sync policy.

However, it is possible to proactively convert any repositories you currently have configured with the background policy to the immediate policy by following the Changing the Download Policy for a Repository section of the Satellite documentation. 

Recommended action to take:

• Review the documentation covering the differences between the Satellite sync policies.

• Review your repositories to see if any are currently set to the background policy. If so, consider proactively converting these repositories to the immediate sync policy.

• Review your configuration setting for Default Red Hat Repository download policy and Default Custom Repository download policy by following this documentation. If either of these default settings is set to background, consider proactively changing it to the immediate sync policy. 

Planning for OSTree repository deprecation

The only Red Hat product Satellite supports for OSTree repositories is Red Hat Enterprise Linux Atomic Host. If you are not using this product, or a third party OSTree repository, then the OSTree repository removal in Satellite 7 should have no impact in your environment. 

If you are using Satellite to host your Atomic Host OSTree repositories, you have a couple of options. The Atomic Host end of maintenance is August of 2020 if you are using Atomic Host outside of OpenShift 3. If you are using Atomic Host within an OpenShift 3 environment, the end of maintenance is June of 2021 (for more information see this article). 

If you are currently using OSTree repositories in Satellite to support Atomic Host, one option would be to stay on Satellite 6.7 or 6.8 (once it is released) until the end of support on Atomic Host in June of 2021. Satellite 6.7 is currently planned to be supported until the late 2021 timeframe. 

Another option would be to follow the steps in this article to setup a mirror of the Atomic OSTree repository outside of the Satellite environment. 

Recommended action to take:

• If you are not using OSTree repositories in Satellite, there is no action needed.

• If you are using Satellite OSTree repositories to support Atomic Host, either stay on Satellite 6.7 or 6.8 until the Atomic Host is out of maintenance in June of 2021, or setup an OSTree repository mirror outside of the Satellite environment. 

Summary and Closing

With the information provided in this post, you should be better prepared for some of the upcoming changes in Satellite related to Puppet, the Katello agent, background down policy, and OSTree repositories.