Rechercher

Ce contenu n'est pas disponible dans la langue sélectionnée.

Release notes and known issues

download PDF
Red Hat OpenShift Dev Spaces 3.0

Release notes and known issues for Red Hat OpenShift Dev Spaces 3.0

Robert Kratky

Fabrice Flore-Thébault

Red Hat Developer Group Documentation Team

Abstract

Information about new and noteworthy features as well as known issues in Red Hat OpenShift Dev Spaces 3.0.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Chapter 1. About Red Hat OpenShift Dev Spaces

Red Hat OpenShift Dev Spaces is a web-based integrated development environment (IDE). OpenShift Dev Spaces runs in OpenShift and is well-suited for container-based development.

OpenShift Dev Spaces provides:

  • an enterprise-level cloud developer workspace server
  • a browser-based IDE
  • ready-to-use developer stacks for popular programming languages, frameworks, and Red Hat technologies

Red Hat OpenShift Dev Spaces 3.0 is based on Eclipse Che 7.46.

1.1. Supported deployment environments

OpenShift Dev Spaces 3.0 is available on listed platforms with the listed supported installation methods:

Table 1.1. Supported deployment environments for OpenShift Dev Spaces 3.0
PlatformArchitecturesDeployment method

OpenShift Container Platform 4.10

  • AMD64 and Intel 64 (x86_64)
  • IBM Power (ppc64le)
  • IBM Z (s390x)

OpenShift Dedicated 4.10

  • AMD64 and Intel 64 (x86_64)

Red Hat OpenShift Service on AWS (ROSA) 4.10

  • AMD64 and Intel 64 (x86_64)

1.2. Support policy

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

OpenShift Dev Spaces 3.0 has been tested on Chrome version 101.0.4951.54 (Official Build) (64-bit).

1.3. Differences between Eclipse Che and Red Hat OpenShift Dev Spaces

The main differences between OpenShift Dev Spaces and Eclipse Che are:

  • OpenShift Dev Spaces is built on RHEL8 to ensure the latest security fixes are included, compared to Alpine distributions that take a longer time to update.
  • OpenShift Dev Spaces uses OpenShift OAuth for user login and management.
  • OpenShift Dev Spaces provides a smaller supported subset of plug-ins compared to Che.
  • OpenShift Dev Spaces provides devfiles for working with other Red Hat technologies such as EAP and Fuse.
  • OpenShift Dev Spaces is supported on OpenShift Container Platform, OpenShift Dedicated, and Red Hat OpenShift Service on AWS (ROSA); Eclipse Che can also run on other Kubernetes clusters.

Red Hat provides licensing, packaging, and support. Therefore, OpenShift Dev Spaces is considered a more stable product than the upstream Eclipse Che project.

Chapter 2. Notable enhancements

2.1. Universal Developer Image consolidates all stack and plug-in sidecars into a single image

With this update, the following stacks and plug-ins are consolidated into a single Universal Developer Image (UDI) sidecar:

The UDI is now the only sidecar used in OpenShift Dev Spaces.

The UDI is available in OpenShift Dev Spaces, like the plug-ins and stack sidecars that the UDI has replaced: OpenShift Dev Spaces admins can use the image puller to pull the UDI. Users can specify the UDI in the devfile.

Additional resources

2.2. Node.js version updated to 16

With this update, Node.js 16 is included in the Universal Developer Image sidecar that replaces the older stacks and plug-in sidecars.

Support for Node.js is aligned to the Node.js lifecycle.

Additional resources

2.3. Code samples implement the devfile v2 specification

Before this update, code samples implemented the devfile v1 specification. With this update, code samples are implementing the devfile v2 specification.

Additional resources

2.4. Fuse Booster sample project updated to use the Red Hat build of OpenJDK 11 in the devfile

With this update, the Fuse Booster sample project uses the Red Hat build of OpenJDK 11 rather than 8.

Additional resources

2.5. Support for Fuse devfiles on IBM Z and IBM Power

With this update, Red Hat Fuse can be used in Red Hat OpenShift Dev Spaces on IBM Z and IBM Power.

The sample project and its associated devfile for Red Hat Fuse have been updated to work with Java 11 and can now be used on all supported architectures.

Additional resources

2.6. Removal of the backup and recovery functionality

