This is a cache of https://docs.okd.io/4.9/operators/operator_sdk/osdk-upgrading-projects.html. It is a snapshot of the page at 2024-11-21T23:30:20.443+0000.
Upgrading projects for newer Operator SDK versions - Developing Operators | Operators | OKD 4.9
  1. Documentation
×

Upgrading projects for newer Operator SDK versions

OKD 4.9 supports Operator SDK v1.10.1. If you already have the v1.8.0 CLI installed on your workstation, you can upgrade the CLI to v1.10.1 by installing the latest version.

However, to ensure your existing Operator projects maintain compatibility with Operator SDK v1.10.1, upgrade steps are required for the associated breaking changes introduced since v1.8.0. You must perform the upgrade steps manually in any of your Operator projects that were previously created or maintained with v1.8.0.

Upgrading projects for Operator SDK v1.10.1

The following upgrade steps must be performed to upgrade an existing Operator project for compatibility with v1.10.1.

Prerequisites

  • Operator SDK v1.10.1 installed

  • Operator project that was previously created or maintained with Operator SDK v1.8.0

Procedure

  • For Ansible-based Operator projects, update the command in the Set pull policy section of the molecule/default/prepare.yml file:

    molecule/default/prepare.yml file diff 
         - name: Set pull policy
-      command: '{{ "{{ kustomize }}" }} edit add patch pull_policy/{{ "{{ operator_pull_policy }}" }}.yaml'
+      command: '{{ "{{ kustomize }}" }} edit add patch --path pull_policy/{{ "{{ operator_pull_policy }}" }}.yaml'

    Ansible projects are now scaffolded with Kustomize version 3.8.7. This version of Kustomize requires that the path to patch files be provided with the --path flag in the add patch command.

Your Operator project is now compatible with Operator SDK v1.10.1.

Known issues

  • The ansible-operator binary rejects the kubeconfig file if the server URL contains a path. There is currently no workaround other than running the Operator as a pod in the cluster, in which case it uses the internal endpoint. The fix for this issue is currently blocked waiting on a fix to the apimachinery package. See operator-framework/operator-sdk#4925 for more details.

Additional resources