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. Configure the CheCluster Custom Resource. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   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 3.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

   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.

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

2. Optional: To prevent the ConfigMap from being mounted automatically, add these labels:

   controller.devfile.io/watch-configmap: "false"
   controller.devfile.io/mount-to-devworkspace: "false"

   Copy code to clipboard

3. Optional: To retain the ConfigMap in a user namespace after deletion from openshift-devspaces, add this annotation:

   che.eclipse.org/sync-retain-on-delete: "true"

   Copy code to clipboard

4. 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

   See the Content from github.com is not included.mounting volumes, configmaps, and secrets for other possible labels and annotations.

5. Optional: To prevent the Secret from being mounted automatically, add these labels:

   controller.devfile.io/watch-secret: "false"
   controller.devfile.io/mount-to-devworkspace: "false"

   Copy code to clipboard

6. Optional: To retain the Secret in a user namespace after deletion from openshift-devspaces, add this annotation:

   che.eclipse.org/sync-retain-on-delete: "true"

   Copy code to clipboard

7. 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

   See the Content from github.com is not included.mounting volumes, configmaps, and secrets for other possible labels and annotations.

8. Optional: By default, deleting a PersistentVolumeClaim from openshift-devspaces does not delete it from a user namespace. To delete the PersistentVolumeClaim from user namespaces as well, add this annotation:

   che.eclipse.org/sync-retain-on-delete: "false"

   Copy code to clipboard

9. 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. Create an HPA resource for a deployment, specifying the target metrics and desired replica count.

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: scaler
     namespace: openshift-devspaces
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: <deployment_name>
     ...

   Copy code to clipboard

   where:

   <deployment_name>

   One of the following deployments:

   • devspaces
   • che-gateway
   • devspaces-dashboard
   • plugin-registry

   • devfile-registry

     For example:

     apiVersion: autoscaling/v2
     kind: HorizontalPodAutoscaler
     metadata:
       name: devspaces-scaler
       namespace: openshift-devspaces
     spec:
       scaleTargetRef:
         apiVersion: apps/v1
         kind: Deployment
         name: devspaces
       minReplicas: 2
       maxReplicas: 5
       metrics:
         - type: Resource
           resource:
             name: cpu
             target:
               type: Utilization
               averageUtilization: 75

     Copy code to clipboard

     In this example, the HPA targets the devspaces deployment with a minimum of 2 replicas, a maximum of 5 replicas, and scales based on CPU utilization.

Procedure

1. Set the startup timeout and event handling in the CheCluster Custom Resource to handle autoscaler node additions:

   spec:
     devEnvironments:
       startTimeoutSeconds: 600
       ignoredUnrecoverableEvents:
         - FailedScheduling

   Copy code to clipboard

   where:

   startTimeoutSeconds

   Set to at least 600 seconds to allow time for a new node to be provisioned during workspace startup.

   ignoredUnrecoverableEvents

   Ignore the FailedScheduling event to allow workspace startup to continue when a new node is provisioned. This setting is enabled by default.

2. Add the safe-to-evict annotation to the CheCluster Custom Resource to prevent workspace pod eviction when the autoscaler removes a node:

   spec:
     devEnvironments:
       workspacesPodAnnotations:
         cluster-autoscaler.kubernetes.io/safe-to-evict: "false"

   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 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. Configure OpenShift Dev Spaces operand to use self-signed certificates for Git repositories. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   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: Section 10.2, “Configure storage classes”.

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. Gather a list of relevant container images to pull. See Section 7.7, “Retrieve the default list of images for Kubernetes Image Puller”.

2. Define the memory requests and limits parameters to ensure pulled containers and the platform have enough memory to run.

   When defining the minimal value for CACHING_MEMORY_REQUEST or CACHING_MEMORY_LIMIT, consider the necessary amount of memory required to run each of the container images to pull.

   When defining the maximal value for CACHING_MEMORY_REQUEST or CACHING_MEMORY_LIMIT, consider the total memory allocated to the DaemonSet Pods in the cluster:

   (memory limit) * (number of images) * (number of nodes in the cluster)

   Copy code to clipboard

   Pulling 5 images on 20 nodes, with a container memory limit of 20Mi requires 2000Mi of memory.

3. Clone the Image Puller repository and get in the directory containing the OpenShift templates:

   git clone https://github.com/che-incubator/kubernetes-image-puller
   cd kubernetes-image-puller/deploy/openshift

   Copy code to clipboard

