Skip to content

0.4.2

Latest
Latest

Choose a tag to compare

View all tags
@openbao-operator-release-tag openbao-operator-release-tag released this 15 Jul 11:59
Immutable release. Only release title and notes can be modified.
0.4.2
This tag was signed with the committer’s verified signature.
dc-tec Roel de Cort
GPG key ID: A5ABD477540DEB59
Verified
Learn about vigilant mode.
1a88724
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

OpenBao Operator 0.4.2 allows an existing OpenBaoCluster to change its
upgrade strategy while the cluster is healthy and idle. This gives clusters
configured for BlueGreen a supported path to use the validated rolling
upgrade to OpenBao 2.6.x without snapshotting and recreating the cluster.

If you do not use BlueGreen and do not plan to switch to it, there is no need
to update from OpenBao Operator 0.4.1 to 0.4.2. Version 0.4.1 already supports
the validated rolling upgrade to OpenBao 2.6.x. Upgrade to 0.4.2 when an
existing cluster needs to change its upgrade strategy.

Idle Upgrade Strategy Switching

Initialized clusters can now change spec.upgrade.strategy in either
direction:

  • BlueGreen to RollingUpdate
  • RollingUpdate to BlueGreen

The operator accepts a strategy change only after every voter and configured
read replica is Ready, status.currentVersion equals spec.version, and no
upgrade, rollback, backup, restore, resize, restart, Green workload, pending
request, failure, operation lock, or safe-mode recovery is active. Unsafe
changes are rejected with recovery guidance.

Patch only spec.upgrade.strategy, then wait for
status.acceptedUpgradeStrategy to report the requested strategy before
changing spec.version, spec.image, replicas, storage, or restart controls.
The active StatefulSet and its PVCs remain the stable workload during the
strategy transition.

Switching to BlueGreen requires a resolvable upgrade executor image and a JWT
role with the BlueGreen upgrade capabilities. Self-init policies created for a
rolling-origin cluster are not rewritten by a later strategy change, so update
that role policy before requesting BlueGreen when necessary.

OpenBao 2.6.x Upgrade Guidance

The mixed-version OpenBao incompatibility remains: a pre-2.6 Blue leader cannot
safely promote a 2.6-or-newer Green revision. OpenBao Operator continues to
block that BlueGreen transition before deploying Green.

For an existing pre-2.6 cluster configured for BlueGreen:

  1. Upgrade the OpenBao Operator CRDs and controller to 0.4.2.
  2. Let the cluster return to a healthy BlueGreen Idle state.
  3. Change only spec.upgrade.strategy to RollingUpdate.
  4. Wait for status.acceptedUpgradeStrategy=RollingUpdate.
  5. Request the OpenBao 2.6.x version change separately.

Do not combine the strategy and OpenBao version changes in one request.
Clusters that already use RollingUpdate can remain on OpenBao Operator 0.4.1
for the validated OpenBao 2.6.x rolling upgrade.

CRD Upgrade Required

This patch adds status.acceptedUpgradeStrategy and
status.upgrade.blueGreen.blueControllerRevision to the OpenBaoCluster CRD.
Apply the 0.4.2 CRDs before upgrading the controller. Helm does not upgrade
installed CRDs automatically:

kubectl apply -f https://github.com/dc-tec/openbao-operator/releases/download/0.4.2/crds.yaml

The existing 0.4.0 versioned documentation remains the release-line snapshot
and has been refreshed with the strategy-switch procedure, OpenBao 2.6.x
guidance, and the new status fields.

0.4.2 (2026-07-15)

Bug Fixes

  • upgrade: allow idle strategy switching on 0.4.x (#552) (3501400)
Assets 14
Loading