Upgrade OpenShift Dev Spaces
Plan and perform upgrades to keep your deployment current
Abstract
Preface
Upgrade your OpenShift Dev Spaces deployment to the latest version to receive bug fixes, security patches, and new capabilities with minimal disruption.
Chapter 1. Plan your upgrade
Plan your OpenShift Dev Spaces upgrade by reviewing supported upgrade paths, choosing an update approval strategy, and completing the pre-upgrade checklist so that the upgrade proceeds without disruption.
1.1. How the upgrade works
Understand what happens during an OpenShift Dev Spaces upgrade so that you can plan the timing, communicate downtime expectations, and verify the result.
When you upgrade OpenShift Dev Spaces, the Operator handles the server component upgrade automatically. You do not need to manually update individual pods or configurations. The Operator:
- Replaces the OpenShift Dev Spaces server, dashboard, gateway, and plugin registry pods with the new version.
- Upgrades the Dev Workspace Operator to the version bundled with the new release.
-
Preserves the existing
CheClustercustom resource configuration.
Running workspaces are not automatically restarted during the upgrade. Developers must stop their workspaces before the upgrade and restart them after the upgrade completes.
1.1.1. Supported upgrade path
OpenShift Dev Spaces supports upgrading from the previous minor version to the current version. For example, upgrading from OpenShift Dev Spaces 3.27 to OpenShift Dev Spaces 3.29.
Direct upgrades that skip minor versions are not supported. If your deployment is more than one minor version behind, upgrade one minor version at a time.
1.1.2. OpenShift version compatibility
OpenShift Dev Spaces 3.29 is supported on OpenShift 4.16 through 4.22. Before you upgrade OpenShift Dev Spaces, verify that your OpenShift cluster version is within this range.
1.1.3. Review the release notes
Review the release notes before upgrading to understand new features, bug fixes, and any changes that might affect your deployment. For the full release notes, see Additional resources.
1.2. Choose how updates are applied
Choose between automatic and manual update approval for the Red Hat OpenShift Dev Spaces Operator so that you control when new versions are installed on your cluster.
The Red Hat OpenShift Dev Spaces Operator supports two upgrade strategies:
Automatic- The Operator installs new updates when they become available.
Manual- New updates need to be manually approved before installation begins.
Prerequisites
- You have an OpenShift web console session as a cluster administrator. See Accessing the web console.
- You have an instance of OpenShift Dev Spaces installed by using Red Hat Ecosystem Catalog.
Procedure
- In the OpenShift web console, navigate to → .
- Click Red Hat OpenShift Dev Spaces in the list of installed Operators.
- Navigate to the Subscription tab.
-
Configure the Update approval strategy to
AutomaticorManual.
Additional resources
1.3. Pre-upgrade checklist
Complete the following checklist before upgrading OpenShift Dev Spaces so that no work is lost and the upgrade proceeds without errors.
| Step | Action |
|---|---|
| 1 | Review the This content is not included.OpenShift Dev Spaces 3.29 release notes for breaking changes and new features. |
| 2 | Verify that your OpenShift cluster version is between 4.16 and 4.22. |
| 3 | Notify developers to save and push all uncommitted work in their running workspaces. |
| 4 | Stop all running workspaces. The upgrade does not automatically stop workspaces, and running workspaces might encounter errors during the upgrade. |
| 5 |
If you plan to upgrade from the command line, install |
| 6 | Verify the current OpenShift Dev Spaces Operator subscription and update approval strategy. See Section 1.2, “Choose how updates are applied”. |
Chapter 2. Upgrade from the web console
Upgrade OpenShift Dev Spaces to the latest version from the OpenShift web console so that your developers receive bug fixes, security patches, and new features without requiring command-line access.
2.1. Approve a pending upgrade in the web console
Approve a pending Red Hat OpenShift Dev Spaces Operator upgrade in the OpenShift web console so that your deployment receives the latest features, bug fixes, and security patches at the time you choose.
Prerequisites
- You have an OpenShift web console session as a cluster administrator. See Accessing the web console.
- You have an instance of OpenShift Dev Spaces installed by using the Red Hat Ecosystem Catalog.
-
You have the approval strategy in the subscription set to
Manual. See Section 1.2, “Choose how updates are applied”.
Procedure
- Manually approve the pending Red Hat OpenShift Dev Spaces Operator upgrade. See Manually approving a pending Operator upgrade.
Verification
- Navigate to the OpenShift Dev Spaces instance.
- The 3.29 version number is visible at the bottom of the page.
Additional resources
Chapter 3. Upgrade from the command line
Upgrade OpenShift Dev Spaces to the latest version using the dsc CLI management tool so that you can automate upgrades or upgrade deployments in restricted environments. Reinstall dsc to version 3.29 before you begin. For installation instructions, see Additional resources.
3.1. Upgrade by using the dsc management tool
Upgrade OpenShift Dev Spaces from the previous minor version by using the dsc management tool so that your deployment receives the latest bug fixes, security patches, and features.
Prerequisites
- You have an administrative account on OpenShift.
-
You have a previous minor version of CodeReady Workspaces installed using the CLI management tool on the same instance of OpenShift, in the
openshift-devspacesproject. -
You have
dscfor OpenShift Dev Spaces version 3.29 installed. See This content is not included.Installing the dsc management tool.
Procedure
- Save and push changes back to the Git repositories for all running CodeReady Workspaces 3.27 workspaces.
- Shut down all workspaces in the CodeReady Workspaces 3.27 instance.
Upgrade OpenShift Dev Spaces:
$ dsc server:update -n openshift-devspaces
NoteFor slow systems or internet connections, add the
--k8spodwaittimeout=1800000flag option to extend the Pod timeout period to 1800000 ms or longer.
Verification
- Navigate to the OpenShift Dev Spaces instance.
- The 3.29 version number is visible at the bottom of the page.
3.2. Upgrade in an air-gapped environment
Upgrade OpenShift Dev Spaces on a cluster with no internet access by mirroring updated container images and Operator catalogs to your private registry before running the upgrade.
Prerequisites
-
You have the OpenShift Dev Spaces instance installed on OpenShift using the
dsc --installer operatormethod in theopenshift-devspacesproject. See This content is not included.Install OpenShift Dev Spaces in a restricted environment. - You have an OpenShift cluster with at least 64 GB of disk space.
- You have an OpenShift cluster ready to operate on a restricted network. See About disconnected installation mirroring and This page is not included, but the link has been rewritten to point to the nearest parent document.Using Operator Lifecycle Manager on restricted networks.
-
You have an active
ocsession with administrative permissions to the OpenShift cluster. See This page is not included, but the link has been rewritten to point to the nearest parent document.Getting started with the OpenShift CLI. -
You have an active
oc registrysession to theregistry.redhat.ioRed Hat Ecosystem Catalog. See Red Hat Container Registry authentication. -
You have the following tools installed:
opm(see Installing theopmCLI),jq(see Content from stedolan.github.io is not included.Downloadingjq),podman(see Content from podman.io is not included.Podman Installation Instructions), andskopeoversion 1.6 or higher (see Content from github.com is not included.Installing Skopeo). -
You have an active
skopeosession with administrative access to the private Docker registry. Content from github.com is not included.Authenticating to a registry, and Mirroring images for a disconnected installation. -
You have
dscfor OpenShift Dev Spaces version 3.29 installed. See This content is not included.Installing the dsc management tool.
Procedure
Download and execute the mirroring script to install a custom Operator catalog and mirror the related images: prepare-restricted-environment.sh.
$ bash prepare-restricted-environment.sh \ --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.22\ --devworkspace_operator_version "v0.41.0" \ --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.22" \ --prod_operator_package_name "devspaces" \ --prod_operator_bundle_name "devspacesoperator" \ --prod_operator_version "v3.29.0" \ --my_registry "<my_registry>"where:
<my_registry>- The private Docker registry where the images are mirrored
- In all running workspaces in the CodeReady Workspaces 3.27 instance, save and push changes back to the Git repositories.
- Stop all workspaces in the CodeReady Workspaces 3.27 instance.
Run the following command:
$ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
Verification
- Navigate to the OpenShift Dev Spaces instance.
- The 3.29 version number is visible at the bottom of the page.
Additional resources
Chapter 4. Verify the upgrade completed successfully
Verify that all OpenShift Dev Spaces components are running the new version and that the platform is functional so that you can confirm the upgrade succeeded before notifying developers.
Prerequisites
-
You have an active
ocsession with administrative permissions to the OpenShift cluster. See This page is not included, but the link has been rewritten to point to the nearest parent document.Getting started with the CLI.
Procedure
Verify that the OpenShift Dev Spaces Operator CSV shows the expected version and
Succeededphase:$ oc get csv -n openshift-devspaces -o custom-columns='NAME:.metadata.name,PHASE:.status.phase,VERSION:.spec.version'
Expected output:
NAME PHASE VERSION devspacesoperator.v3.29.0 Succeeded 3.29.0
Verify that the
CheClustercustom resource reportsActivephase and the correct version:$ oc get checluster devspaces -n openshift-devspaces -o jsonpath='Phase: {.status.chePhase}, Version: {.status.cheVersion}'Expected output:
Phase: Active, Version: 3.29.0
Verify that all OpenShift Dev Spaces pods in the
openshift-devspacesnamespace are running and ready:$ oc get pods -n openshift-devspaces
All pods should show
Runningstatus with all containers ready.Verify that the OpenShift Dev Spaces dashboard is accessible:
$ oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'Open the returned URL in a browser and confirm the login page loads.
Verify that the Dev Workspace Operator is running the expected version:
$ oc get csv -n openshift-operators -o custom-columns='NAME:.metadata.name,PHASE:.status.phase' | grep devworkspace
The Dev Workspace Operator CSV should show
Succeededphase.- Start a test workspace from the OpenShift Dev Spaces dashboard to confirm that workspaces function correctly after the upgrade.
Chapter 5. Fix a duplicate Dev Workspace Operator after a cluster upgrade
Fix a duplicate Dev Workspace Operator installation that can occur when an OLM restart or OpenShift cluster upgrade leaves multiple Operator entries in a Replacing or Pending loop.
Prerequisites
-
You have an active
ocsession as a cluster administrator to the destination OpenShift cluster. See This page is not included, but the link has been rewritten to point to the nearest parent document.Getting started with the CLI. - You see multiple entries for the Dev Workspace Operator on the Installed Operators page of the OpenShift web console. Alternatively, you see one entry that is stuck in a loop of Replacing and Pending.
Procedure
-
Delete the
devworkspace-controllernamespace that contains the failing pod. Update
DevWorkspaceandDevWorkspaceTemplateCustom Resource Definitions (CRD) by setting the conversion strategy toNoneand removing the entirewebhooksection:spec: ... conversion: strategy: None status: ...TipYou can find and edit the
DevWorkspaceandDevWorkspaceTemplateCRDs in the Administrator perspective of the OpenShift web console by searching forDevWorkspacein → .NoteThe
DevWorkspaceOperatorConfigandDevWorkspaceRoutingCRDs have the conversion strategy set toNoneby default.Remove the Dev Workspace Operator subscription:
$ oc delete sub devworkspace-operator \ -n <devworkspace_operator_namespace>where:
<devworkspace_operator_namespace>-
The project where the Dev Workspace Operator is installed. For OpenShift Dev Spaces 3.29, this is typically
openshift-devspaces. For standalone Dev Workspace Operator installations, this isopenshift-operators.
Get the Dev Workspace Operator CSVs in the <devworkspace_operator.vX.Y.Z> format:
$ oc get csv | grep devworkspace
Remove each Dev Workspace Operator CSV:
$ oc delete csv <devworkspace_operator.vX.Y.Z> \ -n <devworkspace_operator_namespace>
Re-create the Dev Workspace Operator subscription:
$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: devworkspace-operator namespace: openshift-operators spec: channel: fast name: devworkspace-operator source: redhat-operators sourceNamespace: openshift-marketplace installPlanApproval: Automatic startingCSV: devworkspace-operator.v0.41.0 EOF
installPlanApprovalAutomaticorManual.ImportantFor
installPlanApproval: Manual, in the Administrator perspective of the OpenShift web console, go to → and select the following for the Dev Workspace Operator: → → .
Verification
- In the Administrator perspective of the OpenShift web console, go to → and verify the Succeeded status of the Dev Workspace Operator.
Additional resources
Additional resources
- This content is not included.OpenShift Dev Spaces 3.29 release notes
- This content is not included.Common user roles and tasks
- Troubleshoot OpenShift Dev Spaces
- This content is not included.Install the dsc management tool
- Configure the OpenShift Dev Spaces platform
- This content is not included.Secure OpenShift Dev Spaces
Revised on 2026-07-27 19:48:17 UTC