GPSS Operator 1.3.0 to 1.3.1 upgrade behavior for existing GpssCluster resources

Products

VMware Tanzu Data VMware Tanzu Greenplum VMware Tanzu Greenplum / Gemfire VMware Tanzu Data Suite VMware Tanzu Data Suite

Issue/Introduction

After upgrading VMware Tanzu Greenplum Streaming Server (GPSS) Operator from version 1.3.0 to 1.3.1, questions may arise about whether existing GpssCluster resources are automatically upgraded to the new runtime image and whether any Custom Resource Definition (CRD) migration is required.

The published upgrade documentation describes the Operator upgrade process but does not explicitly describe the behavior of existing GpssCluster resources.

This article explains the supported upgrade behavior, runtime image update process, CRD compatibility, and expected behavior for GPSS jobs during the upgrade.

Environment

GPSS Operator 1.3.0

Cause

The GPSS Operator manages the lifecycle of GPSS clusters, but it does not automatically modify the runtime image specified in a GpssCluster resource.

The runtime image is explicitly controlled by the spec.image field in each GpssCluster Custom Resource.

Resolution

Operator Upgrade Behaviour

Upgrading the GPSS Operator from 1.3.0 to 1.3.1 replaces only the Operator controller image.

Existing GPSS clusters continue running the runtime image currently specified in their spec.image field.

For example:

#Current runtime image:

gpss-instance-gpdb6.gpssk8s-1.3.0.2.3.0.tar.gz

#Available runtime image in GPSS 1.3.1:

gpss-instance-gpdb6.gpssk8s-1.3.1.2.3.1.tar.gz

Does the GpssCluster runtime image upgrade automatically ?

No. The Operator does not automatically update the runtime image referenced by existing GpssCluster resources.

To use the GPSS 1.3.1 runtime image, manually update the spec.image field for each GpssCluster.

The 1.3.1 runtime image primarily refreshes the base image and bundled operating system packages to address known security vulnerabilities (CVEs).

Is a CRD upgrade required?

No. The GpssCluster CRDs are identical between GPSS Operator 1.3.0 and 1.3.1.

No CRD migration, schema update, or manual CRD upgrade is required.

Supported Procedure to upgrade existing clusters

Make the GPSS 1.3.1 runtime image available in the image registry accessible by the Kubernetes cluster.
Upgrade the GPSS Operator to version 1.3.1 using the documented Helm upgrade procedure.
Update the spec.image field of each GpssCluster resource to reference the GPSS 1.3.1 runtime image.
Allow the Operator to perform a rolling update.
Verify that all GPSS pods become Ready and confirm cluster health after the rollout completes.

During the rolling update:

New pods are started before old pods are removed.
The GPSS service endpoint remains available throughout the upgrade.
Existing pods are replaced one at a time.

Behavior of GpssJob resources during upgrade

This behavior applies only to jobs managed as GpssJob resources.

Jobs submitted manually outside of a GpssJob resource are not tracked by the Operator.

Will running jobs continue without interruption ?

No. A running job executes on a specific GPSS pod.

When that pod is replaced during the rolling update, the job experiences a brief interruption.

GPSS resumes processing from the last committed offset, so the interruption does not result in data loss.

Is rolling upgrade supported?

Yes.The Operator performs a rolling update while keeping the GPSS service endpoint available.

Are jobs automatically restarted?

Jobs managed by GpssJob resources are automatically restarted and resumed by the Operator.
Jobs submitted manually must be restarted manually after the upgrade.

Recommendations before Upgrading

Manage workloads using GpssJob resources whenever possible.
Verify that the GPSS 1.3.1 runtime image is available in the image registry before beginning the upgrade.
For latency-sensitive or critical data pipelines, stop jobs gracefully before upgrading and restart them after the upgrade completes.
Verify that all jobs have returned to the Running state and confirm data ingestion after the upgrade.