1. The administrator applies the CheCluster Custom Resource YAML file with modifications in the cheServer component section.
2. The Operator generates the che ConfigMap.
3. OpenShift detects changes in the ConfigMap and triggers a restart of the OpenShift Dev Spaces Pod.

Procedure

1. Edit the CheCluster Custom Resource on the cluster:

   $ oc edit checluster/devspaces -n openshift-devspaces

   Copy code to clipboard
2. Save and close the file to apply the changes.

Verification

1. Verify the value of the configured property:

   $ oc get configmap che -o jsonpath='{.data.<configured_property>}' \
   -n openshift-devspaces

   Copy code to clipboard

Procedure

1. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     components:
       devEnvironments:
         defaultNamespace:
           template: <workspace_namespace_template>

   Copy code to clipboard

   where:

   <workspace_namespace_template>

   The project name template. Must include the <username> or <userid> placeholder.

   Table 2.1. User workspaces project name template examples

   User workspaces project name template	Resulting project example
   <username>-devspaces (default)	user1-devspaces
   <userid>-namespace	cge1egvsb2nhba-namespace-ul1411
   <userid>-aka-<username>-namespace	cgezegvsb2nhba-aka-user1-namespace-6m2w2b

Procedure

1. Disable automatic namespace provisioning on the CheCluster level:

   devEnvironments:
     defaultNamespace:
       autoProvision: false

   Copy code to clipboard

2. Create the <project_name> project for <username> user with the following labels and annotations:

   kind: Namespace
   apiVersion: v1
   metadata:
     name: <project_name>
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-namespace
     annotations:
       che.eclipse.org/username: <username>

   Copy code to clipboard

   where:

   <project_name>

   A project name of your choosing.

   <username>

   The username of the OpenShift Dev Spaces user.

Procedure

