Upgrade from DataRobot v11.x to the latest release¶

This section provides a checklist of tasks that are required when upgrading from any DataRobot 11.x version to the latest release version.

Upgrade to latest release¶

In the latest release, the PCS and DataRobot charts have been consolidated into a single chart. This change eliminates code duplication and simplifies the installation process.

Update values¶

The latest DataRobot release introduces minor changes to the YAML configuration schema. Therefore, adjust the existing configuration to match the new schema.

Minimal values files¶

For platform-specific configuration examples, refer to the minimal values files located within the datarobot-prime/override Helm chart artifact directory.

tar xzf datarobot-prime-X.X.X.tgz
cd datarobot-prime/override

Use the current values_dr.yaml file as a reference when populating the minimal values files.

Upgrade GenAI¶

Enable the LLM gateway service in values_dr.yaml. For details, see the Generative AI documentation.

Review external PCS PostgreSQL extensions¶

If you use external PCS and plan to enable the Memory Service (available in 11.9 and later), your external PostgreSQL instance must provide the pgvector and pg_trgm extensions. On AWS RDS and Google Cloud SQL these are available by default and are created automatically when DataRobot connects as a superuser. Two cases require manual action before you enable the service:

• Azure Database for PostgreSQL blocks CREATE EXTENSION until VECTOR and PG_TRGM are allowlisted in the server parameters.
• Limited-permission database users that cannot run CREATE EXTENSION require the extensions to be created manually.

For the exact steps, see the cloud-specific guide: AWS, Azure, or Google Cloud.

Migrate Workload API data from the admin database¶

This applies only if you used the Workload API during its Private Preview (in 11.9 or 11.10), run external PCS with a full MONGODB_URI override, and are upgrading from those releases. If that override's connection string pointed at the admin database, Workload API data was written to admin; run the one-off migrateFromAdmin job during the upgrade to relocate it. See Migrate Workload API data from the admin database. Most installations are unaffected and can skip this.

Review custom CA bundle configuration¶

If you are using Trust Manager and deploying custom CA bundles to manage root certificates across the DataRobot platform, verify the structure of the ca-cert-bundle.yaml file. For details, see configuring Custom CA upgrade notes.

Review notebook configuration¶

The naming for notebook chart values was updated. This change may impact your process. For detailed instructions, see the Notebooks Upgrade Guide.

Application upgrade steps¶

Set DataRobot namespace¶

export NAMESPACE="DATAROBOT_NAMESPACE"

Delete Elasticsearch certificate¶

kubectl -n ${NAMESPACE} delete secret pcs-elasticsearch-master-crt

Temporarily disable PostgreSQL HA¶

If High Availability (HA) is configured for PostgreSQL, reduce the PostgreSQL replicaCount to prevent potential conflicts during the upgrade:

postgresql-ha:
    postgresql:
        replicaCount: 1

Verify that the current PostgreSQL primary node is pcs-postgresql-0:

kubectl exec -i -t -n ${NAMESPACE}  pcs-postgresql-0 -c postgresql -- bash -c "/opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh repmgr cluster show -f /opt/bitnami/repmgr/conf/repmgr.conf --compact"

Scale down the PostgreSQL StatefulSet to 1 replica:

kubectl scale sts pcs-postgresql --replicas=1 -n ${NAMESPACE}

Apply API gateway CRDs¶

The latest release introduces the API gateway as a subchart of the datarobot-prime chart. Helm only installs the custom resource definitions (CRDs) located in a chart's crds/ directory during the initial installation, not during a helm upgrade. Therefore, apply the API gateway CRDs manually before running the Helm upgrade to ensure they are present in the cluster.

Extract the datarobot-prime chart artifact and apply the API gateway CRDs from the bundled subchart:

tar xzf datarobot-prime-X.X.X.tgz
kubectl apply --server-side --force-conflicts -f datarobot-prime/charts/api-gateway/crds/

Upgrade Helm to latest version¶

helm upgrade --install dr datarobot-prime-X.X.X.tgz \
--namespace ${NAMESPACE} \
--values values_dr.yaml \
--debug \
--timeout 20m

Post-upgrade tasks¶

After your helm upgrade command completes successfully and the application pods are running, perform any applicable final steps from the sections below to complete the upgrade process.

Scale PostgreSQL replica¶

If High Availability (HA) for PostgreSQL is required, scale the PostgreSQL replica count back up to the desired value to restore HA functionality.

kubectl scale statefulset pcs-postgresql --replicas=3 -n ${NAMESPACE}

postgresql-ha:
    postgresql:
        replicaCount: 3

Upgrade GenAI¶

Every installation that includes a GenAI subsystem requires a static files migration and execution environment migration. This is done automatically for installations with internet access; however, offline clusters must do this manually:

• Migrate static files.
• Migrate execution environments.

Delete orphaned OTEL collector volumes¶

When datarobot-otel-collector upgrades, it creates new PersistentVolumeClaims (PVCs) with a -v2 suffix. The original PVCs (without the -v2 suffix) are no longer used and should be deleted. These volumes only hold a cache for otel collector metrics/traces/logs and are safe to delete after the upgrade.

List the existing PVCs to identify the ones without the v2 suffix:

kubectl get pvc -n ${NAMESPACE} | grep -i otel
exporter-persistent-storage-datarobot-otel-collector-exporter-0      Bound     pvc-dd4544f4-ff3e-4776-934b-26d7e3a5e9f0   1Gi        RWO            gp3-csi        <unset>                 179d
exporter-persistent-storage-datarobot-otel-collector-exporter-1      Bound     pvc-41755fd6-5b06-482e-9d9f-3bf9926de8be   1Gi        RWO            gp3-csi        <unset>                 48d
exporter-persistent-storage-datarobot-otel-collector-exporter-v2-0   Bound     pvc-9d11d327-2436-4c63-9189-2a240d4db68e   5Gi        RWO            gp3-csi        <unset>                 43h
exporter-persistent-storage-datarobot-otel-collector-exporter-v2-1   Bound     pvc-c78c7e1b-9a37-4104-b67c-ec1c9dbbaf8e   5Gi        RWO            gp3-csi        <unset>                 43h

Delete each orphaned PVC, the ones without v2, the originals that should be 1Gi in size:

kubectl delete pvc -n ${NAMESPACE} exporter-persistent-storage-datarobot-otel-collector-exporter-0
kubectl delete pvc -n ${NAMESPACE} exporter-persistent-storage-datarobot-otel-collector-exporter-1

The corresponding PersistentVolumes (PVs) are automatically reclaimed once the PVCs are deleted. Verify that no orphaned PVs remain:

kubectl get pv | grep -i otel