4. Configure the app.yaml, configmap.yaml, and serviceaccount.yaml OpenShift templates using the following parameters:

   Table 7.1. Image Puller OpenShift templates parameters in app.yaml

   Value	Usage	Default
   DEPLOYMENT_NAME	The value of DEPLOYMENT_NAME in the ConfigMap	kubernetes-image-puller
   IMAGE	Image used for the kubernetes-image-puller deployment	registry.redhat.io/devspaces/imagepuller-rhel8
   IMAGE_TAG	The image tag to pull	latest
   SERVICEACCOUNT_NAME	The name of the ServiceAccount created and used by the deployment	kubernetes-image-puller

   Table 7.2. Image Puller OpenShift templates parameters in configmap.yaml

   Value	Usage	Default
   CACHING_CPU_LIMIT	The value of CACHING_CPU_LIMIT in the ConfigMap	.2
   CACHING_CPU_REQUEST	The value of CACHING_CPU_REQUEST in the ConfigMap	.05
   CACHING_INTERVAL_HOURS	The value of CACHING_INTERVAL_HOURS in the ConfigMap	"1"
   CACHING_MEMORY_LIMIT	The value of CACHING_MEMORY_LIMIT in the ConfigMap	"20Mi"
   CACHING_MEMORY_REQUEST	The value of CACHING_MEMORY_REQUEST in the ConfigMap	"10Mi"
   DAEMONSET_NAME	The value of DAEMONSET_NAME in the ConfigMap	kubernetes-image-puller
   DEPLOYMENT_NAME	The value of DEPLOYMENT_NAME in the ConfigMap	kubernetes-image-puller
   IMAGES	The value of IMAGES in the ConfigMap	{}
   NAMESPACE	The value of NAMESPACE in the ConfigMap	k8s-image-puller
   NODE_SELECTOR	The value of NODE_SELECTOR in the ConfigMap	"{}"

   Table 7.3. Image Puller OpenShift templates parameters in serviceaccount.yaml

   Value	Usage	Default
   SERVICEACCOUNT_NAME	The name of the ServiceAccount created and used by the deployment	kubernetes-image-puller
   KIP_IMAGE	The image puller image to copy the sleep binary from	registry.redhat.io/devspaces/imagepuller-rhel8:latest

5. Create an OpenShift project to host the Image Puller:

   oc new-project <k8s-image-puller>

   Copy code to clipboard

6. Process and apply the templates to install the puller:

   oc process -f serviceaccount.yaml | oc apply -f -
   oc process -f configmap.yaml | oc apply -f -
   oc process -f app.yaml | oc apply -f -

   Copy code to clipboard

Verification

1. Verify the existence of a <kubernetes-image-puller> deployment and a <kubernetes-image-puller> DaemonSet. The DaemonSet needs to have a Pod for each node in the cluster:

   oc get deployment,daemonset,pod --namespace <k8s-image-puller>

   Copy code to clipboard

2. Verify the values of the <kubernetes-image-puller> ConfigMap.

   oc get configmap <kubernetes-image-puller> --output yaml

   Copy code to clipboard

Procedure

1. Install the Kubernetes Image Puller Operator. See This page is not included, but the link has been rewritten to point to the nearest parent document.Installing from OperatorHub using the web console.
2. Create a KubernetesImagePuller operand from the Kubernetes Image Puller Operator. See Creating applications from installed Operators.

Procedure

1. Configure the Image Puller to pre-pull OpenShift Dev Spaces images.

   oc patch checluster/devspaces \
       --namespace openshift-devspaces \
       --type='merge' \
       --patch '{
                 "spec": {
                   "components": {
                     "imagePuller": {
                       "enable": true
                     }
                   }
                 }
               }'

   Copy code to clipboard

Procedure

1. Configure the Image Puller to pre-pull custom images.

   oc patch checluster/devspaces \
       --namespace openshift-devspaces \
       --type='merge' \
       --patch '{
                 "spec": {
                   "components": {
                     "imagePuller": {
                       "enable": true,
                       "spec": {
                         "images": "NAME-1=IMAGE-1;NAME-2=IMAGE-2"
                       }
                     }
                   }
                 }
               }'

   Copy code to clipboard

   where:

   images

   The semicolon-separated list of images in name=image format.

Procedure

1. Create k8s-image-puller namespace:

   oc create namespace k8s-image-puller

   Copy code to clipboard

2. Create KubernetesImagePuller Custom Resource:

   oc apply -f - <<EOF
   apiVersion: che.eclipse.org/v1alpha1
   kind: KubernetesImagePuller
   metadata:
     name: k8s-image-puller-images
     namespace: k8s-image-puller
   spec:
     images: "NAME-1=IMAGE-1;NAME-2=IMAGE-2"
   EOF

   Copy code to clipboard

   where:

   images

   The semicolon-separated list of images in name=image format.

Procedure

1. Determine the namespace where the OpenShift Dev Spaces Operator is deployed:

   OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)

   Copy code to clipboard

2. Determine the images that can be pre-pulled by the Image Puller:

   oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt

   Copy code to clipboard