1. Create the following ConfigMap to mount it into every workspace:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: devspaces-user-configmap
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   data:
     ...

   Copy code to clipboard

   Optional: Use annotations to configure how the ConfigMap is mounted.

   Table 2.2. Optional annotations

   Annotation	Description
   che.eclipse.org/sync-retain-on-delete:	When set to "true", the ConfigMap is retained in a user namespace after being deleted from openshift-devspaces namespace.
   controller.devfile.io/mount-on-start:	When set to "true", the ConfigMap is mounted only at workspace start. This prevents workspace restarts when the ConfigMap is created.
   controller.devfile.io/mount-to-devworkspace-include:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the ConfigMap is mounted only to workspaces whose names match at least one pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).
   controller.devfile.io/mount-to-devworkspace-exclude:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the ConfigMap is mounted to all workspaces except those whose names match a pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).

   Note

   When both annotations controller.devfile.io/mount-to-devworkspace-include and controller.devfile.io/mount-to-devworkspace-exclude are set, the resource is mounted only to workspaces that match the include pattern and do not match the exclude pattern.

   For other labels and annotations, see the Content from github.com is not included.mounting volumes, configmaps, and secrets.

   For example, to mount a default SSH configuration into every workspace, create a ConfigMap:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: ssh-config-configmap
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/component: workspaces-config
       app.kubernetes.io/part-of: che.eclipse.org
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /etc/ssh/ssh_config.d/
   data:
     ssh.conf: <ssh_config_content>

   Copy code to clipboard

   The ConfigMap propagates the SSH configuration as an extension by using Include /etc/ssh/ssh_config.d/*.conf. For details, see Content from man.openbsd.org is not included.Include definition.

2. Create the following Secret to mount it into every workspace:

   kind: Secret
   apiVersion: v1
   metadata:
     name: devspaces-user-secret
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   stringData:
       ...

   Copy code to clipboard

   Optional: Use annotations to configure how the Secret is mounted.

   Table 2.3. Optional annotations

   Annotation	Description
   che.eclipse.org/sync-retain-on-delete:	When set to "true", the Secret is retained in a user namespace after being deleted from openshift-devspaces namespace.
   controller.devfile.io/mount-on-start:	When set to "true", the Secret is mounted only at workspace start. This prevents workspace restarts when the Secret is created.
   controller.devfile.io/mount-to-devworkspace-include:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the Secret is mounted only to workspaces whose names match at least one pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).
   controller.devfile.io/mount-to-devworkspace-exclude:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the Secret is mounted to all workspaces except those whose names match a pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).

   Note

   When both annotations controller.devfile.io/mount-to-devworkspace-include and controller.devfile.io/mount-to-devworkspace-exclude are set, the resource is mounted only to workspaces that match the include pattern and do not match the exclude pattern.

   For other labels and annotations, see the Content from github.com is not included.mounting volumes, configmaps, and secrets.

3. Create the following PersistentVolumeClaim for every user project:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: devspaces-user-pvc
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   spec:
     ...

   Copy code to clipboard

   Optional: Use annotations to configure how the PersistentVolumeClaim is mounted.

   Note

   The PersistentVolumeClaim is not deleted in a user namespace by default if the one from openshift-devspaces is deleted.

   Table 2.4. Optional annotations

   Annotation	Description
   che.eclipse.org/sync-retain-on-delete:	When set to "false", the PersistentVolumeClaim is deleted in a user namespace when it is deleted from openshift-devspaces namespace.
   controller.devfile.io/mount-on-start:	When set to "true", the PersistentVolumeClaim is mounted only at workspace start. This prevents workspace restarts when the PersistentVolumeClaim is created.
   controller.devfile.io/mount-to-devworkspace-include:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the PersistentVolumeClaim is mounted only to workspaces whose names match at least one pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).
   controller.devfile.io/mount-to-devworkspace-exclude:	Specifies a comma-separated list of Dev Workspace name patterns. When set, the PersistentVolumeClaim is mounted to all workspaces except those whose names match a pattern. Patterns support exact match, prefix (name*), suffix (*name), contains (*name*).

   Note

   When both annotations controller.devfile.io/mount-to-devworkspace-include and controller.devfile.io/mount-to-devworkspace-exclude are set, the resource is mounted only to workspaces that match the include pattern and do not match the exclude pattern.

   For other labels and annotations, see the Content from github.com is not included.mounting volumes, configmaps, and secrets.

4. Optional: To use the OpenShift Kubernetes Engine, create a Template object to replicate all resources defined within the template across each user project.

   Aside from the previously mentioned ConfigMap, Secret, and PersistentVolumeClaim, Template objects can include:

   • LimitRange
   • NetworkPolicy
   • ResourceQuota
   • Role

   • RoleBinding

     apiVersion: template.openshift.io/v1
     kind: Template
     metadata:
       name: devspaces-user-namespace-configurator
       namespace: openshift-devspaces
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: workspaces-config
     objects:
       ...
     parameters:
     - name: PROJECT_NAME
     - name: PROJECT_ADMIN_USER

     Copy code to clipboard

     The parameters are optional and define which parameters can be used. Currently, only PROJECT_NAME and PROJECT_ADMIN_USER are supported. PROJECT_NAME is the name of the OpenShift Dev Spaces namespace, while PROJECT_ADMIN_USER is the OpenShift Dev Spaces user of the namespace.

     The namespace name in objects is replaced with the user’s namespace name during synchronization.

     For example, a Template that replicates ResourceQuota, LimitRange, Role, and RoleBinding objects:

     apiVersion: template.openshift.io/v1
     kind: Template
     metadata:
       name: devspaces-user-namespace-configurator
       namespace: openshift-devspaces
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: workspaces-config
     objects:
     - apiVersion: v1
       kind: ResourceQuota
       metadata:
         name: devspaces-user-resource-quota
       spec:
         ...
     - apiVersion: v1
       kind: LimitRange
       metadata:
         name: devspaces-user-resource-constraint
       spec:
         ...
     - apiVersion: rbac.authorization.k8s.io/v1
       kind: Role
       metadata:
         name: devspaces-user-roles
       rules:
         ...
     - apiVersion: rbac.authorization.k8s.io/v1
       kind: RoleBinding
       metadata:
         name: devspaces-user-rolebinding
       roleRef:
         apiGroup: rbac.authorization.k8s.io
         kind: Role
         name: devspaces-user-roles
       subjects:
       - kind: User
         apiGroup: rbac.authorization.k8s.io
         name: ${PROJECT_ADMIN_USER}
     parameters:
     - name: PROJECT_ADMIN_USER

     Copy code to clipboard
     Note

     Creating Template Kubernetes resources is supported only on OpenShift.

Procedure

1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-settings
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
   ...

   Copy code to clipboard

   where:

   kind

   Secret for a Secret or ConfigMap for a ConfigMap.

   <DEPLOYMENT_NAME>

   Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.

   <OBJECT_KIND>

   secret for a Secret or configmap for a ConfigMap.

2. Configure the annotation values. Annotations must indicate that the given object is mounted as a file:

   • che.eclipse.org/mount-as: file - Mounts an object as a file.

   • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

     For a Secret:

     apiVersion: v1
     kind: Secret
     metadata:
       name: custom-data
       annotations:
         che.eclipse.org/mount-as: file
         che.eclipse.org/mount-path: /data
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-secret
     ...

     Copy code to clipboard

     For a ConfigMap:

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: custom-data
       annotations:
         che.eclipse.org/mount-as: file
         che.eclipse.org/mount-path: /data
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-configmap
     ...

     Copy code to clipboard

3. Add data items to the object. Each item name must match the desired file name mounted into the container.

   For a Secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-data
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-secret
     annotations:
       che.eclipse.org/mount-as: file
       che.eclipse.org/mount-path: /data
   data:
     ca.crt: <base64 encoded data content here>

   Copy code to clipboard

   For a ConfigMap:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: custom-data
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-configmap
     annotations:
       che.eclipse.org/mount-as: file
       che.eclipse.org/mount-path: /data
   data:
     ca.crt: <data content here>

   Copy code to clipboard

Procedure

1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-settings
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
   ...

   Copy code to clipboard

   where:

   kind

   Secret for a Secret or ConfigMap for a ConfigMap.

   <DEPLOYMENT_NAME>

   Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.

   <OBJECT_KIND>

   secret for a Secret or configmap for a ConfigMap.

2. Configure the annotation values. Annotations must indicate that the given object is mounted as a subPath:

   • che.eclipse.org/mount-as: subpath - Mounts an object as a subPath.

   • che.eclipse.org/mount-path: <TARGET_PATH> - To provide a required mount path.

     For a Secret:

     apiVersion: v1
     kind: Secret
     metadata:
       name: custom-data
       annotations:
         che.eclipse.org/mount-as: subpath
         che.eclipse.org/mount-path: /data
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-secret
     ...

     Copy code to clipboard

     For a ConfigMap:

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: custom-data
       annotations:
         che.eclipse.org/mount-as: subpath
         che.eclipse.org/mount-path: /data
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-configmap
     ...

     Copy code to clipboard

3. Add data items to the object. Each item name must match the file name mounted into the container.

   For a Secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-data
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-secret
     annotations:
       che.eclipse.org/mount-as: subpath
       che.eclipse.org/mount-path: /data
   data:
     ca.crt: <base64 encoded data content here>

   Copy code to clipboard

   For a ConfigMap:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: custom-data
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-configmap
     annotations:
       che.eclipse.org/mount-as: subpath
       che.eclipse.org/mount-path: /data
   data:
     ca.crt: <data content here>

   Copy code to clipboard

Procedure

1. Create a new OpenShift Secret or a ConfigMap in the OpenShift project where OpenShift Dev Spaces is deployed with the required labels:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-settings
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
   ...

   Copy code to clipboard

   where:

   kind

   Secret for a Secret or ConfigMap for a ConfigMap.

   <DEPLOYMENT_NAME>

   Target deployment: devspaces, devspaces-dashboard, devfile-registry, or plugin-registry.

   <OBJECT_KIND>

   secret for a Secret or configmap for a ConfigMap.

2. Configure the annotation values. Annotations must indicate that the given object is mounted as an environment variable:

   • che.eclipse.org/mount-as: env - Mounts an object as an environment variable.

   • che.eclipse.org/env-name: <FOO_ENV> - Provides the environment variable name, which is required to mount an object key value.

     For a Secret:

     apiVersion: v1
     kind: Secret
     metadata:
       name: custom-settings
       annotations:
         che.eclipse.org/env-name: FOO_ENV
         che.eclipse.org/mount-as: env
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-secret
     stringData:
       mykey: myvalue

     Copy code to clipboard

     For a ConfigMap:

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: custom-settings
       annotations:
         che.eclipse.org/env-name: FOO_ENV
         che.eclipse.org/mount-as: env
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: devspaces-configmap
     data:
       mykey: myvalue

     Copy code to clipboard

3. If the object provides more than one data item, provide the environment variable name for each data key by using the che.eclipse.org/<key>_env-name annotation format.

   For a Secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name: custom-settings
     annotations:
       che.eclipse.org/mount-as: env
       che.eclipse.org/mykey_env-name: FOO_ENV
       che.eclipse.org/otherkey_env-name: OTHER_ENV
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-secret
   stringData:
     mykey: <data_content_here>
     otherkey: <data_content_here>

   Copy code to clipboard

   For a ConfigMap:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: custom-settings
     annotations:
       che.eclipse.org/mount-as: env
       che.eclipse.org/mykey_env-name: FOO_ENV
       che.eclipse.org/otherkey_env-name: OTHER_ENV
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: devspaces-configmap
   data:
     mykey: <data content here>
     otherkey: <data content here>

   Copy code to clipboard

   The maximum length of annotation names in an OpenShift object is 63 characters, where 9 characters are reserved for a prefix that ends with /. This restricts the maximum length of the key that can be used for the object.

Procedure

1. Get the name of the OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   $ oc get checluster --all-namespaces \
     -o=jsonpath="{.items[*].metadata.namespace}"

   Copy code to clipboard

2. Configure the maxNumberOfWorkspacesPerUser in the CheCluster Custom Resource:

   spec:
     devEnvironments:
       maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>

   Copy code to clipboard

   where:

   <kept_workspaces_limit>

   The maximum number of workspaces per user. The default value, -1, allows users to keep an unlimited number of workspaces. Use a positive integer to set the maximum number of workspaces per user.

3. Apply the change:

   $ oc patch checluster/devspaces -n openshift-devspaces \
   --type='merge' -p \
   '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'

   Copy code to clipboard

   where:

   -n

   The OpenShift Dev Spaces namespace that you got in step 1.

Procedure

1. Configure the maxNumberOfRunningWorkspacesPerCluster in the CheCluster Custom Resource:

   spec:
     devEnvironments:
       maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>

   Copy code to clipboard

   where:

   <running_workspaces_limit>

   The maximum number of concurrently running workspaces across the entire Kubernetes cluster. This applies to all users in the system. The -1 value means there is no limit on the number of running workspaces.

2. Apply the change:

   $ oc patch checluster/devspaces -n openshift-devspaces \
   --type='merge' -p \
   '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'

   Copy code to clipboard

Procedure

1. Get the name of the OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   $ oc get checluster --all-namespaces \
     -o=jsonpath="{.items[*].metadata.namespace}"

   Copy code to clipboard

2. Configure the maxNumberOfRunningWorkspacesPerUser in the CheCluster Custom Resource:

   spec:
     devEnvironments:
       maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>

   Copy code to clipboard

   where:

   <running_workspaces_limit>

   The maximum number of simultaneously running workspaces per user. The -1 value enables users to run an unlimited number of workspaces. The default value is 1.

3. Apply the change:

   $ oc patch checluster/devspaces -n openshift-devspaces \
   --type='merge' -p \
   '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'

   Copy code to clipboard

   where:

   -n

   The OpenShift Dev Spaces namespace that you got in step 1.

Procedure

1. Create a new ConfigMap with details about the Git server:

   $ oc create configmap che-git-self-signed-cert \
     --from-file=ca.crt=<path_to_certificate> \
     --from-literal=githost=<git_server_url> -n openshift-devspaces

   Copy code to clipboard

   where:

   --from-file

   Path to the self-signed certificate.

   --from-literal

   Optional parameter to specify the Git server URL for example Content from git.example.com is not included.https://git.example.com:8443. When omitted, the self-signed certificate is used for all repositories over HTTPS.

   Note

   • Certificate files are typically stored as Base64 ASCII files, such as. .pem, .crt, .ca-bundle. All ConfigMaps that hold certificate files should use the Base64 ASCII certificate rather than the binary data certificate.
   • A certificate chain of trust is required. If the ca.crt is signed by a certificate authority (CA), the CA certificate must be included in the ca.crt file.

2. Add the required labels to the ConfigMap:

   $ oc label configmap che-git-self-signed-cert \
     app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces

   Copy code to clipboard

3. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     devEnvironments:
       trustedCerts:
         gitTrustedCertsConfigMapName: che-git-self-signed-cert

   Copy code to clipboard

Procedure

1. Set nodeSelector in the CheCluster Custom Resource to schedule workspace Pods on specific nodes:

   spec:
     devEnvironments:
       nodeSelector:
         <key>: <value>

   Copy code to clipboard

   This section must contain a set of key=value pairs for each node label to form the nodeSelector rule.

2. Set tolerations in the CheCluster Custom Resource to allow workspace Pods to be scheduled on tainted nodes. Tolerations work in the opposite way to nodeSelector. Instead of specifying which nodes the Pod is scheduled on, you specify which nodes the Pod cannot be scheduled on.

   spec:
     devEnvironments:
       tolerations:
         - effect: NoSchedule
           key: <key>
           value: <value>
           operator: Equal

   Copy code to clipboard
   Important

   nodeSelector must be configured during OpenShift Dev Spaces installation. This prevents existing workspaces from failing to run due to volumes affinity conflict caused by existing workspace PVC and Pod being scheduled in different zones.

   On large, multizone clusters, Pods and PVCs can be scheduled in different zones. To avoid this, create an additional StorageClass object (pay attention to the allowedTopologies field) to coordinate the PVC creation process.

   Pass the name of this newly created StorageClass to OpenShift Dev Spaces through the CheCluster Custom Resource. For more information, see: Use a custom storage provisioner.

Procedure

1. Patch the CheCluster Custom Resource to configure the allowed source URLs:

   oc patch checluster/devspaces \
       --namespace openshift-devspaces \
       --type='merge' \
       -p \
   '{
      "spec": {
        "devEnvironments": {
          "allowedSources": {
            "urls": ["<url_1>", "<url_2>"]
          }
        }
      }
    }'

   Copy code to clipboard

   where:

   urls

   The array of approved URLs for starting CDEs. Wildcards * are supported. For example, Content from example.com is not included.https://example.com/\* allows CDEs from any path within example.com.

Procedure

1. Configure the CheCluster custom resource to enable container run capabilities:

   oc patch checluster/devspaces -n openshift-devspaces \
     --type='merge' -p \
     '{"spec":{"devEnvironments":{"disableContainerRunCapabilities":false}}}'

   Copy code to clipboard

Procedure

1. Deploy the plugin.yaml devfile v2 file to an HTTP server with the environment variables set correctly.

2. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     devEnvironments:
       defaultPlugins:
       - editor: eclipse/che-theia/next
         plugins:
         - '<your_plugin_url>'

   Copy code to clipboard

   where:

   editor

   The editorId to set the telemetry plugin for.

   plugins

   The URL to the telemetry plugin’s devfile v2 definition, for example, Content from your-web-server is not included.https://your-web-server/plugin.yaml.

Procedure

1. For a fresh installation of OpenShift Dev Spaces, generate metrics by creating a OpenShift Dev Spaces workspace from the Dashboard.
2. In the Administrator view of the OpenShift web console, go to Observe → Metrics.
3. Run a PromQL query to confirm that the metrics are available. For example, enter devworkspace_started_total and click Run queries.

1. Get the name of the Prometheus pod:

   $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'

   Copy code to clipboard

2. Print the last 20 lines of the Prometheus container logs from the Prometheus pod from the previous step:

   $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring

   Copy code to clipboard

Procedure

1. Create a ConfigMap for the dashboard definition in the openshift-config-managed project and apply the necessary label.

   1. $ oc create configmap grafana-dashboard-dwo \
        --from-literal=dwo-dashboard.json="$(curl https://raw.githubusercontent.com/devfile/devworkspace-operator/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed

      Copy code to clipboard
      Note

      The previous command contains a link to material from the upstream community. This material represents the very latest available content and the most recent best practices. These tips have not yet been vetted by Red Hat’s QE department, and they have not yet been proven by a wide user group. Please, use this information cautiously.

   2. $ oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed

      Copy code to clipboard
      Note

      The dashboard definition is based on Grafana 6.x dashboards. Not all Grafana 6.x dashboard features are supported in the OpenShift web console.

Verification

1. In the Administrator view of the OpenShift web console, go to Observe → Dashboards.
2. Go to Dashboard → Dev Workspace Operator and verify that the dashboard panels contain data.

Procedure

1. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     components:
       metrics:
         enable: <boolean>

   Copy code to clipboard

   where:

   <boolean>

   true to enable, false to disable.

Procedure

1. In the Administrator view of the OpenShift web console, go to Observe → Metrics.
2. Run a PromQL query to confirm that the metrics are available. For example, enter process_uptime_seconds{job="che-host"} and click Run queries.

1. Get the name of the Prometheus pod:

   $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'

   Copy code to clipboard

2. Print the last 20 lines of the Prometheus container logs from the Prometheus pod from the previous step:

   $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring

   Copy code to clipboard

Procedure

1. Create a ConfigMap for the dashboard definition in the openshift-config-managed project and apply the necessary label.

   1. $ oc create configmap grafana-dashboard-devspaces-server \
        --from-literal=devspaces-server-dashboard.json="$(curl https://raw.githubusercontent.com/eclipse-che/che-server/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed

      Copy code to clipboard
      Note

      The previous command contains a link to material from the upstream community. This material represents the very latest available content and the most recent best practices. These tips have not yet been vetted by Red Hat’s QE department, and they have not yet been proven by a wide user group. Please, use this information cautiously.

   2. $ oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed

      Copy code to clipboard
      Note

      The dashboard definition is based on Grafana 6.x dashboards. Not all Grafana 6.x dashboard features are supported in the OpenShift web console.

Verification

1. In the Administrator view of the OpenShift web console, go to Observe → Dashboards.

2. Go to Dashboard → Che Server JVM and verify that the dashboard panels contain data.

   Figure 5.3. Quick Facts

   

   Figure 5.4. JVM Memory

   

   Figure 5.5. JVM Misc

   

   Figure 5.6. JVM Memory Pools (heap)

   

   Figure 5.7. JVM Memory Pools (Non-Heap)

   

   Figure 5.8. Garbage Collection

   

   Figure 5.9. Class loading

   

   Figure 5.10. Buffer Pools

   

Procedure

1. Go to Content from github.com is not included.the GitHub OAuth application registration page.

2. Enter the following values:

   1. Application name: <application name>
   2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
   3. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
3. Click Register application.
4. Click Generate new client secret.
5. Copy and save the GitHub OAuth Client ID for use when applying the GitHub OAuth App Secret.
6. Copy and save the GitHub OAuth Client Secret for use when applying the GitHub OAuth App Secret.

Procedure

1. Register a GitHub App. See Content from docs.github.com is not included.Registering a GitHub App.

2. Enter the following values:

   1. GitHub App name: <application_name>
   2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
   3. Callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
   4. Deselect the Active check box in the Webhook section.
   5. Under Permissions & events, set the Contents repository permission to Read and Write.
3. Click Create GitHub App.
4. Click Generate a new client secret.
5. Copy and save the GitHub App Client Secret for use when applying the GitHub App Secret.
6. Copy and save the GitHub App Client ID for use when applying the GitHub App Secret.
7. Install the GitHub App. See Content from docs.github.com is not included.Installing your own GitHub App.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: github-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: oauth-scm-configuration
     annotations:
       che.eclipse.org/oauth-scm-server: github
       che.eclipse.org/scm-server-endpoint: <github_server_url>
       che.eclipse.org/scm-github-disable-subdomain-isolation: 'false'
   type: Opaque
   stringData:
     id: <GitHub_OAuth_Client_ID>
     secret: <GitHub_OAuth_Client_Secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   che.eclipse.org/scm-server-endpoint

   This depends on the GitHub product your organization is using. When hosting repositories on GitHub.com or GitHub Enterprise Cloud, omit this line or enter the default Content from github.com is not included.https://github.com. When hosting repositories on GitHub Enterprise Server, enter the GitHub Enterprise Server URL.

   che.eclipse.org/scm-github-disable-subdomain-isolation

   If you are using GitHub Enterprise Server with a disabled Content from docs.github.com is not included.subdomain isolation option, you must set the annotation to true. Otherwise, you can either omit the annotation or set it to false.

   id

   The GitHub OAuth Client ID.

   secret

   The GitHub OAuth Client Secret.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard
3. Optional: To configure OAuth 2.0 for another GitHub provider, repeat the previous steps and create a second GitHub OAuth Secret with a different name.

Procedure

1. Click your avatar and go to Edit profile → Applications.
2. Enter OpenShift Dev Spaces as the Name.
3. Enter https://<openshift_dev_spaces_fqdn>/api/oauth/callback as the Redirect URI.
4. Check the Confidential and Expire access tokens checkboxes.
5. Under Scopes, check the api, write_repository, and openid checkboxes.
6. Click Save application.
7. Copy and save the GitLab Application ID for use when applying the GitLab-authorized application Secret.
8. Copy and save the GitLab Client Secret for use when applying the GitLab-authorized application Secret.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: gitlab-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: oauth-scm-configuration
     annotations:
       che.eclipse.org/oauth-scm-server: gitlab
       che.eclipse.org/scm-server-endpoint: <gitlab_server_url>
   type: Opaque
   stringData:
     id: <GitLab_Application_ID>
     secret: <GitLab_Client_Secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   che.eclipse.org/scm-server-endpoint

   The GitLab server URL. Use Content from gitlab.com is not included.https://gitlab.com for the SAAS version.

   id

   The GitLab Application ID.

   secret

   The GitLab Client Secret.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard
3. Optional: To configure OAuth 2.0 for another GitLab provider, repeat the previous steps and create a second GitLab OAuth Secret with a different name.

Procedure

1. Go to Administration > Applications > Application links.
2. Select Create link.
3. Select External application and Incoming.
4. Enter https://<openshift_dev_spaces_fqdn>/api/oauth/callback to the Redirect URL field.
5. Select the Admin - Write checkbox in Application permissions.
6. Click Save.
7. Copy and save the Client ID for use when applying the Bitbucket application link Secret.
8. Copy and save the Client secret for use when applying the Bitbucket application link Secret.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: bitbucket-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: oauth-scm-configuration
     annotations:
       che.eclipse.org/oauth-scm-server: bitbucket
       che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
   type: Opaque
   stringData:
     id: <Bitbucket_Client_ID>
     secret: <Bitbucket_Client_Secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   che.eclipse.org/scm-server-endpoint

   The URL of the Bitbucket Server.

   id

   The Bitbucket Client ID.

   secret

   The Bitbucket Client secret.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. Click your avatar and go to the All workspaces page.
2. Select a workspace and click it.
3. Go to Settings → OAuth consumers → Add consumer.
4. Enter OpenShift Dev Spaces as the Name.
5. Enter https://<openshift_dev_spaces_fqdn>/api/oauth/callback as the Callback URL.
6. Under Permissions, check all of the Account and Repositories checkboxes, and click Save.
7. Expand the added consumer and then copy and save the Key value for use when applying the Bitbucket OAuth consumer Secret.
8. Copy and save the Secret value for use when applying the Bitbucket OAuth consumer Secret.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: bitbucket-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: oauth-scm-configuration
     annotations:
       che.eclipse.org/oauth-scm-server: bitbucket
   type: Opaque
   stringData:
     id: <Bitbucket_Oauth_Consumer_Key>
     secret: <Bitbucket_Oauth_Consumer_Secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   id

   The Bitbucket OAuth consumer Key.

   secret

   The Bitbucket OAuth consumer Secret.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. On a command line, run the commands to create the necessary files for the next steps and for use when applying the application link Secret:

   $ openssl genrsa -out private.pem 2048 && \
   openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \
   cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \
   openssl rsa -in private.pem -pubout > public.pub && \
   cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \
   openssl rand -base64 24 > bitbucket-consumer-key && \
   openssl rand -base64 24 > bitbucket-shared-secret

   Copy code to clipboard
2. Go to Administration → Application Links, enter https://<openshift_dev_spaces_fqdn>/ into the URL field, and click Create new link.
3. Under The supplied Application URL has redirected once, check the Use this URL checkbox and click Continue.

4. Configure the application link with the following values:

   1. Enter OpenShift Dev Spaces as the Application Name.
   2. Select Generic Application as the Application Type.
   3. Enter OpenShift Dev Spaces as the Service Provider Name.
   4. Paste the content of the bitbucket-consumer-key file as the Consumer key.
   5. Paste the content of the bitbucket-shared-secret file as the Shared secret.
   6. Enter <bitbucket_server_url>/plugins/servlet/oauth/request-token as the Request Token URL.
   7. Enter <bitbucket_server_url>/plugins/servlet/oauth/access-token as the Access token URL.
   8. Enter <bitbucket_server_url>/plugins/servlet/oauth/authorize as the Authorize URL.
   9. Check the Create incoming link checkbox and click Continue.

5. Configure the incoming link with the following values:

   1. Paste the content of the bitbucket-consumer-key file as the Consumer Key.
   2. Enter OpenShift Dev Spaces as the Consumer name.
   3. Paste the content of the public-stripped.pub file as the Public Key and click Continue.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: bitbucket-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/component: oauth-scm-configuration
       app.kubernetes.io/part-of: che.eclipse.org
     annotations:
       che.eclipse.org/oauth-scm-server: bitbucket
       che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
   type: Opaque
   stringData:
     private.key: <Content_of_privatepkcs8-stripped.pem>
     consumer.key: <Content_of_bitbucket-consumer-key>
     shared_secret: <Content_of_bitbucket-shared-secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   che.eclipse.org/scm-server-endpoint

   The URL of the Bitbucket Server.

   private.key

   The content of the privatepkcs8-stripped.pem file.

   consumer.key

   The content of the bitbucket-consumer-key file.

   shared_secret

   The content of the bitbucket-shared-secret file.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. Register an application in Microsoft Entra ID. See Content from learn.microsoft.com is not included.Register an application.
2. Add the Authorization callback URL https://<openshift_dev_spaces_fqdn>/api/oauth/callback to your application. See Content from learn.microsoft.com is not included.Add a redirect URI.
3. Add a client secret to your application. See Content from learn.microsoft.com is not included.Add credentials.
4. Add the Azure DevOps vso.code_write permission to the client application. See Content from learn.microsoft.com is not included.Add permissions to access your web API.
5. Connect your Azure DevOps organization to Microsoft Entra ID. See Content from learn.microsoft.com is not included.Connect your organization to Microsoft Entra ID.

Procedure

1. Prepare the Secret:

   kind: Secret
   apiVersion: v1
   metadata:
     name: azure-devops-oauth-config
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: oauth-scm-configuration
     annotations:
       che.eclipse.org/oauth-scm-server: azure-devops
   type: Opaque
   stringData:
     tenant-id: <Microsoft_Entra_ID_Tenant_ID>
     id: <Microsoft_Entra_ID_App_ID>
     secret: <Microsoft_Entra_ID_Client_Secret>

   Copy code to clipboard

   where:

   namespace

   The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

   tenant-id

   The Microsoft Entra ID Directory (tenant) ID.

   id

   The Microsoft Entra ID Application (client) ID.

   secret

   The Microsoft Entra ID Client Secret.

2. Apply the Secret:

   $ oc apply -f - <<EOF
   <Secret_prepared_in_the_previous_step>
   EOF

   Copy code to clipboard

Procedure

1. Modify the CheCluster Custom Resource to enable forced token refresh:

   spec:
     components:
       cheServer:
         extraProperties:
           CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"

   Copy code to clipboard

Procedure

1. Create an allow-from-openshift-devspaces.yaml file. The allow-from-openshift-devspaces NetworkPolicy allows incoming traffic from the OpenShift Dev Spaces namespace to all Pods in the user project.

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
       name: allow-from-openshift-devspaces
   spec:
       ingress:
       - from:
           - namespaceSelector:
               matchLabels:
                   kubernetes.io/metadata.name: openshift-devspaces
       podSelector: {}
       policyTypes:
       - Ingress

   Copy code to clipboard

   where:

   kubernetes.io/metadata.name: openshift-devspaces

   Selects traffic from the OpenShift Dev Spaces namespace. The default namespace is openshift-devspaces.

   podSelector: {}

   The empty podSelector selects all Pods in the project.

2. Apply the allow-from-openshift-devspaces NetworkPolicy to each user project:

   oc apply -f allow-from-openshift-devspaces.yaml -n <user_namespace>

   Copy code to clipboard

3. Optional: If you configured multitenant isolation with network policy, create and apply the allow-from-openshift-apiserver and allow-from-workspaces-namespaces NetworkPolicies to openshift-devspaces. The allow-from-openshift-apiserver NetworkPolicy allows incoming traffic from the openshift-apiserver namespace to the devworkspace-webhook-server, enabling webhooks. The allow-from-workspaces-namespaces NetworkPolicy allows incoming traffic from each user project to the che-gateway pod.

   1. Create an allow-from-openshift-apiserver.yaml file:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-apiserver
        namespace: openshift-devspaces
      spec:
        podSelector:
          matchLabels:
            app.kubernetes.io/name: devworkspace-webhook-server
        ingress:
          - from:
              - podSelector: {}
                namespaceSelector:
                  matchLabels:
                    kubernetes.io/metadata.name: openshift-apiserver
        policyTypes:
          - Ingress

      Copy code to clipboard

      where:

      namespace: openshift-devspaces

      The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

      app.kubernetes.io/name: devworkspace-webhook-server

      The podSelector only selects devworkspace-webhook-server pods.

   2. Create an allow-from-workspaces-namespaces.yaml file:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-workspaces-namespaces
        namespace: openshift-devspaces
      spec:
        podSelector: {}
        ingress:
          - from:
              - podSelector: {}
                namespaceSelector:
                  matchLabels:
                    app.kubernetes.io/component: workspaces-namespace
        policyTypes:
          - Ingress

      Copy code to clipboard

      where:

      namespace: openshift-devspaces

      The OpenShift Dev Spaces namespace. The default is openshift-devspaces.

      podSelector: {}

      The empty podSelector selects all pods in the OpenShift Dev Spaces namespace.

   3. Apply both NetworkPolicies:

      oc apply -f allow-from-openshift-apiserver.yaml -n openshift-devspaces
      oc apply -f allow-from-workspaces-namespaces.yaml -n openshift-devspaces

      Copy code to clipboard

Procedure

1. Pre-create a project for OpenShift Dev Spaces:

   $ oc create project openshift-devspaces

   Copy code to clipboard

2. Create a TLS secret:

   $ oc create secret tls <tls_secret_name> \
   --key <key_file> \
   --cert <cert_file> \
   -n openshift-devspaces

   Copy code to clipboard

   where:

   <tls_secret_name>

   The TLS secret name.

   --key

   A file with the private key.

   --cert

   A file with the certificate.

3. Add the required labels to the secret:

   $ oc label secret <tls_secret_name> \
   app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces

   Copy code to clipboard

   where:

   <tls_secret_name>

   The TLS secret name.

4. Configure the CheCluster Custom Resource:

   spec:
     networking:
       hostname: <hostname>
       tlsSecretName: <secret>

   Copy code to clipboard

   where:

   <hostname>

   Custom Red Hat OpenShift Dev Spaces server hostname.

   <secret>

   The TLS secret name.

5. If OpenShift Dev Spaces is already deployed, wait for the rollout of all OpenShift Dev Spaces components to complete.

Procedure

1. Concatenate all CA chains PEM files to import, into the custom-ca-certificates.pem file, and remove the return character that is incompatible with the Java truststore.

   $ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem

   Copy code to clipboard

2. Create the custom-ca-certificates ConfigMap with the required TLS certificates:

   $ oc create configmap custom-ca-certificates \
       --from-file=custom-ca-certificates.pem \
       --namespace=openshift-devspaces

   Copy code to clipboard

3. Label the custom-ca-certificates ConfigMap:

   $ oc label configmap custom-ca-certificates \
       app.kubernetes.io/component=ca-bundle \
       app.kubernetes.io/part-of=che.eclipse.org \
       --namespace=openshift-devspaces

   Copy code to clipboard
4. Deploy OpenShift Dev Spaces if it has not been deployed before. Otherwise, wait until the rollout of OpenShift Dev Spaces components finishes.
5. Restart running workspaces for the changes to take effect.

Verification

1. Verify that the ConfigMap contains your custom CA certificates. This command returns CA bundle certificates in PEM format:

   oc get configmap \
       --namespace=openshift-devspaces \
       --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
       --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org

   Copy code to clipboard

2. Verify in the OpenShift Dev Spaces server logs that the imported certificates count is not null:

   oc logs deploy/devspaces --namespace=openshift-devspaces \
       | grep tls-ca-bundle.pem

   Copy code to clipboard
3. Start a workspace, get the project name in which it has been created: <workspace_namespace>, and wait for the workspace to be started.

4. Verify that the ca-certs-merged ConfigMap contains your custom CA certificates. This command returns OpenShift Dev Spaces CA bundle certificates in PEM format:

   oc get configmap ca-certs-merged \
       --namespace=<workspace_namespace> \
       --output='jsonpath={.data.tls-ca-bundle\.pem}'

   Copy code to clipboard

5. Verify that the workspace pod mounts the ca-certs-merged ConfigMap:

   oc get pod \
       --namespace=<workspace_namespace> \
       --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
       --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
       | grep ca-certs-merged

   Copy code to clipboard

6. Get the workspace pod name <workspace_pod_name>:

   oc get pod \
       --namespace=<workspace_namespace> \
       --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
       --output='jsonpath={.items[0:].metadata.name}'

   Copy code to clipboard

7. Verify that the workspace container has your custom CA certificates. This command returns OpenShift Dev Spaces CA bundle certificates in PEM format:

   oc exec <workspace_pod_name> \
       --namespace=<workspace_namespace> \
       -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

   Copy code to clipboard

   Or if disableWorkspaceCaBundleMount set to true:

   oc exec <workspace_pod_name> \
       --namespace=<workspace_namespace> \
       -- cat /public-certs/tls-ca-bundle.pem

   Copy code to clipboard

Procedure

1. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     networking:
       labels: <labels>
       domain: <domain>
       annotations: <annotations>

   Copy code to clipboard

   where:

   <labels>

   An unstructured key value map of labels that the target ingress controller uses to filter the set of Routes to service.

   <domain>

   The DNS name serviced by the target ingress controller.

   <annotations>

   An unstructured key value map stored with a resource.

Procedure

1. Set the CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX field in the CheCluster Custom Resource:

   spec:
     components:
       cheServer:
         extraProperties:
           CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<base_domain>"

   Copy code to clipboard

   where:

   <base_domain>

   The workspace endpoints base domain, for example, my-devspaces.example.com.

2. Apply the change:

   oc patch checluster/devspaces \
       --namespace openshift-devspaces \
       --type='merge' -p \
   '{"spec":
       {"components":
           {"cheServer":
               {"extraProperties":
                   {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'

   Copy code to clipboard

Procedure

1. Optional: Create a Secret in the openshift-devspaces namespace that contains a user and password for a proxy server. The secret must have the app.kubernetes.io/part-of=che.eclipse.org label. Skip this step if the proxy server does not require authentication.

   oc apply -f - <<EOF
   kind: Secret
   apiVersion: v1
   metadata:
     name: devspaces-proxy-credentials
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
   type: Opaque
   stringData:
     user: <user>
     password: <password>
   EOF

   Copy code to clipboard

   where:

   <user>

   The username for the proxy server.

   <password>

   The password for the proxy server.

2. Configure the proxy or override the cluster-wide proxy configuration for an OpenShift cluster by setting the following properties in the CheCluster custom resource:

   oc patch checluster/devspaces \
       --namespace openshift-devspaces \
       --type='merge' -p \
   '{"spec":
       {"components":
           {"cheServer":
               {"proxy":
                   {"credentialsSecretName" : "<secretName>",
                    "nonProxyHosts"         : ["<host_1>"],
                    "port"                  : "<port>",
                    "url"                   : "<protocol>://<domain>"}}}}}'

   Copy code to clipboard

   where:

   <secretName>

   The credentials secret name created in the previous step.

   <host_1>

   The list of hosts that can be reached directly, without using the proxy. Use the following form .<DOMAIN> to specify a wildcard domain. OpenShift Dev Spaces Operator automatically adds .svc and Kubernetes service host to the list of non-proxy hosts. In OpenShift, OpenShift Dev Spaces Operator combines the non-proxy host list from the cluster-wide proxy configuration with the custom resource. In some proxy configurations, localhost may not translate to 127.0.0.1. Both localhost and 127.0.0.1 should be specified in this situation.

   <port>

   The port of the proxy server.

   <protocol>://<domain>

   Protocol and domain of the proxy server.

Verification

1. Start a workspace.
2. Verify that the workspace pod contains HTTP_PROXY, HTTPS_PROXY, http_proxy, and https_proxy environment variables, each set to <protocol>://<user>:<password>@<domain>:<port>.
3. Verify that the workspace pod contains NO_PROXY and no_proxy environment variables, each set to a comma-separated list of non-proxy hosts.

Procedure

1. Define storage class names: configure the CheCluster Custom Resource, and install OpenShift Dev Spaces. See This content is not included.Configuring the CheCluster Custom Resource during installation.

   spec:
     devEnvironments:
       storage:
         perUserStrategyPvcConfig:
           claimSize: <claim_size>
           storageClass: <storage_class_name>
         perWorkspaceStrategyPvcConfig:
           claimSize: <claim_size>
           storageClass: <storage_class_name>
         pvcStrategy: <pvc_strategy>

   Copy code to clipboard

   where:

   claimSize

   Persistent Volume Claim size.

   storageClass

   Storage class for the Persistent Volume Claim. When omitted or left blank, a default storage class is used.

   pvcStrategy

   Persistent volume claim strategy. The supported strategies are:

   • per-user: All workspaces Persistent Volume Claims share one volume.
   • per-workspace: Each workspace gets its own individual Persistent Volume Claim.
   • ephemeral: Non-persistent storage. Local changes are lost when the workspace stops.

Procedure

1. Set the pvcStrategy field in the CheCluster Custom Resource to per-user, per-workspace, or ephemeral:

   spec:
     devEnvironments:
       storage:
         pvc:
           pvcStrategy: 'per-user'

   Copy code to clipboard

   where:

   pvcStrategy

   The available storage strategies are per-user, per-workspace, and ephemeral.

   Note

   • You can set this field at installation. See This content is not included.Configuring the CheCluster Custom Resource during installation.
   • You can update this field on the command line. See Section 1.2, “Edit the central configuration from the command line”.

Procedure

1. Set the appropriate claimSize field for the desired storage strategy in the CheCluster Custom Resource.

   Note

   1. You can set this field at installation. See This content is not included.Configuring the CheCluster Custom Resource during installation.
   2. include::snippets/snip_edit-checluster-cr.adoc[]

   spec:
     devEnvironments:
       storage:
         pvc:
           pvcStrategy: '<strategy_name>'
           perUserStrategyPvcConfig:
             claimSize: <resource_quantity>
           perWorkspaceStrategyPvcConfig:
             claimSize: <resource_quantity>

   Copy code to clipboard

   where:

   <strategy_name>

   Select the storage strategy: per-user or per-workspace or ephemeral. Note: the ephemeral storage strategy does not use persistent storage, therefore you cannot configure its storage size or other PVC-related attributes.

   perUserStrategyPvcConfig, perWorkspaceStrategyPvcConfig

   Specify a claim size on the next line or omit the next line to set the default claim size value. The specified claim size is only used when you select this storage strategy.

   <resource_quantity>

   The claim size must be specified as a Content from kubernetes.io is not included.Kubernetes resource quantity. The available quantity units include: Ei, Pi, Ti, Gi, Mi and Ki.

   Important

   Manually modifying a PVC on the cluster that was provisioned by OpenShift Dev Spaces is not officially supported and may result in unexpected consequences.

   If you want to resize a PVC that is in use by a workspace, you must restart the workspace for the PVC change to occur.