Chapter 2. New features and enhancements


2.1. Leverage the Openshift cluster-wide Custom CA Bundle configuration for CDEs

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.

Additional resources

2.2. Allow configuring two GitLab OAuth providers simultaneously

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.

Additional resources

2.3. Ability to create the .gitconfig file from the User Dashboard regardless of the authentication method setup on the cluster

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.

Additional resources

2.4. Documentation for a minimal set of permissions for deploying Dev Spaces on OpenShift

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

Additional resources

2.5. Endpoint-specific service for discoverable endpoints

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

Additional resources

2.6. Allow configuring users namespaces with OpenShift template

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.

Additional resources

2.7. Notification when autoscaler kicks in during workspace startup

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.

Additional resources

2.8. Launching Visual Studio Code - Open Source ("Code - OSS") with selected default extensions installed

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

Additional resources

2.9. Security best practices for Dev Spaces

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

Additional resources

2.10. Warning message when tracker can not ping machine-exec

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.

Additional resources

2.11. Enabling fuse-overlayfs for all workspaces

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

Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.