Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-10997

Bump operator-sdk version for 3scale-operator

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • 3scale Operator
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started

      WHAT
      Bump the Operator SDK dependency for the 3scale-operator to the latest version (currently v1.34.1).

      HOW
      In order to bump the version of operator-sdk we also need to migrate migrate 3scale-operator from a kubebuilder v2 project to a kubebuilder v4 project.

      For background, operator-sdk is built around the kubebuilder project and uses kubebuilder standards when scaffolding new projects. When 3scale-operator was first scaffolded, the default kubebuilder layout was go/v2. Starting with operator-sdk v1.3.0, operator-sdk began using the go/v3 layout when scaffolding new projects by default. At this time, operator-sdk does not require legacy scaffolded projects to update their underlying kubebuilder version but by skipping it we are missing out on a lot of features. Additionally, if they (operator-sdk) ever change their mind and require operators to bump their project layout, then we will have to overcome a lot of technical debt since operator-sdk is moving to go/v4 by default in operator-sdk v1.33.0. So in order to bump our operator-sdk version from 1.2.0 to 1.34.1 (the latest version as of writing this), we will need to bump 3scale-operator's underlying project layout from go/v2 to go/v3 and then from go/v3 to go/v4.

      Note: It's probably possible to migrate the project directly from v2 to v4 but there's less documentation/support for this. Before beginning this ticket it's worth spending a little time to investigate if migrating directly from v2 to v4 is possible or if that will only introduce more problems.

      Here are some tips when bumping operator-sdk:

      • operator-sdk official upgrade docs can be found here.
      • Kubebuilder's migration guide for v2 to v3 can be found here. This should be done between operator-sdk v1.2.0 and v1.3.0.
      • Kubebuilder's migration guide for v3 to v4 can be found here. This should probably be done between operator-sdk v1.32.0 and v1.33.0.
      • When creating a new kubebuilder go/v3 project for the migration, use v3.13.0 of the kubebuilder CLI because this is closest to our current dependencies of go1.20, k8s v0.28.3, and controller-runtime v0.16.5.
      • Don't forget to delete operator-sdk binary stored at 3scale-operator/bin/operator-sdk between version bumps. This is required because currently, 3scale-operator's Makefile will not re-download the binary if it already exists. So for example, even if you update the operator-sdk version to 1.3.0, if the old 1.2.0 binary already exists at 3scale-operator/bin/operator-sdk, the new 1.3.0 binary will not be downloaded/used.

      DONE

      • 3scale-operator's project layout matches the standard kubebuilder v4 layout
      • Bumped operator-sdk to latest version

            Unassigned Unassigned
            ckyrillo@redhat.com Carl Kyrillos
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: