3.18.0 Release notes and known issues

OpenShift Dev Spaces runs on OpenShift 4.14–4.17 on the following CPU architectures:

For Red Hat OpenShift Dev Spaces 3.18, Red Hat will provide support for deployment, configuration, and use of the product.

There are some differences between Red Hat OpenShift Dev Spaces and the upstream project on which it is based, Eclipse Che:

Red Hat provides licensing and packaging to ensure enterprise-level support for OpenShift Dev Spaces.

Communications with external services are encrypted with TLS and require the certificates to be signed by trusted Certificate Authorities (CA). Therefore, all untrusted CA chains used by external services should be imported to Dev Spaces.

Starting from this release, labeled ConfigMaps from the installation namespace are used as sources for TLS certificates. The ConfigMaps can have an arbitrary amount of keys with an arbitrary amount of certificates each. The operator merges all ConfigMaps into a single one titled ca-certs-merged, and mounts it as a volume in the operands and Cloud Development Environment (CDE) pods.

By default, the operator mounts the ca-certs-merged ConfigMap in a user’s CDE at two locations: /public-certs and /etc/pki/ca-trust/extracted/pem. The /etc/pki/ca-trust/extracted/pem directory is where the system stores extracted CA certificates for trusted certificate authorities on Red Hat (e.g. CentOS, Fedora). CLI tools automatically use certificates from the system-trusted locations when the user’s CDE is up and running.

Learn more about the procedure in the official documentation.

Starting from this release, you can configure two Gitlab OAuth providers on a single Dev Spaces instance. This can be particularly useful when developers are working with codebases hosted on both GitLab SaaS and on-premises.

Learn more about the procedure in the official documentation.

With this release, you can create or import the .gitconfig file from the User Dashboard regardless of the authentication method setup on the cluster.

Before this release, it was not possible to create or import the .gitconfig file if you were logged in via LDAP or local authentication. Instead, you had to manually create a dedicated config map for the .gitconfig file in their namespace.

This official documentation defines minimal permissions for installing Dev Spaces on an OpenShift cluster using CLI or web console UI starting from this release.

When setting the discoverable: true attribute on a devfile container component endpoint, a dedicated service will be created and used for the endpoint. For all other endpoints that do not set the discoverable: true attribute, the common workspace service will be used.

The dedicated service created for the endpoint will have a static name, corresponding to the endpoint’s name. For example, a service named http-python will be generated in the example endpoint defined below:

# Example endpoint with discoverable attribute
- exposure: public
  targetPort: 8080
  name: http-python
  protocol: http
  secure: true
  attributes:
    discoverable: true

# Example endpoint with discoverable attribute
- exposure: public
  targetPort: 8080
  name: http-python
  protocol: http
  secure: true
  attributes:
    discoverable: true

With this release, you can leverage the OpenShift Template object and replicate the resources defined in it across the namespaces of all users, such as:

*LimitRange *ResourceQuota *NetworkPolicy *Role *RoleBinding

Learn more about the procedure in the official documentation.

Starting from this release, if cluster autoscaler is provisioning a new worker node during Cloud Developer Environment (CDE) startup, you will be notified with a dedicated warning message.

With this release, you can install default Visual Studio Code - Open Source ("Code - OSS") extensions using the combinations of the devfile postStart event together with automount ConfigMap:

  - id: add-default-extensions
    exec:
      # put your tooling container name here
      component: runtime
      commandLine: |
        # download regular binary
        curl open-vsx.org/api/atlassian/atlascode/3.0.10/file/atlassian.atlascode-3.0.10.vsix --location -o /tmp/atlassian.atlascode-3.0.10.vsix
        curl open-vsx.org/api/snowflake/snowflake-vsc/1.9.1/file/snowflake.snowflake-vsc-1.9.1.vsix --location -o /tmp/snowflake.snowflake-vsc-1.9.1.vsix

