Updating the Kubeturbo version through OperatorHub

Update the image tag version of your Kubeturbo deployment whenever your Turbonomic instance updates to a new version or if you are instructed to do so.

The image tag version should be in the format x.x.x. This version depends on, and should always match, your Turbonomic instance version. For example, if your Turbonomic instance version is 8.14.3, specify the same instance version as the image tag version.

To get the version of your Turbonomic instance, open the Turbonomic user interface and click the Help icon in the navigation menu.

Open the installed operator and update the Kubeturbo operator based on your subscription. You can enable automatic updates or require update approvals. The Kubeturbo operator is given the same version as the Kubeturbo product version.

If your subscription is set to automatic, Kubeturbo automatically updates when a new version of Kubeturbo is released. There are no manual steps for you to perform.
If your Kubeturbo release was installed with default values, check if the kubeturbo-release pod has restarted and verify the new version in the Turbonomic user interface (in Settings > Target Configuration, open the target that corresponds to the Red Hat OpenShift cluster).

Repeat this step for every cluster with a Kubeturbo deployment.
If you are using a non-default cluster role and your version of the Kubeturbo operator was deployed before 8.9.5, review the following guidelines and additional steps.
- As of Kubeturbo operator 8.9.5, there were changes introduced to have a new unique cluster role binding name. Additionally, in version 8.9.6, there were changes introduced to have a new unique cluster role name. These changes were introduced to support deploying multiple operator-based Kubeturbo in a single cluster. As such, some manual changes are needed to ensure that your operator-based deployment of Kubeturbo continues to work and uses these new unique cluster role and cluster role binding names. Since the Kubeturbo operator is Helm-based, these manual steps are required to delete the old cluster role and cluster role binding names.
- There are a few different scenarios where you will be required to perform the following manual steps to use these new cluster role and cluster role binding names.
  - Your operator or OperatorHub deployment of Kubeturbo uses a custom cluster role, such as turbo-cluster-reader, and you now want to change it to turbo-cluster-admin to allow Kubeturbo to execute actions automatically.
  - Your operator or OperatorHub deployment of Kubeturbo uses a custom cluster role, such as turbo-cluster-reader or turbo-cluster-admin, and you upgraded a version older than 8.9.5 to a later version.
Perform these additional steps.
1. Delete all cluster roles that start with the names turbo-cluster-reader and turbo-cluster-admin. There could be four cluster roles with such names.
2. Delete any cluster role binding that starts with the name turbo-all-binding-kubeturbo.
After a few minutes, the Kubeturbo operator automatically recreates the required non-default cluster role and cluster role binding using the new names.
If you have explicitly specified a Kubeturbo version in the kubeturbo-release custom resource (kubeturbo-release is default), update the tag: parameter to upgrade your installation, as shown in the following example..
```
spec:
  image:
    #supply your private repo and specific product version here
    repository: "icr.io/cpopen/turbonomic/kubeturbo"
    tag: {new_image_tag_version}
  #rest of CR will be retained
  ...
```
Apply the updates.

Repeat these steps for every cluster with a Kubeturbo deployment.