Upgrading Dynamic Engine to 1.7.0 with persistent storage

Last updated: 10/13/2026

Use this procedure when upgrading from 1.6.x to 1.7.0 with persistence still enabled in 1.6.x.

Important: If you already disabled configuration.persistence.enabled in 1.6.x, follow the generic upgrade procedure instead. This procedure covers Helm deployments only. Manifest-based deployments cannot be migrated to Helm.

Before you begin

You must have the Infrastructure Administrator role to upgrade the Dynamic Engine version.

About this task

In 1.7.0, persistence is disabled by default. During an upgrade from 1.6.x, the Helm upgrade can attempt to delete existing persistent volume claims (PVCs) unless persistence is enabled in the new values file.

This procedure covers the storage decision for DI (data integration) Jobs in an external Docker registry.

Tip: Embedded registry persistence is configured separately with configuration.dockerRegistry.persistence.enabled and not recommended for production use.

In a production environment, use an external Docker registry instead. See Configuring a custom Docker registry for Talend Management Console tasks for recommended configuration.

Procedure

Check whether persistence is enabled for the existing environment.
Review the environment values file used for the 1.6.x Helm release. If configuration.persistence.enabled is false, use the generic upgrade procedure. If it is true or omitted, continue with this procedure.
Choose whether to keep or drop the existing persistent storage.
- Typically, you need to keep the persistence for data used by data integration Jobs. To keep persistence , set configuration.persistence.enabled to true in the environment values file. Set configuration.persistence.defaultStorageClassName to the storage class to use, or leave it null to use the cluster default.
```
configuration:
  persistence:
    enabled: true
    defaultStorageClassName: <storage-class-name-or-null>
```
- To drop persistence, do not add persistence configuration. The upgrade can delete the existing PVCs.
If your data integration tasks are scheduled or running during the upgrade and you want to preserve their existing resources, annotate the PVCs and ConfigMaps before upgrading.
```
kubectl annotate pvc -A -l app=di-job-deployer helm.sh/resource-policy=keep --overwrite
kubectl annotate cm -A -l app=di-job-controller helm.sh/resource-policy=keep --overwrite
```
The annotations prevent Helm from deleting the selected resources during the upgrade. You can then delete the unused PVCs later.
Upgrade the engine and environment by following the generic upgrade procedure.

Information noteWarning: If you still need to use the embedded image registry for persistence, before upgrading the engine,
enable persistence for the registry. Set configuration.dockerRegistry.persistence.enabled=true in the engine values file. Without it, images can be lost if the registry pod restarts.

This internal Docker registry is for the development environment only.
Verify the deployment and inspect the existing PVCs you want to keep.
```
kubectl get pvc -A -l app=di-job-deployer
```
The previous di-job-deployer pod can continue to use its PVC while it runs. Do not remove a PVC that is still in use.
Optional: When the old pod no longer uses the PVCs, delete the unused PVCs if you no longer need them.
```
kubectl delete pvc -A -l app=di-job-deployer
```
To review and delete PVCs individually, list them first:
```
kubectl get pvc -A -l app=di-job-deployer
kubectl delete pvc -n <namespace> <pvc-name>
```

Results

Persistence remains enabled for the data used by data integration Jobs when you chose to keep it. Remove old PVCs only after confirming that no running pod uses them.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!

Leave your feedback here