In OpenShift Dev Spaces 3.0, backing up and restoring a OpenShift Dev Spaces instance by using a backup server, such as SFTP or Amazon S3 or REST or the internal backup server, has been removed. The CheBackupServerConfiguration, CheClusterBackup, and CheClusterRestore custom resources are no longer used. Bug fixes and support are provided only through the end of the CodeReady Workspaces 2.15 lifecycle.

Additional resources

2.7. Red Hat OpenShift Dev Spaces Operator enables the DevWorkspace engine by default

With this update, the Red Hat OpenShift Dev Spaces Operator enables the DevWorkspace engine by default from the new stable channel.

Additional resources

2.8. JetBrains IntelliJ IDEA editor now opens projects specified in the devfile

With this update, when you start a workspace using a devfile that specifies the JetBrains IntelliJ IDEA editor, the editor automatically opens the project(s) specified in the devfile.

Additional resources

2.9. Enabling admins to specify pod tolerations and node selector

With this update, OpenShift Dev Spaces admins can specify podTolerations and podNodeSelector for workspaces by setting a CustomCheProperty in the CheCluster custom resource. This is a global configuration and cannot be specified for a workspace or user.

Additional resources

2.10. Improved startup performance of the Che-Theia IDE

With this update, the Che-Theia IDE loads in the workspace 20 seconds faster than previously.

Additional resources

2.11. OAuth 2.0 support for organizations' GitLab instances

With this update, OpenShift Dev Spaces supports private repositories on an organization’s own GitLab instance. OpenShift Dev Spaces admins can set up a GitLab-authorized application and configure OAuth 2.0 for a GitLab instance. No support is provided for private repositories on GitLab SaaS. This expands the OAuth 2.0 support that OpenShift Dev Spaces already provides for Bitbucket servers and GitHub.

Additional resources

2.12. OpenJDK replaces JVM on IBM Power and IBM Z

Before this update, Eclipse OpenJ9 was the Java SE implementation for containers targeting IBM Power (ppc64le) and IBM Z (s390x) OpenShift clusters. With this update, the OpenJ9 JVM in the OpenShift containers for IBM Power (ppc64le) and IBM Z (s390x) is replaced by the Red Hat build of OpenJDK.

Installed CodeReady Workspaces instances, on update to Red Hat OpenShift Dev Spaces 3.0, switch over to use the new Universal Developer Image sidecar container that provides OpenJDK rather than OpenJ9 for Java 8 and 11.

Customers whose devfiles still reference the OpenJ9-based containers must edit their devfiles and replace plugin-java8-openj9-rhel8 and plugin-java11-openj9-rhel8 with udi-rhel8.

New samples in Red Hat OpenShift Dev Spaces 3.0 already use the new udi-rhel8 sidecar.

Additional resources

2.13. Parent devfile support

With this update, OpenShift Dev Spaces supports a devfile v2 that refers to a parent devfile.

Additional resources

2.14. Version update of the Language Support for Apache Camel extension for Visual Studio Code

Language Support for Apache Camel by Red Hat, the Visual Studio Code extension that adds Apache Camel language support for XML DSL and Java DSL code, is updated to version 0.1.5.

Additional resources

2.15. Removal of support for some deployment environments

In Red Hat OpenShift Dev Spaces 3.0 (formerly CodeReady Workspaces), support for the following deployment environments is removed due to the switch to the DevWorkspace Operator:

  • OpenShift Container Platform 3.11
  • OpenShift Container Platform 4.8
  • OpenShift Container Platform 4.9
  • Red Hat OpenShift Dedicated 4.8
  • Red Hat OpenShift Dedicated 4.9
  • Red Hat OpenShift Service on AWS 4.8
  • Red Hat OpenShift Service on AWS 4.9

Bug fixes and support are planned through the end of the 2.15 life cycle. During which, no new feature enhancements are made.

With Red Hat OpenShift Dev Spaces 3.0 (formerly CodeReady Workspaces), the supported deployment environments are the following:

  • OpenShift Container Platform 4.10
  • Red Hat OpenShift Dedicated 4.10
  • Red Hat OpenShift Service on AWS 4.10

Additional resources

2.16. Logs from the Che Gateway deployment

