The OpenShift Dev Spaces server components manage multi-tenancy and workspace lifecycle. Understanding these components helps you troubleshoot issues and plan cluster capacity.

Figure 1.2. OpenShift Dev Spaces server components interacting with the Dev Workspace operator

The OpenShift Dev Spaces Operator manages the full lifecycle of OpenShift Dev Spaces server components through the CheCluster custom resource. Creating a CheCluster CR triggers the Operator to deploy the Dev Workspace Operator, gateway, dashboard, server, and plug-in registry.

The Dev Workspace Operator (DWO) extends OpenShift to manage workspace pods, services, and persistent volumes by reconciling Dev Workspace custom resources. Every OpenShift Dev Spaces workspace has an underlying Dev Workspace CR that contains the devfile, editor definition, and configuration attributes.

The Dev Workspace CR is an OpenShift resource representation of an OpenShift Dev Spaces workspace. Whenever a user creates a workspace using OpenShift Dev Spaces in the background, Dashboard OpenShift Dev Spaces creates a Dev Workspace CR in the cluster. For every OpenShift Dev Spaces workspace, there is an underlying Dev Workspace CR on the cluster.

Figure 1.3. Example of a Dev Workspace CR in a cluster

When creating a workspace with OpenShift Dev Spaces with a devfile, the Dev Workspace CR contains the devfile details. Additionally, OpenShift Dev Spaces adds the editor definition into the Dev Workspace CR depending on which editor was chosen for the workspace. OpenShift Dev Spaces also adds attributes to the Dev Workspace that further configure the workspace depending on how you configured the CheCluster CR.

A DevWorkspaceTemplate is a custom resource that defines a reusable spec.template for Dev Workspaces.

When a workspace is started, DWO reads the corresponding Dev Workspace CR and creates the necessary resources such as deployments, secrets, configmaps, and routes. As a result, a workspace pod representing the development environment defined in the devfile is created.

1.1.3.4. DevWorkspaceOperatorConfig

The DevWorkspaceOperatorConfig (DWOC) custom resource defines configuration options for the DWO. There are two different types of DWOC:

• global configuration
• non-global configuration

The global configuration is a DWOC custom resource named devworkspace-operator-config and is usually located in the DWO installation namespace. By default, the global configuration is not created upon installation. Configuration fields set in the global configuration apply to the DWO and all Dev Workspaces. However, the DWOC configuration can be overridden by a non-global configuration.

Any other DWOC custom resource than devworkspace-operator-config is considered to be non-global configuration. A non-global configuration does not apply to any Dev Workspaces unless the Dev Workspace contains a reference to the DWOC. If the global configuration and non-global configuration have the same fields, the non-global configuration field takes precedence.

Table 1.1. Global DWOC and OpenShift Dev Spaces-owned DWOC comparison

	Global DWOC	OpenShift Dev Spaces-owned DWOC
Resource name	devworkspace-operator-config	devworkspace-config
Namespace	DWO installation namespace	OpenShift Dev Spaces installation namespace
Default creation	Not created by default upon DWO installation	Created by default on OpenShift Dev Spaces installation
Scope	Applies to the DWO itself and all Dev Workspaces managed by DWO	Applies to Dev Workspaces created by OpenShift Dev Spaces
Precedence	Overridden by fields set in OpenShift Dev Spaces-owned config	Takes precedence over global config if both define the same field
Primary use case	Used to define default, broad settings that apply to DWO in general.	Used to define specific configuration for Dev Workspaces created by OpenShift Dev Spaces

For example, by default OpenShift Dev Spaces creates and manages a non-global DWOC in the OpenShift Dev Spaces namespace named devworkspace-config. This DWOC contains configuration specific to OpenShift Dev Spaces workspaces, and is maintained by OpenShift Dev Spaces depending on how you configure the CheCluster CR. When OpenShift Dev Spaces creates a workspace, OpenShift Dev Spaces adds a reference to the OpenShift Dev Spaces-owned DWOC with the controller.devfile.io/devworkspace-config attribute.

Figure 1.4. Example of Dev Workspace configuration attribute

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceRouting
metadata:
  annotations:
    controller.devfile.io/devworkspace-started: 'false'
  name: routing-workspaceb14aa33254674065
  labels:
    controller.devfile.io/devworkspace_id: workspaceb14aa33254674065
spec:
  devworkspaceId: workspaceb14aa33254674065
  endpoints:
    universal-developer-image:
      - attributes:
          cookiesAuthEnabled: true
          discoverable: false
          type: main
          urlRewriteSupported: true
        exposure: public
        name: che-code
        protocol: https
        secure: true
        targetPort: 3100
  podSelector:
    controller.devfile.io/devworkspace_id: workspaceb14aa33254674065
  routingClass: che
status:
  exposedEndpoints:
    ...

$ oc get pods -l 'app.kubernetes.io/part-of=devworkspace-operator' -o custom-columns=NAME:.metadata.name -n openshift-operators
NAME
devworkspace-controller-manager-66c6f674f5-l7rhj
devworkspace-webhook-server-d4958d9cd-gh7vr
devworkspace-webhook-server-d4958d9cd-rfvj6

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: devworkspace-operator
  namespace: openshift-operators
spec:
  config:
    affinity:
      nodeAffinity: ...
      podAffinity: ...
    resources:
      limits:
        memory: ...
        cpu: ...
      requests:
        memory: ...
        cpu: ...

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: <DWO install namespace>
config:
  webhooks:
    nodeSelector: <map[string]string>
    replicas: <int>
    tolerations: <[]corev1.Toleration>

The OpenShift Dev Spaces gateway routes requests, authenticates users with OpenID Connect (OIDC), and enforces OpenShift RBAC policies. It controls access to the dashboard, server, plug-in registry, and every user workspace.

The OpenShift Dev Spaces gateway has the following roles:

The OpenShift Dev Spaces operator manages it as the che-gateway Deployment.

It controls access to the user dashboard, the OpenShift Dev Spaces server, the plug-in registry, and user workspaces.

Figure 1.5. OpenShift Dev Spaces gateway interactions with other components

The user dashboard is the landing page of Red Hat OpenShift Dev Spaces where users create, manage, and access their workspaces. It coordinates with the OpenShift Dev Spaces server, plug-in registry, and OpenShift API to convert devfiles into running workspace pods.

It needs access to the OpenShift Dev Spaces server, the plug-in registry, and the OpenShift Application Programming Interface (API).

Figure 1.6. User dashboard interactions with other components

When the user requests the user dashboard to start a workspace, the user dashboard executes this sequence of actions:

The OpenShift Dev Spaces server is a Java web service that creates user namespaces, provisions them with secrets and config maps, and integrates with Git service providers for devfile fetching and authentication.

The OpenShift Dev Spaces server main functions are:

The OpenShift Dev Spaces server is a Java web service exposing a Hypertext Transfer Protocol (HTTP) REST API and needs access to:

Figure 1.7. OpenShift Dev Spaces server interactions with other components

The OpenShift Dev Spaces plug-in registry provides the list of available editors and editor extensions, each described by a Devfile v2. The dashboard reads this registry when assembling the Dev Workspace custom resource for a new workspace.

The user dashboard reads the content of the registry.

Figure 1.8. Plugin registries interactions with other components