|
| 1 | +# Migrating from Versioned to Unversioned Workflows |
| 2 | + |
| 3 | +This guide walks you through reverting from worker versioning back to unversioned Temporal Workflows. It assumes you have enabled worker versioning and currently have (or previously had) versioned workers polling the Temporal Server. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Table of Contents |
| 8 | + |
| 9 | +- [Prerequisites](#prerequisites) |
| 10 | +- [Migration Steps](#migration-steps) |
| 11 | + - [Step 1: Update Worker Code](#step-1-update-worker-code) |
| 12 | + - [Step 2: Deploy the Unversioned Worker](#step-2-deploy-the-unversioned-worker) |
| 13 | + - [Step 3: Set Current Version to Unversioned](#step-3-set-current-version-to-unversioned) |
| 14 | +- [Monitoring the Migration](#monitoring-the-migration) |
| 15 | +- [Cleanup and Garbage Collection](#cleanup-and-garbage-collection) |
| 16 | + |
| 17 | +--- |
| 18 | + |
| 19 | +## Prerequisites |
| 20 | + |
| 21 | +Before starting the migration, ensure you have: |
| 22 | + |
| 23 | +- ✅ **Temporal CLI** version >= 1.5.0 |
| 24 | + |
| 25 | +--- |
| 26 | + |
| 27 | +## Migration Steps |
| 28 | + |
| 29 | +### Step 1: Update Worker Code |
| 30 | + |
| 31 | +Update your worker initialization code to remove versioning configuration. |
| 32 | + |
| 33 | +**Before (Versioned):** |
| 34 | + |
| 35 | +```go |
| 36 | +// Worker must use the build ID and deployment name from environment variables. |
| 37 | +// These are set on the deployment by the controller. |
| 38 | +buildID := os.Getenv("TEMPORAL_WORKER_BUILD_ID") |
| 39 | +deploymentName := os.Getenv("TEMPORAL_DEPLOYMENT_NAME") |
| 40 | +if buildID == "" || deploymentName == "" { |
| 41 | + // exit with an error |
| 42 | +} |
| 43 | + |
| 44 | +workerOptions := worker.Options{ |
| 45 | + DeploymentOptions: worker.DeploymentOptions{ |
| 46 | + UseVersioning: true, |
| 47 | + Version: worker.WorkerDeploymentVersion{ |
| 48 | + DeploymentName: deploymentName, |
| 49 | + BuildID: buildID, |
| 50 | + }, |
| 51 | + }, |
| 52 | +} |
| 53 | +worker := worker.New(client, "my-task-queue", workerOptions) |
| 54 | +``` |
| 55 | + |
| 56 | +**After (Unversioned):** |
| 57 | + |
| 58 | +```go |
| 59 | +// Worker connects without versioning |
| 60 | +worker := worker.New(client, "my-task-queue", worker.Options{}) |
| 61 | +``` |
| 62 | + |
| 63 | +### Step 2: Deploy the Unversioned Worker |
| 64 | + |
| 65 | +Deploy the updated worker so that unversioned pollers begin polling the system. |
| 66 | + |
| 67 | +> **Note:** If using the Worker Controller, change the Rollout Strategy in your `TemporalWorkerDeployment` custom resource to `Manual`. This will prevent the controller from automatically setting a new current version. |
| 68 | +
|
| 69 | +### Step 3: Set Current Version to Unversioned |
| 70 | + |
| 71 | +Run the following Temporal CLI command to set the current version of the Worker Deployment to *unversioned*: |
| 72 | + |
| 73 | +```bash |
| 74 | +temporal worker deployment set-current-version \ |
| 75 | + --deployment-name <your-deployment-name> \ |
| 76 | + --build-id "" |
| 77 | +``` |
| 78 | + |
| 79 | +--- |
| 80 | + |
| 81 | +## Monitoring the Migration |
| 82 | + |
| 83 | +After completing the migration steps: |
| 84 | + |
| 85 | +1. **Verify in the Temporal UI** that traffic is gradually shifting from versioned workers to unversioned workers. |
| 86 | +2. **AutoUpgrade workflows** will eventually move onto the unversioned worker(s). |
| 87 | +3. **Pinned workflows** that were started on versioned workers will continue and complete execution on those pinned workers. |
| 88 | + |
| 89 | +--- |
| 90 | + |
| 91 | +## Cleanup and Garbage Collection |
| 92 | + |
| 93 | +This section highlights the ways in which one can delete the corresponding Worker Versions or Worker Deployment resources that were created in Temporal. |
| 94 | + |
| 95 | +### Deleting Kubernetes Deployments created with the Worker-Controller: |
| 96 | + |
| 97 | +The Worker Controller will delete Kubernetes Deployments, which represent versioned workers, based on your configured Sunset Strategy. The Worker Controller deletes Kubernetes Deployments for a version once the time since it became drained exceeds the combined `Scaledown` and `Sunset` delay. Deleting these deployments stops the workers from polling the Temporal Server, which is a pre-requisite for deleting a Worker-Version. |
| 98 | + |
| 99 | +### Deleting Worker Versions |
| 100 | + |
| 101 | +A Worker Version can be deleted once it has been drained and has no active pollers. |
| 102 | +Once it's drained and without active pollers, delete the Worker Version using: |
| 103 | + |
| 104 | +```bash |
| 105 | +temporal worker deployment delete-version \ |
| 106 | + --deployment-name <your-deployment-name> \ |
| 107 | + --build-id <your-build-id> |
| 108 | +``` |
| 109 | + |
| 110 | +> **Tip:** To skip the drainage requirement, add the `--skip-drainage` flag: |
| 111 | +> |
| 112 | +> ```bash |
| 113 | +> temporal worker deployment delete-version \ |
| 114 | +> --deployment-name <your-deployment-name> \ |
| 115 | +> --build-id <your-build-id> \ |
| 116 | +> --skip-drainage |
| 117 | +> ``` |
| 118 | +
|
| 119 | +### Deleting the Worker Deployment |
| 120 | +
|
| 121 | +To delete a Worker Deployment: |
| 122 | +
|
| 123 | +1. First, ensure all its Worker Versions have been deleted. |
| 124 | +2. Then run: |
| 125 | +
|
| 126 | +```bash |
| 127 | +temporal worker deployment delete --name <your-deployment-name> |
| 128 | +``` |
0 commit comments