With this update, the dsc server:logs command (formerly crwctl server:logs) can now retrieve logs from the Che Gateway deployment. This command can also retrieve logs from the Che Server, Operator, Dashboard, plug-in and devfile registries, and PostgreSQL deployments.

Additional resources

2.17. Devfile no longer supports Visual Studio Code extensions

In OpenShift Dev Spaces 3.0, using the workspace devfile to specify Visual Studio Code extensions has been removed to meet the devfile v2 specification. Bug fixes and support are provided only through the end of the CodeReady Workspaces 2.15 lifecycle. To specify Visual Studio Code extensions, users must now use .vscode/extensions.json or .che/che-theia-plugins.yaml in their Git repositories. See https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.0/html/user_guide/adding-visual-studio-code-extension for more information.

Additional resources

2.18. OpenShift Dev Spaces 3.0.1 is available as Technology Preview on Red Hat OpenShift 4.11

With this update, as Technology Preview, OpenShift Dev Spaces 3.0.1 can be installed and tested on OpenShift Container Platform 4.11, OpenShift Dedicated 4.11, and Red Hat OpenShift Service on AWS (ROSA) 4.11, in addition to the supported OpenShift Container Platform 4.10, OpenShift Dedicated 4.10, and Red Hat OpenShift Service on AWS (ROSA) 4.10.

Important

Support for OpenShift Dev Spaces 3.0.1 on Red Hat OpenShift 4.11 is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview.

Additional resources

Chapter 3. Bug fixes

Chapter 4. Known issues

4.1. Debugging cannot be activated in Go workspaces on IBM Z and IBM Power

On IBM Z and IBM Power, the debugging features cannot be activated in the Go workspace in OpenShift Dev Spaces 3.0. Delve, the required debugger for the Go programming language, is not available for these platforms. An attempt to activate this feature results in the Failed to continue error message. This issue has no workaround.

Additional resources

4.2. Language server features are not preinstalled in Go workspaces

Currently, Golang-based workspaces do not include basic language server features such as code autocompletion.

Workaround

  1. Run the OpenShift Dev Spaces instance in a non-restricted environment.
  2. Install the required module by clicking Install in the IDE dialog box.

Additional resources

4.3. Workspace creation fails on unstable networks

OpenShift Dev Spaces might fail to create a workspace when the network is unstable. OpenShift Dev Spaces displays an error such as Failed to run the workspace: "Waiting for pod 'workspace9fbid1gnx7273d47.maven-545f8c9cf4-hw79f' was interrupted." This issue has no workaround.

Additional resources

4.4. Unsupported devfiles on IBM Z and IBM Power

Currently, the following devfiles are not supported on IBM Z and IBM Power:

  • IntelliJ IDEA
  • .Net
  • Apache Camel K by Red Hat

This issue has no workaround.

Additional resources

4.5. No delegateCommandHandler error for Java with the JBoss EAP 7.3 devfile

A workspace using Java with the JBoss EAP 7.3 devfile fails with the following error message: No delegateCommandHandler for vscode.java.startDebugSession. There is no workaround for this issue.

Additional resources

4.6. No display for a task after a networking issue

When a task is running and there is some networking issue, the terminal window is cleared and contains no text. Even when the connection is restored, the terminal remains empty and loading. There is no workaround for this issue.

Additional resources

4.7. OpenShift Connector plug-in fails to deploy an application in a restricted environment

The OpenShift Connector plug-in fails to deploy because of the inability to access the odo image in the disconnected environment. There is no workaround for this issue.

Additional resources

4.8. The DEBUG configuration is missing

The DEBUG panel displays No Configurations in the drop-down list because no configurations are loaded.

Workaround

  • Refresh the page to display the debug configurations.

Additional resources

4.9. OpenShift Connector plug-in does not allow the creation of a new component on IBM Power

On IBM Power, the list of supported image streams is missing, which causes component creation to fail. There is currently no workaround for this issue.

Additional resources

4.10. Upgrading a CodeReady Workspaces 2.15 instance with the DevWorkspace engine enabled (Technology Preview)

Upgrading a CodeReady Workspaces 2.15 instance with the DevWorkspace engine enabled (Technology Preview) is simpler than the upgrade procedure described in the Administration Guide.

