Skip to main content
We are excited to be a part of AWS re:Invent 2024. Visit us at booth #1844 in Las Vegas.More info
Loading
Version: Operator 2.3.0

Upgrade Operator 2.2.1 to 2.3.0 on Red Hat OpenShift using Command Line

This is the procedure to upgrade the Operator installed on Red Hat OpenShift from version 2.2.1 to version 2.3.0 using the command line tools.

tip

The following instructions also works with the OpenShift command line tool - oc

Verify that 2.3.0 version of the operator is available​

Verify that the following command lists 2.3.0 as the current CSV version:

kubectl get packagemanifests  -l catalog=redhat-marketplace,provider=Aerospike -o yaml | grep currentCSV:

The following appears:

    - currentCSV: aerospike-kubernetes-operator.v2.3.0

Upgrade the Operator​

Based on the installPlanApproval mode, the upgrade of the Operator can be either:

  • Automatic: The default when installing the Operator from OperatorHub.io.
  • Manual: If the OperatorHub.io subscription is configured to use Manual approval.

Automatic​

The standard install procedure sets up Automatic upgrade approval for the operator. In this case OLM automatically installs operator version 2.3.0. You do not need to perform any manual steps to upgrade the operator.

You can skip ahead to verification.

Manual​

If the OperatorHub.io subscription is configured to use Manual approval, you need to approve the upgrade as follows:

Verify that the InstallPlan for version 2.3.0 has been created.

kubectl get installplan -n openshift-operators | grep aerospike

Sample output with an InstallPlan for version 2.3.0.

NAME            CSV                                    APPROVAL   APPROVED
install-2tg7p   aerospike-kubernetes-operator.v2.3.0   Manual     false
install-fn297   aerospike-kubernetes-operator.v2.2.1   Manual     true

The upgrade is not applied, since the approved status is false.

To approve the upgrade, set approved field in the InstallPlan to true using the following:

kubectl patch installplan -n openshift-operators --type merge --patch '{"spec":{"approved":true}}'  $(kubectl get installplan -n openshift-operators | grep "aerospike-kubernetes-operator.v2.3.0" | cut -f 1 -d " ")

Verify that the Operator is upgraded​

Run the following command

kubectl get csv -n openshift-operators | grep aerospike

While the operator upgrade is in progress, the CSV for version 2.3.0 goes through phases like Pending, Installing, InstallReady, and finally Succeeded.

Sample output on success:

NAME                                   DISPLAY                         VERSION   REPLACES                               PHASE
aerospike-kubernetes-operator.v2.3.0   Aerospike Kubernetes Operator   2.3.0     aerospike-kubernetes-operator.v2.2.1   Succeeded

Check Operator Logs​

The Operator runs as two replicas by default, for higher availability. Run the following command to follow the logs for the Operator pods.

kubectl -n openshift-operators logs -f deployment/aerospike-operator-controller-manager manager

Output:

2022-06-16T19:09:58.058Z    INFO    controller-runtime.metrics  metrics server is starting to listen    {"addr": "127.0.0.1:8080"}
2022-06-16T19:09:58.062Z    INFO    setup   Init aerospike-server config schemas

2022-06-16T19:09:58.071Z    DEBUG   schema-map  Config schema added {"version": "4.7.0"}
2022-06-16T19:09:58.072Z    INFO    aerospikecluster-resource   Registering mutating webhook to the webhook server
2022-06-16T19:09:58.073Z    INFO    controller-runtime.webhook  registering webhook {"path": "/mutate-asdb-aerospike-com-v1beta1-aerospikecluster"}
2022-06-16T19:09:58.073Z    INFO    controller-runtime.builder  skip registering a mutating webhook, admission.Defaulter interface is not implemented   {"GVK": "asdb.aerospike.com/v1beta1, Kind=AerospikeCluster"}
2022-06-16T19:09:58.073Z    INFO    controller-runtime.builder  Registering a validating webhook    {"GVK": "asdb.aerospike.com/v1beta1, Kind=AerospikeCluster", "path": "/validate-asdb-aerospike-com-v1beta1-aerospikecluster"}
2022-06-16T19:09:58.073Z    INFO    controller-runtime.webhook  registering webhook {"path": "/validate-asdb-aerospike-com-v1beta1-aerospikecluster"}
2022-06-16T19:09:58.074Z    INFO    setup   Starting manager
I1015 19:09:58.074722       1 leaderelection.go:243] attempting to acquire leader lease aerospike/96242fdf.aerospike.com...

Grant RBAC permissions to non-aerospike Kubernetes namespaces​

caution

OLM-based installations (OperatorHub.io and on Red Hat OpenShift) have a known issue with upgrading from version 2.2.1 to 2.3.0. This upgrade scenario revokes the RBAC privileges required to run Aerospike clusters in Kubernetes namespaces other than the aerospike namespace.

If you are upgrading from 2.2.1 to 2.3.0 and are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, follow these instructions to restore the required RBAC privileges.

Last updated on