NEXUS-50170: Fix StatefulSet updateStrategy to always use RollingUpdate

[SraavanChevireddy]

Problem Statement

The Nexus HA Helm chart was conditionally setting the StatefulSet updateStrategy to OnDelete when zeroDowntimeEnabled was false (which is the default configuration). This prevented customers from performing standard Kubernetes rolling updates and administrative activities.

Customer Impact: Hyundai reported that this affects their Kubernetes administration activities, as they cannot perform normal pod updates without manually deleting pods.

Root Cause Analysis

The issue was in nxrm-ha/templates/statefulset.yaml lines 23-26:

Before:

{{- if not .Values.statefulset.container.env.zeroDowntimeEnabled }}
updateStrategy:
  type: OnDelete
{{- end }}

This conditional logic meant:

• When zeroDowntimeEnabled: false (default) → updateStrategy.type: OnDelete
• When zeroDowntimeEnabled: true → No updateStrategy block (defaults to RollingUpdate)

The OnDelete strategy requires manual intervention to delete pods before they are updated, which is not standard Kubernetes behavior.

Solution Details

Changed the StatefulSet template to always use RollingUpdate strategy:

After:

updateStrategy:
  type: RollingUpdate

This ensures that Kubernetes will automatically perform rolling updates of StatefulSet pods when the Helm chart is upgraded, regardless of the Zero Downtime Upgrade setting.

Testing Verification

Template Changes

• File: nxrm-ha/templates/statefulset.yaml
• Change: Removed conditional logic, always set updateStrategy.type: RollingUpdate

Test Updates

Updated two tests in nxrm-ha/tests/statefulset_test.yaml:

1. Test: "should set zdu env to true and rollingUpgrades when zeroDowntimeEnabled is true"

   • Before: Expected spec.updateStrategy to be null
   • After: Expects spec.updateStrategy.type: RollingUpdate

2. Test: "should create nxrm-app container with dynamic nexusdata volume"

   • Before: Expected spec.updateStrategy.type: OnDelete
   • After: Expects spec.updateStrategy.type: RollingUpdate

Expected Behavior

With this fix, the rendered StatefulSet YAML will always include:

spec:
  updateStrategy:
    type: RollingUpdate

This applies to both scenarios:

• zeroDowntimeEnabled: false (default)
• zeroDowntimeEnabled: true

Impact on Customers

Positive Impact:

• Customers can now perform normal Kubernetes rolling updates without enabling the Zero Downtime Upgrade workaround
• StatefulSet pods will be automatically updated in a rolling fashion when the Helm chart is upgraded
• Aligns with standard Kubernetes StatefulSet update behavior

Zero Downtime Upgrade (ZDU) Functionality:

• ZDU functionality remains completely unaffected
• ZDU operates at the application level via the NEXUS_ZERO_DOWNTIME_ENABLED environment variable
• The updateStrategy setting does not interfere with ZDU's internal coordination mechanisms

Related Links

• JIRA Ticket: NEXUS-50170
• Customer: Hyundai
• Labels: jira_escalated, support_reviewed

Generated with Claude Code

[bobotimi]

This was done on purpose. Rolling upgrades should not be attempted unless ZDU is enabled to prevent database corruption.

It was intentionally done this way as we don't want rolling upgrades unless Zero downtime flag is enabled. Doing so will mean you can have two different versions of nexus (i.e., current version and new version being upgraded to) connected to the same postgres instance without the checks we have in place for the zero downtime feature.