Workaround

  1. Skip steps 1 and 2 in the upgrade procedure.
  2. In step 5 of the upgrade procedure, use the following two values when setting the environment variables for the migration scripts:

    • export PRE_MIGRATION_PRODUCT_SUBSCRIPTION_NAME=codeready-workspaces2 rather than the documented codeready-workspaces value
    • export PRE_MIGRATION_PRODUCT_OPERATOR_NAMESPACE=openshift-operators rather than the documented openshift-workspaces value
  3. In step 6 of the upgrade procedure, run only the ./3-subscribe.sh and ./4-wait.sh scripts. Do not run ./1-prepare.sh and ./2-migrate.sh.
Important

Support for deploying OpenShift Dev Spaces 3.0 with the DevWorkspace engine is available starting with OpenShift Container Platform 4.10. Administrators must upgrade clusters running earlier versions of OpenShift Container Platform to 4.10 or later before subscribing to and deploying OpenShift Dev Spaces.

Additional resources

4.11. Error in the Cake-php sample project on IBM Power

When using the Cake-php sample, the Configure Apache Web Server DocumentRoots task fails with the following error: error sed: couldn’t open temporary file /etc/httpd/conf/sedSgv1Z4: Permission denied. There is currently no workaround for this issue.

Additional resources

4.12. Support for per-workspace storage strategy currently not available

Currently, the per-workspace workspace storage strategy is not supported due to the change to the DevWorkspace engine. With migration from CodeReady Workspaces 2.15 to OpenShift Dev Spaces 3.0, existing workspaces change to the common strategy. Setting the PVC storage size other than 10 GB is currently not possible. This issue has no workaround.

Additional resources

4.13. 403 Permission Denied error

Currently, users might encounter a 403 Permission Denied error when logging in to OpenShift Dev Spaces.

Workaround: Log in to OpenShift Dev Spaces in a web browser using incognito mode.

See also #21352.

Additional resources

4.14. Workspace panel in Che-Theia workspaces might appear blank

In workspaces that use the default Che-Theia IDE in a proxied environment, the Workspace panel might appear blank rather than showing available commands, terminals, and applications.

Workaround

  1. Run $ oc edit proxy cluster.
  2. Add 172.30.0.1 to the spec.noProxy property.
  3. Run the oc command in the project where devworkspace-controller-manager is deployed, openshift-operators or openshift-devspaces:

    `$ oc rollout restart -n __<project>__ deploy/devworkspace-controller-manager`

Additional resources

4.15. 503 Service Unavailable or 504 Gateway Time-out errors

Currently, you might encounter a 503 Service Unavailable or 504 Gateway Time-out error message after refreshing the page of a stopped workspace.

Workaround: Restart the workspace from the dashboard.

Additional resources

4.16. Users cannot edit profile information in the dashboard

In CodeReady Workspaces 2.15, users were able to edit their profile information in the Account page of the dashboard. Because OpenShift OAuth is now used exclusively for user management in OpenShift Dev Spaces 3.0, users can only edit their user profile within OpenShift. The Account page in the dashboard remains for display purposes only.

Additional resources

4.17. 502 Bad Gateway or application not available errors

When launching a sample application from the workspace, users can encounter an error message such as 502 Bad Gateway or application not available. The cause of this error is the Theia IDE displaying the notification that the application is ready before the application startup is complete.

Workaround: Wait a minute or two, and reload the browser tab.

See the related issue #21377.

Additional resources

4.18. Golang sample workspaces cannot be deleted on IBM Power

Currently on IBM Power, a workspace based on the Golang sample project might create files with file permissions that prevent workspace deletion.

Workaround

  • Ask an administrator to delete the workspace.

Additional resources

4.19. Creating a new OpenShift Dev Spaces instance using the OpenShift web console

Currently, using the OpenShift web console, OperatorHub, to create a new OpenShift Dev Spaces instance results in the instance deployed by default in the openshift-operators namespace for Operators.

Workaround

  1. In OperatorHub in the OpenShift web console, install the Red Hat OpenShift Dev Spaces Operator.
  2. Create a <custom_namespace> project, for example devspaces. See Creating a project using the web console.
  3. With the new project selected in the drop-down menu, create a new OpenShift Dev Spaces instance.

Additional resources

4.20. CheCluster custom resource retains its pre-upgrade name

