3.16.0 Release notes and known issues

OpenShift Dev Spaces runs on OpenShift 4.12–4.16 on the following CPU architectures:

The following CPU architecture requires Openshift 4.13-4.16 to run OpenShift Dev Spaces:

For Red Hat OpenShift Dev Spaces 3.16, 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.

With this release, the devworkspace-webhook-server deployment options are available in the global DevWorkspaceOperatorConfig (DWOC) including: replicas, pod tolerations and nodeSelector.

These configuration options exist in the global DWOC’s config.webhook field:

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: $OPERATOR_INSTALL_NAMESPACE
config:
 routing:
   clusterHostSuffix: 192.168.49.2.nip.io
   defaultRoutingClass: basic
 webhook:
   nodeSelector: <string, string>
   tolerations: <[]tolerations>
   replicas: <int32>

With this release, when you start a cloud development environment (CDE) from a URL, you are asked if you trust the authors of the repository since creating a workspace from unknown or untrusted sources could be dangerous.

Starting from this release, it is possible to configure the container image, temporary storage, memory and CPU limits when starting a CDE using the "Import from Git" flow.

With this release, you can not only set the name and email for the Git Configuration but also to upload and edit the entire .gitconfig file from the User Dashboard.

Starting from this release, you can set ignoredUnrecoverableEvents explicitly on the CheCluster CustomResource level:

apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  devEnvironments:
    ignoredUnrecoverableEvents:
    - FailedScheduling
    - FailedMount

More details about configuring ignoredUnrecoverableEvents can be found in the official documentation.

The DisableInitContainer field has been added to the CheCluster CR. This field sets the config.workspaces.persistUserHome.disableInitContainer field in the operator-owned DWOC. This field whether the init container that initializes the persistent home directory should be disabled.

When the /home/user directory is persisted, the init container is used to initialize the directory before the workspace starts. If set to true, the init container will not be created, delegating the home persistence setup to the CDE’s first container component’s entrypoint. This field is not used if the devEnvironments.persistUserHome.enabled field is set to false.

The init container is enabled by default.

With this release, you can provide ports in the URL for Git Provider Endpoint when adding Personal Access Tokens on the User Dashboard. Previously, it was not possible due to strict validation.

Before this release, when the spec.devEnvironments.persistUserHome option was enabled, the token in .kube/config was not renewed automatically during a workspace restart.

You can find more details about automatic token injection in the official documentation.

Previously, PROJECTS_ROOT and PROJECT_SOURCE environment variables were not correctly set after using the Restart Workspace from Local Devfile functionality. The defect has been fixed in this release.

Previously, when commands were executed using the command definition in the devfile, they had a different $PATH compared to commands launched in containers defined within the components section. The defect has been fixed in this release.

Previously, users were not able to reference the $PROJECT_ROOT or $PROJECT_SOURCE environment variables in their devfile environment variables. This issue has now been fixed in this release.

Previously, during a workspace startup, the status could have been unexpectedly changed to 'Stopped' even though the workspace started successfully. The defect has been fixed in this release, and the status changes are ignored during workspace startup.

Previously, starting a new workspace with a clone of a specified branch didn’t work correctly if the repository didn’t have devfile.yaml. Instead, the default branch was always cloned after the cloud development environment (CDE) startup. The defect has been fixed in this release.

Before this release, branch detection for Microsoft Azure repositories was not working on the User Dashboard. The defect has been fixed in this release.

Before this release, creating a workspace from GitHub Enterprise public repositories that have no personal access token (PAT) or OAuth configured resulted in the following error: "Failed to create the workspace. Cannot build factory with any of the provided parameters. Please check parameters correctness, and resend query." The defect has been fixed in this release.

Previously, using the experimental CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature could result in the cyclic reload sequence during cloud development environment (CDE) startup. The defect has been fixed in this release.

Learn more about the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN feature in the official documentation.

Before this release, there was an issue with adding an SSH key by manually pasting the key strings in the dashboard. After saving the SSH key and starting the workspace, the project would not be cloned with the following error message: "Could not read from remote repository. Please make sure you have the correct access rights and the repository exists." With this release, the issue has been fixed.

In this release, the Dev Spaces-specific devfile-registry operand has been removed. For configuring the custom Getting-Started samples, the admin should leverage the dedicated Kubernetes ConfigMap.

Find more details in the official documentation.

There is a known issue affecting workspaces using Microsoft Azure DevOps/Bitbucket/GitHub git providers in connection with the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property. Every time you start a workspace, a new personal access token (PAT) is added to the previous PATs which are not removed. When the number of existing PATs exceeds five, you can not run the workspace, and the Dashboard is not available.

There is a known issue with using the CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN property. After using the property, the previous Microsoft Azure DevOps/Bitbucket/GitHub personal tokens are not removed. This can also cause issues with accessing the Dashboard.

There is currently a known issue with applying Refused OAuth authorization. When you launch a factory with OAuth setup and if and apply the Refused OAuth authorization, the "Untrusted Repository" pop-up appears again.

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.