events:
  postStart:
    - add-default-extensions

  - id: add-default-extensions
    exec:
      # put your tooling container name here
      component: runtime
      commandLine: |
        # download regular binary
        curl open-vsx.org/api/atlassian/atlascode/3.0.10/file/atlassian.atlascode-3.0.10.vsix --location -o /tmp/atlassian.atlascode-3.0.10.vsix
        curl open-vsx.org/api/snowflake/snowflake-vsc/1.9.1/file/snowflake.snowflake-vsc-1.9.1.vsix --location -o /tmp/snowflake.snowflake-vsc-1.9.1.vsix

events:
  postStart:
    - add-default-extensions

With this release, the security best practices for Dev Spaces are available in the official documentation.

When the activity tracker extension could not ping the idler service, there was no user-facing error message displayed. This could cause a situation where your Cloud Development Environment (CDE) is terminated due to the idler, even when you are actively using your CDE. With this release, an error notification warns you when the idler service cannot be reached.

With this release, the Enabling fuse-overlayfs for all workspaces document is updated to include support for Podman 5.x.

With this release, registry.redhat.io/devspaces/udi-rhel9 is used as the default development image. To override it, use the spec.devEnvironments.defaultComponents Custom Resource property:

spec:
  devEnvironments:
    defaultComponents:
       - name: universal-developer-image
         container:
           image: <>

spec:
  devEnvironments:
    defaultComponents:
       - name: universal-developer-image
         container:
           image: <>

Previously, the 'Temporary Storage' switch was not working correctly on the User Dashboard. The defect has been fixed in this release.

Previously if the admin configured allowed URLs for Cloud Development Environments (CDEs), workspace creation was stopped after a user clicked on the 'Continue' button in the 'Trust the repository authors' pop-up. The defect has been fixed in this release.

Previously, if you refused the OAuth authorization the Cloud Development Environment (CDE) would not start. The defect has been fixed in this release.

Before this release, the error message could appear during a Cloud Development Environment (CDE) startup: 'No IDE URL after 20 sec during workspace startup'. The defect has been fixed in this release.

The "Workspace Details" drop-down menu item has been returned back to the navigation bar.

Before this release, it was not possible to create Cloud Development Environments (CDEs) from a .devfile.yaml within an internally hosted Gitlab repository. With this release, the issue is fixed.

There is a known issue affecting workspaces that use a ubi-9-based image without libbrotli library as a tools container. If you start the workspace, the following error message appears: "Failed to open the workspace: The workspace status remains "Starting" in the last 300 seconds."

There is a known issue affecting the automatic setup of Git user.name and user.email in the `gitconfig file after you configured your access token (PAT) or OAuth. If you open User Dashboard > Gitconfig page after PAT or OAuth configuration, you receive the following error message: "Author identity unknown." A workaround exists.

There is a known issue affecting Visual Studio Code - Open Source ("CODE - OSS") after you upgrade Dev Spaces from version 3.17.0 to 3.18.0. If you open a workspace previously created from a sample in Dev Spaces 3.17.0, an old version (1.93.0) of Visual Studio Code appears in it instead of the new version (1.96.0).

There is currently no workaround available.

There is a known issue when experimental refresh token mode is applied using the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property for the GitHub and Microsoft Azure DevOps OAuth providers. This causes the workspace starts to reload the dashboard cyclically, creating a new personal access token on each page restart. The refresh token mode works correctly for 'GitLab' and 'BitBucket' OAuth providers.

There’s a known issue with FIPS compliance that results in certain cryptographic modules not being FIPS-validated. Below is a list of requirements and limitations for using FIPS with OpenShift Dev Spaces:

Once the cluster is up and running, install OpenShift Dev Spaces 3.18 (3.18-36) and verify that the latest DevWorkspace operator bundle 0.32 (0.32-2) or newer is also installed and updated. See https://catalog.redhat.com/software/containers/devworkspace/devworkspace-operator-bundle/60ec9f48744684587e2186a3

The resulting binaries can be scanned and should pass without error.

As they are not related to cryptography, they do not affect FIPS compliance.

Currently, the debugger in Microsoft Visual Studio Code - Open Source does not work in the .NET sample.