Currently, the name of the CheCluster custom resource remains the same as before upgrading from CodeReady Workspaces 2.15 to OpenShift Dev Spaces 3.0. Customers whose Checluster custom resource name is codeready-workspaces before the upgrade will find the same name after the upgrade. This issue has no workaround.

Additional resources

4.21. Blank Welcome To Your Workspace page in Che-Theia workspaces

Currently, the Welcome To Your Workspace page in Che-Theia workspaces might appear blank when the workspace loads. This is caused by a missing self-signed TLS certificate in the browser.

Workaround

  • If you use self-signed TLS certificates to connect over HTTPS to an OpenShift cluster running OpenShift Dev Spaces, import those certificates into your browser.

Additional resources

4.22. Workspace startup might fail if a ConfigMap includes environment variables

Currently, a workspace might fail to start if an applied ConfigMap includes environment variables, env.

Workaround

  1. Delete any ConfigMaps that include environment variables for the workspace.
  2. Edit the workspace’s devfile to add the required environment variables for the workspace.

Additional resources

4.23. Maven mvnw might time out in disconnected environments

Users running mvnw in disconnected or restricted environments might encounter a timeout error.

Workaround

  • Execute commands manually in the tools terminal using mvn rather than mvnw.

Additional resources

4.24. Maven commands failing for JBoss EAP

Currently, Maven commands might fail for JBoss EAP XP MicroProfile and JBoss EAP 7.4 because these devfiles use two separate users and containers.

Workaround

  • In the dashboard, edit the devfile to add the .m2 volume to the EAP container so that Maven commands can use the .m2 folder.

Additional resources

4.25. Java Gradle sample fails in restricted environments

Currently, there is a known issue with the Java Gradle sample in restricted environments. Running the 1-build command to build an application might result in the FAILURE: Build failed with an exception error and failure to load a native library or not resolving a plug-in artifact in plug-in repositories. This issue has no workaround.

Additional resources

4.26. Conversion of CodeReady Workspaces Node.js workspaces with node-debug and node-debug2 plug-ins

Currently, using the Convert button in the OpenShift Dev Spaces dashboard to convert a Deprecated Node.js workspace with the node-debug or node-debug2 plug-in fails. The following error message is displayed:

Workspace conversion failed. Failed to create a new workspace from the devfile, reason: Unable to resolve theia plugins …​.

In OpenShift Dev Spaces 3.0, the node-debug and node-debug2 plug-ins have been updated to js-debug.

Workaround

  1. Edit the devfile in the editor in the dashboard page. If the editor in the dashboard page is disabled, copy the devfile contents to a new devfile.yaml file.
  2. Edit your existing v1 devfile(s) to replace ms-vscode/node-debug/latest and ms-vscode/node-debug2/latest with ms-vscode/js-debug/latest.
  3. Commit to a Git repository.
  4. Start a new workspace from the edited devfile by using one of the following options:

    • The factory URL, using the ?new URL parameter for starting a duplicate workspace:

      https://devspaces-<openshift_deployment_name>.<domain_name>#<git_repository_url>?new
    • Go to DashboardCreate WorkspaceQuick AddImport from GitGit Repo URL* Enter Git URLCreate & Open.

Additional resources

4.27. Converted Red Hat Fuse workspaces fail to start

Currently, workspaces with Red Hat Fuse devfile v1 fail to start after conversion to devfile v2 by clicking the Convert button in the OpenShift Dev Spaces dashboard.

Workaround

  1. Edit the devfile in the editor in the dashboard page. If the editor in the dashboard page is disabled, copy the devfile contents to a new devfile.yaml file.
  2. In the devfile, rename the endpoint for the target port 8080 to name: port8080.
  3. Commit to a Git repository.
  4. Start a new workspace from the edited devfile by using one of the following options:

    • The factory URL, using the ?new URL parameter for starting a duplicate workspace:

      https://devspaces-<openshift_deployment_name>.<domain_name>#<git_repository_url>?new
    • Go to DashboardCreate WorkspaceQuick AddImport from GitGit Repo URL* Enter Git URLCreate & Open.

Additional resources

4.28. Workspaces might fail to start in environments behind a proxy

Currently, workspaces might fail to start in environments using a proxy. This failure happens if you attempted to customize proxy settings by configuring the DevWorkspaceOperatorConfig custom resource and a component was restarted after that. In that case, the workspace fails to start while the Progress tab shows Waiting for workspace to start.