Procedure

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

2. Configure the CheCluster Custom Resource. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   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. Create the ServiceMonitor for detecting the Dev Workspace Operator metrics Service:

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: devworkspace-controller
     namespace: openshift-devspaces
   spec:
     endpoints:
       - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
         interval: 10s
         port: metrics
         scheme: https
         tlsConfig:
           insecureSkipVerify: true
     namespaceSelector:
       matchNames:
         - openshift-operators
     selector:
       matchLabels:
         app.kubernetes.io/name: devworkspace-controller

   Copy code to clipboard

   where:

   namespace

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

   interval

   The rate at which a target is scraped.

2. Allow the in-cluster Prometheus instance to detect the ServiceMonitor by labeling the OpenShift Dev Spaces namespace:

   $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true

   Copy code to clipboard

Verification

1. For a fresh installation of OpenShift Dev Spaces, generate metrics by creating an 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. The query returns data points showing the total number of started workspaces.

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. Configure the CheCluster Custom Resource. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   spec:
     components:
       metrics:
         enable: <boolean>

   Copy code to clipboard

   where:

   <boolean>

   true to enable, false to disable.

Procedure

1. Create the ServiceMonitor for detecting the OpenShift Dev Spaces JVM metrics Service:

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: che-host
     namespace: openshift-devspaces
   spec:
     endpoints:
       - interval: 10s
         port: metrics
         scheme: http
     namespaceSelector:
       matchNames:
         - openshift-devspaces
     selector:
       matchLabels:
         app.kubernetes.io/name: devspaces

   Copy code to clipboard

   where:

   namespace

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

   interval

   The rate at which a target is scraped.

2. Create a Role to allow Prometheus to view the metrics:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: prometheus-k8s
     namespace: openshift-devspaces
   rules:
     - verbs:
         - get
         - list
         - watch
       apiGroups:
         - ''
       resources:
         - services
         - endpoints
         - pods

   Copy code to clipboard

   where:

   namespace

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

3. Create a RoleBinding to bind the Role to the Prometheus service account:

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: view-devspaces-openshift-monitoring-prometheus-k8s
     namespace: openshift-devspaces
   subjects:
     - kind: ServiceAccount
       name: prometheus-k8s
       namespace: openshift-monitoring
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: prometheus-k8s

   Copy code to clipboard

   where:

   namespace

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

4. Allow the in-cluster Prometheus instance to detect the ServiceMonitor by labeling the OpenShift Dev Spaces namespace:

   $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true

   Copy code to clipboard

Verification

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. The query returns data points showing the OpenShift Dev Spaces Server uptime.

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 8.3. Quick Facts

   

   Figure 8.4. JVM Memory

   

   Figure 8.5. JVM Misc

   

   Figure 8.6. JVM Memory Pools (heap)

   

   Figure 8.7. JVM Memory Pools (Non-Heap)

   

   Figure 8.8. Garbage Collection

   

   Figure 8.9. Class loading

   

   Figure 8.10. Buffer Pools

   

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. Configure the CheCluster Custom Resource. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   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_DOMAINSUFFIX: "<base_domain>__"

   Copy code to clipboard

   where:

   <base_domain>

   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 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 Configuring the CheCluster Custom Resource during installation.
   • You can update this field on the command line. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

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 Configuring the CheCluster Custom Resource during installation.
   2. You can update this field on the command line. See Section 2.2, “Use the CLI to configure the CheCluster Custom Resource”.

   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.

1. Creating symbolic links is faster and consumes less storage than creating copies of the /home/user directory content in the persistent volume. The persistent volume contains symbolic links, not the actual files.
2. If the tools image is updated with newer versions of existing binaries, configs, and files, the init container does not need to rerun stow. The existing symbolic links already point to the newer versions in /home/tooling.

Procedure

1. Create a JSON file with the samples configuration. The file must contain an array of objects, where each object represents a sample.

   cat > my-samples.json <<EOF
   [
     {
       "displayName": "<display_name>",
       "description": "<description>",
       "tags": <tags>,
       "url": "<url>",
       "icon": {
         "base64data": "<base64data>",
         "mediatype": "<mediatype>"
       }
     }
   ]
   EOF

   Copy code to clipboard

   where:

   displayName

   The display name of the sample.

   description

   The description of the sample.

   tags

   The JSON array of tags, for example, ["java", "spring"].

   url

   The URL to the repository containing the devfile.

   base64data

   The base64-encoded data of the icon.

   mediatype

   The media type of the icon. For example, image/png.

2. Create a ConfigMap with the samples configuration:

   oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces

   Copy code to clipboard

3. Add the required labels to the ConfigMap:

   oc label configmap getting-started-samples app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=getting-started-samples -n openshift-devspaces

   Copy code to clipboard