Skip to main content
Contact the Anaconda implementation team before you begin for assistance upgrading your version of Data Science & AI Workbench. Follow along with these instructions as an Anaconda implementation team member guides you through the upgrade process. They will provide you with a Helm chart archive that contains all the components needed for upgrading.
  • Current versions of Workbench no longer support Postgres versions 9.6 and older. To align with these changes, you must update your Postgres to a supported version. Verify your Postgres version is compatible before you begin your upgrade.
  • It is important to stop all sessions prior to upgrading. If you do not, sessions that are terminated as part of the upgrade process must be restarted manually post upgrade.
  • Sessions can also be stopped programmatically using ae5-tools by running the following command in a terminal that has access to your Workbench cluster over the network:

Prerequisites

  • You must have access to the Administrative Server.
  • You must verify the Service Account used for the upgrade has the correct permissions.
  • Air-gapped servers must have the Docker images added to their Docker image repository.

Upgrading

Upgrade your BYOK8s cluster by performing the following steps:
  1. Log in to the service account on the Administrative Server running your Workbench software.
  2. Create a backup of your cluster configurations.
    This backup is the only reliable way to undo this upgrade later. Some Workbench components run forward database migrations when they start under the new chart version (confirmed for the git-storage service), and helm rollback does not reverse those migrations. Once a migration has run, rolling the release back to the prior version leaves that component unable to start against the now-newer database schema.Confirm the backup completed successfully before continuing. If you need to undo this upgrade after it has run, restore from this backup rather than relying on helm rollback alone.
  3. Unpack the Helm charts provided by Anaconda onto the Administrative Server:
  4. Save your current configurations with the extract_config.sh script delivered with your Helm chart:
    The extract_config.sh script creates a file called helm_values.yaml and saves it in the directory where the script was run.
  5. Verify the information captured in the helm_values.yaml file is correct and contains all of your current cluster configuration settings.
  6. Begin the upgrade:
    If the upgrade is successful, your output will look like this:
    The duration of the upgrade depends on both the cluster node count and the speed of the new Docker images loading into each node.

Verifying your upgrade

  1. Verify all pods are running:
  2. Open a web browser and navigate to your Authentication Center.
  3. Select Users from the left-hand navigation, then click View all users and verify your users’ data is present.
  4. Open a new tab in your web browser and navigate to your Workbench URL. Log in using the same credentials you used for your previous installation.
  5. Review the Projects list to verify that all project data has been restored.
  6. Verify your deployments have returned to a started state.
If you are upgrading from Workbench version 5.6.2 or older and have RStudio installed, you must reinstall RStudio. This is due to the upgrade of the Workbench base image from UBI8 to UBI9 in version 5.7. UBI9 requires a different binary for RStudio.

Troubleshooting a failed rollback

Rolling back a Workbench upgrade with helm rollback can fail with a conflict on the kubernetes-dashboard-csrf secret:
The kubernetes-dashboard-csrf secret is written by two different owners: the Helm chart and the Kubernetes Dashboard application itself, which generates a real CSRF token at runtime under its own field manager.
  • helm upgrade re-renders the chart on every run, so it stays in sync with whatever the Dashboard has since written.
  • helm rollback does not re-render anything; it reapplies the exact secret content captured at the time the target revision was installed or upgraded to.
By the time you need to roll back, that captured content has almost always diverged from what the Dashboard has written since, and Kubernetes’ server-side apply rejects the conflicting write. Deleting the secret before retrying removes the stale content so the rollback can apply cleanly, and restarting the Dashboard pod ensures it picks up the resulting token instead of continuing to use the one it cached at startup.
This affects Workbench chart versions prior to ae-helm-chart-1.1-364. Use the following steps to complete the rollback:
  1. Find the revision number you want to roll back to:
  2. Delete the conflicting secret, then retry the rollback:
    Kubernetes and Helm recreate the secret cleanly once there is no longer a live value to conflict with.
  3. Restart the Workbench Dashboard pod:
    The Dashboard process reads and caches its CSRF token only once, at startup, so it will not notice that the secret changed until it restarts. If this label selector does not match any pods in your environment, find the pod name first and delete it directly:
  4. Confirm the rollback succeeded:
    The csrf field should return a non-empty base64 value, and the Dashboard pod should show 1/1 Running.