Workaround

  • Apply additional proxy settings to the cluster OpenShift Proxy object rather than the DevWorkspaceOperatorConfig custom resource.

Additional resources

4.29. Blank dashboard page in expired OpenShift OAuth sessions

Currently, when an OpenShift OAuth session expires, the dashboard page appears blank.

Workaround

  • Use either option:

    • Clear the cookies related to the OpenShift Dev Spaces dashboard page from your browser.
    • Load the OpenShift Dev Spaces dashboard page in incognito mode.

Additional resources

4.30. New workspaces cannot be started by using a GitHub pull request URL

Currently, OpenShift Dev Spaces fails to start new workspaces with a clone of a GitHub-hosted repository when using the #https://github.com/<user_or_org>/<repository>/pull/<pull_request_id> URL syntax. The workspace-starting page displays the following error message: Failed to resolve a devfile. Failed to request factory resolver: Internal Server Error occurred.

Workaround

  • Enter the URL of the fork and branch of the pull request: #https://github.com/<user_or_org>/<repository>/tree/<branch_name>.

Additional resources

4.31. Workspace starting and deletion might fail

Currently, a workspace might fail to start, and then you might be unable to delete it. This is caused by a persistent volume claim (PVC) issue. Subsequently, the same problem occurs with other workspaces.

Workaround

  1. Remove the DevWorkspace object of the first stuck workspace.
  2. Remove the PVC that is bound to the invalid volume.

Additional resources

4.32. Visual Studio Code on OpenShift with a self-signed TLS certificate

Currently, starting a workspace that uses the Technology Preview Visual Studio Code on OpenShift with a self-signed TLS certificate results in a blank browser tab.

Workaround

  • Import the TLS certificate into the browser.

Additional resources

4.33. Vert.x Health Check Example failing in restricted environments

Currently, deploying the Vert.x Health Check Example application by running the 6-deploy-to-openshift command fails in disconnected environments. There is currently no workaround for this issue.

Additional resources

4.34. Dev Spaces Operator installing an additional DevWorkspace Operator

Currently, under certain conditions, such as OLM restart or cluster upgrade, the Dev Spaces Operator for OpenShift Dev Spaces 3.0.0 might automatically install the DevWorkspace Operator even if it is already present on the cluster. This might cause severe consequences: the OpenShift web terminal might stop working, or the DevWorkspace Operator admission webhooks might not work properly, which might affect the behavior of the cluster.

You can detect this issue on your cluster by checking Installed Operators in the OpenShift web console: if this problem is occurring, you see multiple entries for the DevWorkspace Operator or one entry that is stuck in a loop of Replacing and Pending.

Workaround

  • On OpenShift 4.10.23 or earlier, enable the subscription for automated updates and get OpenShift Dev Spaces 3.0.1 through the OLM.
  • On OpenShift 4.10.24 or later, follow the linked instructions for fixing the cluster.

Additional resources

Chapter 5. Frequently asked questions

Is it possible to deploy applications to an OpenShift cluster from OpenShift Dev Spaces?
Yes. The user must log in to the OpenShift cluster from their running workspace using oc login.
For best performance, what is the recommended storage to use for Persistent Volumes used with OpenShift Dev Spaces?
Use block storage.
Is it possible to deploy more than one OpenShift Dev Spaces instance on the same cluster?
It is not recommended. This feature is subject to removal in a future release.
Is it possible to install OpenShift Dev Spaces offline (that is, disconnected from the internet)?
Yes. See Installing OpenShift Dev Spaces in restricted environments.
Is it possible to use non-default certificates with OpenShift Dev Spaces?
Yes, you can use self-signed or public certificates. See Importing untrusted TLS certificates.
Is it possible to run multiple workspaces simultaneously?
Yes. See Configuring the number of workspaces that a user can run.
What specific changes have been implemented for IBM Power Systems?

The memory limit for some plug-ins has been increased, to give Pods sufficient RAM to run.

Table 5.1. Example memory limits differences between IBM Power System and other architectures
Plug-inIBM Power SystemOther architectures

Che-Theia editor

2G

512M

OpenShift connector

2.5G

1.5G

Legal Notice

Copyright © 2022 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.