Release 2.4.0

New Features

• [KO -117] - Support for Strong Consistency mode.
• [KO -45] - Support for batch upgrade/downgrade for cluster nodes in a given Rack.
• [KO -26] - Enhancing namespace management (Allows adding and removing a namespace or namespace storage devices and files).

Improvements

• [KO -36] - Automatically set migrate-fill-delay to zero when the operator is scaling down the cluster and reset after completing the scaling down.
• [KO -119] - Scale up all the racks in parallel and then wait for them to be ready.
• [KO -131] - Running disk cleanup operation in parallel during initialisation and upgrade operation.

Bug fixes

• [K0 -83] - Allow empty common storage config in aerospike cluster CR.
• [K0 -124] - Quiesce command is failing for the last node while deleting the namespace.
• [K0 -126] - Long-running init containers failing due to missing ConfigMap files.

Known Issues

• Latest OLM (0.22.0) does not fully support ARM architecture.
• Aerospike Kubernetes Operator 2.4.0 is not available in Red Hat OpenShift Marketplace
• OLM-based installations (OperatorHub.io and on RedHat OpenShift) have a known issue with upgrading from version 2.3.0 to 2.4.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.3.0 to 2.4.0 and are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, follow these instructions to restore the required RBAC privileges.

Release 2.3.0

New Features

• [KO -146] - Aerospike Server Enterprise 6.2.0.0 support (ARM)

Known Issues

• Latest OLM (0.22.0) does not fully support ARM architecture.
• Aerospike Kubernetes Operator 2.3.0 is not available in Red Hat OpenShift Marketplace
• There is a known issue in OLM-based installations (OperatorHub.io and on Red Hat OpenShift), where an upgrade to version 2.2.0 from 2.1.0 causes revoking of RBAC privileges required to run Aerospike clusters in Kubernetes namespaces other than the aerospike namespace. If you are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, re-grant the RBAC privileges following instructions here.

Release 2.2.1

Bug fixes

• [K0-120] - Handled long-running init containers correctly without pods getting restarted again
• [KO-116] - Default fsGroup set as root group ID(0) in pod security context to grant init containers write permission to filesystem volumes in OpenShift
• [KO-137] - Allow Aerospike image tags to have a hyphenated prefix and suffix
• [KO-138] - Allow PMEM in validation webhook

Known Issues

• There is a known issue in OLM-based installations (OperatorHub.io and on Red Hat OpenShift), where an upgrade to version 2.2.0 from 2.1.0 causes revoking of RBAC privileges required to run Aerospike clusters in Kubernetes namespaces other than the aerospike namespace. If you are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, re-grant the RBAC privileges following instructions here.

Release 2.2.0

Security

• [KO -101] - Update vulnerable dependencies and container base images

New Features

• [KO -108] - Aerospike Server Enterprise 6.1.0.1 support

Improvements

• [KO -48] - Operator generates informative Kubernetes events

Bug fixes

• [KO -82] - Fixed auto injected volumes causing continuous restart of first Aerospike pod on scale up

Known Issues

• There is a known issue in OLM based installations (OperatorHub.io and on Red Hat OpenShift) where upgrade to version 2.2.0 from 2.1.0, causes revoking of RBAC privileges required to run Aerospike clusters in Kubernetes namespaces other than the aerospike namespace.If you are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, re-grant the RBAC privileges following instructions here.

Release 2.1.0

New Features

• [KO-32] - 6.0.0.0 server release support
• [KO-47] - Support for LDAP external authentication
• [KO-81] - Support for data and primary index on PMEM
• [KO-50] - Ability to pass securityContext to init-container
• [KO-35] - Custom docker registry for init container
• [KO-92] - Allow extra storage volumes that are not used by Aerospike namespaces
• [KO-93] - Allow image pull secrets in Pod Spec for using images from private registries

Improvements

• [KO-33] - Allow encryption-at-rest key rotation on a live cluster
• [KO-12] - Allow memory resource limit without requiring CPU resource limit
• [KO-13] - During scale down, stateful set status check failures do not exponentially backoff
• [KO-54] - Kube-rbac-proxy & Init-Container now accept resources field

Bug fixes

• [KO-53] - Fixed XDR list fields ship-bins and ship-sets being ignored
• [KO-39] - Fixed incorrect custom initContainers volume mount paths

Known Issues

• There is a known issue in OLM based installations (OperatorHub.io and on Red Hat OpenShift) where upgrade to version 2.1.0 from 2.0.0, causes revoking of RBAC privileges required to run Aerospike clusters in Kubernetes namespaces other than the aerospike namespace. If you are running Aerospike clusters in Kubernetes namespaces other than the aerospike namespace, re-grant the RBAC privileges following instructions here.

Release 2.0.0

[PROD-1783] - Allow for hostNetwork to be set for Aerospike statefulset in CR
[PROD-1902] - Create a load balancer, optionally, for clients to discover Aerospike Pods in a cluster using the load balancer
[PROD-1782] - Allow multiple secrets to be mounted on Aerospike containers
[PROD-1785] - Allow for a configurable list of TLS certs on the server (multiple values for tls-authenticate-client)
[PROD-1786] - Allow configurable non-default ports for heartbeat, fabric, and service traffic.
[PROD-1888] - Use $MY_POD_NAME instead of hostname since it is not guaranteed to be the same as the pod's name
[PROD-1910] - Allow the deployment of a cluster with any number of replicas regardless of the number of racks configured
[PROD-2213] - Control Aerospike Pod placement with configuration by allowing affinity, anti-affinity, and tolerations to be specified
[PROD-2214] - Support OLM
[PROD-2215] - Helm charts for operator 2.0
[PROD-2216] - Support Aerospike Enterprise Server 5.6.x and 5.7.x
[PROD-2217] - Support Kubernetes 1.20, 1.21 and 1.22

Breaking changes

The 2.0.0 custom resource spec has breaking changes to accommodate increased flexibility and broader coverage of deployments.

Release 1.0.1

[CLOUD-59] - Unchanged PodSpec triggers a one-time rolling restart
[CLOUD-60] - Log correct operator version
[CLOUD-61] - Cleanup dangling racks and StatefulSets
[CLOUD-62] - Ignore non-running pods scheduled to be deleted during cluster stability checks
[CLOUD-63] - Fix occasional tip-clear failures after scale down

Release 1.0.0

1.0.0 GA release of Aerospike Kubernetes Operator

Release 0.0.11-beta

Beta release of Aerospike Kubernetes Operator