Update the ODF Operator

In this lesson, we’ll see how to perform a declarative, automated update of the ODF Operator by simply modifying the channel or version in the existing GitOps manifest and allowing Argo CD to handle the rolling upgrade.

In this lesson, you will:

• Manage and execute non-disruptive rolling upgrades for the ODF Operator by updating the channel or version directly in the declarative GitOps repository.

Update the operator

Keeping the ODF Operator up to date is crucial for the storage environment. When updating an operator, you must take two things into account:

• Approval Strategy 

  • If the approval strategy is set to Automatic, nothing must be done inside one OpenShift version. The operator will update itself automatically as soon as a new version is released.

  • If it is set to Manual, then a manual interaction is required. In this case, the UI will indicate that an update is available and can be approved by accepting the new version.

• Operator channel

  • Typically, when a new OpenShift version is released, the channel can be updated to a new version soon afterwards. For example, ODF installed on OpenShift 4.18 is using the channel stable-4.18.

  • Both options can be managed via the helper-operator Chart. While the approval strategy is usually not changed, the update of an Operator can be simply done by changing the channel.

  helper-operator:
  [...]
   operators:
     odf-operator:
       enabled: true
       [...]
       subscription:
         channel: stable-4.18 # <1>
         approval: Automatic # <2>

  • Chosen channel: To update the Operator, simply change the channel from stable-4.18 to stable-4.19 as soon as it has been released. 

  • Approval strategy: Either Manual or Automatic.

Summary

Deploying OpenShift Data Foundation using OpenShift GitOps provides a clean, reproducible, and scalable approach to manage storage in your OpenShift cluster fleet. As with all GitOps workflows, keeping your infrastructure as code in GitHub gives you better traceability, consistency, and control over your environments.

Using the end-to-end examples allows you to automatically install the operator, wait until the operator is fully installed, then configure the operator in one Argo CD application. You might prefer a different way to install and configure the operator, whether it be separate Argo CD applications or simply retries, or you might prefer Kustomize over Helm Charts.

This is totally fine, as at the end of the day, it is important that any cluster configuration is stored in GitHub, because: If it is not in GitHub, it does not exist.

References:

The above solution uses some Helm Charts that should be considered when trying out the solution. Each Helm Chart contains a README file that will explain any additional settings that might be possible. Inside the same major version of the chart no breaking changes will happen.

• helper-operator: Subchart that is responsible for installing the operator.
• helper-status-checker: Subchart that is responsible for verifying the installation status of the operator.
• tpl: Simple collection of common templates.
• openshift-data-foundation: Chart to configure ODF.
• Wrapper Chart that combines the above Charts: Chart used by Argo CD to combine all other charts.

Ready to learn more about Red Hat OpenShift?

• Foundations of OpenShift