Migrating to 2.11.0

Migration Guide

Here you can find the needed steps to upgrade your current Witboost installation to v2.11.0. Please refer to the release notes for a detailed list of changes and improvements. This guide is intended for users who are currently running Witboost version 2.10.x and wish to upgrade to version 2.11.0.

Follow these steps to migrate from the previous version to Witboost version 2.11.0:

Backup Your Data

Before starting the migration, ensure you have a complete backup of your database and configuration files.

Upgrade Steps

If you are using the Witboost Infrastructure CLI, you can execute the following command to automatically migrate your configuration file by replacing the placeholder <path_to_values.yaml> with the path to your values.yaml file:

witboost-infra transform --user-values <path_to_values.yaml> --current-version <your_current_version> --set-target 2.11.0 --output-path <path_to_values.yaml>

---

Hook Jobs: Migration from waitForSecretHook to witboost-hooks

Automatically handled by Infra CLI

In v2.11.0, the pre-install/pre-upgrade hook jobs have been extracted from the Witboost umbrella chart into a dedicated subchart (witboost-hooks). The waitForSecretHook key is retired and replaced by witboost-hooks.

The new hook uses a Witboost-built image (witboost-hooks) instead of curlimages/curl. Its image coordinates, security context, and job configuration are managed by the chart's own defaults — you do not need to specify them in your values.yaml unless you have environment-specific requirements.

What the Infra CLI does automatically

The CLI moves the following user-configured keys from the old structure to the new one, then removes the waitForSecretHook key entirely:

Old path	New path
waitForSecretHook.enabled	witboost-hooks.enabled
waitForSecretHook.nodeSelector	witboost-hooks.secretWaiter.nodeSelector
waitForSecretHook.tolerations	witboost-hooks.secretWaiter.tolerations
waitForSecretHook.affinity	witboost-hooks.secretWaiter.affinity
waitForSecretHook.resources	witboost-hooks.secretWaiter.resources

If a key was not set in waitForSecretHook, the move is skipped — the chart default applies for that key at deploy time.

The following keys are not migrated automatically — they are either no longer relevant or handled differently:

• waitForSecretHook.image.* — the new chart uses a completely different image; the old curlimages/curl reference is discarded.

If waitForSecretHook is absent from your values.yaml, no action is taken — the chart defaults for witboost-hooks apply automatically at deploy time.

Private registry users

If you were mirroring curlimages/curl to a private registry and referencing it under waitForSecretHook.image.repository, that reference is not carried forward. The new chart uses a different image entirely.

Before upgrading you must mirror the new witboost-hooks image to your private registry:

witboost-infra mirror-images --witboost-version 2.11.0 --target <your-private-registry> ...

After mirroring, set the new image path in your values.yaml:

witboost-hooks:
  image:
    repository: <your-private-registry>/witboost-hooks

---

witboost-mcp-client: Service Removal

Automatically handled by Infra CLI — requires manual action if the service was enabled

The witboost-mcp-client service has been merged into Witty and is no longer a standalone chart. The Infra CLI removes its configuration block and its reference from the Witty service config.

Behaviour by case

Condition	CLI action
witboost-mcp-client is absent from values.yaml	No action
witboost-mcp-client.enabled: false	The entire block is removed. witty.configOverride.witboost_mcp_client is also removed(if present).
witboost-mcp-client.enabled: true	Migration is aborted with the error below. You must act before re-running.

When the migration is aborted due to an enabled mcp-client, the CLI outputs:

Condition failed: 'witboost-mcp-client.enabled' must be 'false'. Please disable it before proceeding.

Manual action required if witboost-mcp-client was enabled

If you had witboost-mcp-client.enabled: true, the migration will abort until you take the following steps:

1. Set witboost-mcp-client.enabled: false in your values.yaml.
2. Re-run the transform command — the CLI will then remove the block automatically and proceed.

---

Reloader: Container Security Context and Tag Pin Cleanup

Automatically handled by Infra CLI

Two changes are applied to the reloader block:

1. Container security context — the following is injected under reloader.reloader.deployment if not already present:

reloader:
  reloader:
    deployment:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        runAsUser: 1001

If you already have a containerSecurityContext block there, it is left completely untouched.

2. Explicit image tag pin — if your values.yaml has reloader.image.tag: v1.4.16 (set by the 2.10 migration), it is removed, chart default takes in effect. Any custom tag other than v1.4.16 is left untouched.

---

configOverride Format: YAML is now the required standard

note

This is not a migration rule — no automatic transformation is applied. This is an important note for any operator who has not yet converted their configOverride blocks.

Starting from v2.9.0, the Infra CLI began converting configOverride values from HOCON format to YAML format for the following components:

• provisioning-coordinator
• mock-specific-provisioner
• governance-platform

From v2.11.0 onwards, configOverride blocks are expected to be in YAML format. If your values.yaml still contains HOCON-formatted configOverride blocks (identifiable by the { and } braces and unquoted keys typical of HOCON syntax), you must convert them to YAML manually before or during this upgrade.

Example — HOCON (deprecated):

governance-platform:
  configOverride: |-
    computational-governance-platform {
      database = {
        connection-timeout = 120 seconds
      }
    }

Example — YAML:

governance-platform:
  configOverride:
    computational-governance-platform:
      database:
        connection-timeout: 120 seconds

If you ran the Infra CLI migration for v2.9.0, this conversion was already applied to your values.yaml automatically.

---

UI Backend Security Context Hardening

note

This is an informational item only — it is not enforced by a migration rule. No automatic change is made to your values.yaml. Review and act according to your environment's requirements.

In v2.11.0, the default securityContext for the Witboost UI backend container has been hardened:

Field	Previous default	New default
runAsNonRoot	false	true
runAsUser	0 (root)	1000

If you are not overriding ui.backend.securityContext in your values.yaml, these secure defaults take effect automatically on upgrade and no action is required.

If you are overriding ui.backend.securityContext (for example, because your environment requires a specific UID or root access), your values are preserved as-is. You may optionally align with the new defaults:

ui:
  backend:
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 1000

warning

Before applying these changes, verify that the Witboost UI image is compatible with running as a non-root user in your environment. If your cluster enforces Pod Security Standards or OPA/Kyverno policies that require non-root containers, aligning with these defaults will help avoid policy violations.