Procedure

1. Download the archive from This content is not included.https://developers.redhat.com/products/openshift-dev-spaces/download to a directory such as $HOME.
2. Run tar xvzf on the archive to extract the /dsc directory.
3. Add the extracted /dsc/bin subdirectory to $PATH.

Procedure

1. Identify the workspace resource requirements from the devfile components section. The following example uses the Content from github.com is not included.Quarkus API example devfile.

   • The tools component of the devfile defines the following requests and limits:

         memoryLimit: 6G
         memoryRequest: 512M
         cpuRequest: 1000m
         cpuLimit: 4000m

     Copy code to clipboard

   • During workspace startup, an internal che-gateway container is implicitly provisioned with the following requests and limits:

         memoryLimit: 256M
         memoryRequest: 64M
         cpuRequest: 50m
         cpuLimit: 500m

     Copy code to clipboard

   • Additional memory and CPU are added implicitly for the Visual Studio Code - Open Source ("Code - OSS") editor:

         memoryLimit: 1024M
         memoryRequest: 256M
         cpuRequest: 30m
         cpuLimit: 500m

     Copy code to clipboard

   • Additional memory and CPU are added implicitly for a JetBrains IDE, for example IntelliJ IDEA Ultimate:

         memoryLimit: 6144M
         memoryRequest: 2048M
         cpuRequest: 1500m
         cpuLimit: 2000m

     Copy code to clipboard

2. Calculate the sums of the resources required for each workspace. If you intend to use multiple devfiles, repeat this calculation for every expected devfile.

   Table 2.2. Workspace requirements for the Content from github.com is not included.example devfile in the previous step

   Purpose	Pod	Container name	Memory limit	Memory request	CPU limit	CPU request
   Developer tools	workspace	tools	6 GiB	512 MiB	4000 m	1000 m
   OpenShift Dev Spaces gateway	workspace	che-gateway	256 MiB	64 MiB	500 m	50 m
   Visual Studio Code	workspace	tools	1024 MiB	256 MiB	500 m	30 m
   Total			7.3 GiB	832 MiB	5000 m	1080 m

3. Multiply the resources calculated per workspace by the number of workspaces that you expect all of your users to run simultaneously.

4. Calculate the sums of the requirements for the OpenShift Dev Spaces Operator, Operands, and Dev Workspace Controller.

   Table 2.3. Default requirements for the OpenShift Dev Spaces Operator, Operands, and Dev Workspace Controller

   Purpose	Pod name	Container names	Memory limit	Memory request	CPU limit	CPU request
   OpenShift Dev Spaces operator	devspaces-operator	devspaces-operator	256 MiB	64 MiB	500 m	100 m
   OpenShift Dev Spaces Server	devspaces	devspaces-server	1 GiB	512 MiB	1000 m	100 m
   OpenShift Dev Spaces Dashboard	devspaces-dashboard	devspaces-dashboard	256 MiB	32 MiB	500 m	100 m
   OpenShift Dev Spaces Gateway	devspaces-gateway	traefik	4 GiB	128 MiB	1000 m	100 m
   OpenShift Dev Spaces Gateway	devspaces-gateway	configbump	256 MiB	64 MiB	500 m	50 m
   OpenShift Dev Spaces Gateway	devspaces-gateway	oauth-proxy	512 MiB	64 MiB	500 m	100 m
   OpenShift Dev Spaces Gateway	devspaces-gateway	kube-rbac-proxy	512 MiB	64 MiB	500 m	100 m
   Plugin registry	plugin-registry	plugin-registry	256 MiB	32 MiB	500 m	100 m
   Dev Workspace Controller Manager	devworkspace-controller-manager	devworkspace-controller	5 GiB	100 MiB	3000 m	250 m
   Dev Workspace Controller Manager	devworkspace-controller-manager	kube-rbac-proxy	N/A	N/A	N/A	N/A
   Dev Workspace Operator Catalog	devworkspace-operator-catalog	registry-server	N/A	50 MiB	N/A	10 m
   Dev Workspace Webhook Server	devworkspace-webhook-server	webhook-server	300 MiB	20 MiB	200 m	100 m
   Dev Workspace Webhook Server	devworkspace-webhook-server	kube-rbac-proxy	N/A	N/A	N/A	N/A
   Total			12.3 GiB	1.1 GiB	8.2	1.1

5. Add the workspace resources from step 3 and the operator resources from step 4 to determine total cluster resource requirements.

1. Authenticate by using OAuth through a proxy sidecar.
2. Pass identity and group information through HTTP headers.
3. Verify group memberships by using OpenShift Container Platform API queries.
4. Determine the appropriate Red Hat OpenShift Dev Spaces URL by using a mapping lookup.
5. Redirect the user to the designated cluster instance.

Procedure

1. Optional: If you previously deployed OpenShift Dev Spaces on this OpenShift cluster, ensure that the previous OpenShift Dev Spaces instance is removed:

   $ dsc server:delete

   Copy code to clipboard

2. Create the OpenShift Dev Spaces instance:

   $ dsc server:deploy --platform openshift

   Copy code to clipboard

Verification

1. Verify the OpenShift Dev Spaces instance status:

   $ dsc server:status

   Copy code to clipboard

2. Navigate to the OpenShift Dev Spaces cluster instance:

   $ dsc dashboard:open

   Copy code to clipboard

Procedure

1. In the Administrator view of the OpenShift web console, go to Operators → OperatorHub and search for Red Hat OpenShift Dev Spaces.

2. Install the Red Hat OpenShift Dev Spaces Operator.

   Tip

   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.

   Important

   The Red Hat OpenShift Dev Spaces Operator depends on the Dev Workspace Operator. If you install the Red Hat OpenShift Dev Spaces Operator manually to a non-default namespace, ensure that the Dev Workspace Operator is also installed in the same namespace. The Operator Lifecycle Manager installs the Dev Workspace Operator as a dependency within the Red Hat OpenShift Dev Spaces Operator namespace. If the Dev Workspace Operator is already installed in a different namespace, two conflicting installations can result.

   Important

   If you want to onboard This page is not included, but the link has been rewritten to point to the nearest parent document.Web Terminal Operator on the cluster, use the same installation namespace as the Red Hat OpenShift Dev Spaces Operator. Both operators depend on the Dev Workspace Operator, so all three must be installed in the same namespace.

3. Create the openshift-devspaces project in OpenShift as follows:

   oc create namespace openshift-devspaces

   Copy code to clipboard
4. Go to Operators → Installed Operators → Red Hat OpenShift Dev Spaces instance Specification → Create CheCluster → YAML view.
5. In the YAML view, replace namespace: openshift-operators with namespace: openshift-devspaces.

6. Select Create.

   Tip

   See This page is not included, but the link has been rewritten to point to the nearest parent document.Creating applications from installed Operators.

1. In Red Hat OpenShift Dev Spaces instance Specification, go to devspaces, landing on the Details tab.

1. Under Message, check that there is None, which means no errors.
2. Under Red Hat OpenShift Dev Spaces URL, wait until the URL of the OpenShift Dev Spaces instance appears, and then open the URL to check the OpenShift Dev Spaces dashboard.
3. In the Resources tab, view the resources for the OpenShift Dev Spaces deployment and their status.

Procedure

1. Download and execute the mirroring script to install a custom Operator catalog and mirror the related images.

   $ bash prepare-restricted-environment.sh \
     --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.22\
     --devworkspace_operator_version "v0.40.0" \
     --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.22" \
     --prod_operator_package_name "devspaces" \
     --prod_operator_bundle_name "devspacesoperator" \
     --prod_operator_version "v3.27.0" \
     --my_registry "<my_registry>"

   Copy code to clipboard

   --my_registry

   The private Docker registry where the images will be mirrored

Procedure

1. Install OpenShift Dev Spaces with the configuration set in the che-operator-cr-patch.yaml during the previous step:

   $ dsc server:deploy \
     --platform=openshift \
     --olm-channel stable \
     --catalog-source-name=devspaces-disconnected-install \
     --catalog-source-namespace=openshift-marketplace \
     --skip-devworkspace-operator \
     --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml

   Copy code to clipboard
2. Allow incoming traffic from the OpenShift Dev Spaces namespace to all Pods in the user projects. See: Section 12.1, “Configure network policies”.

Procedure

1. Mirror the following images:

   ghcr.io/ansible/ansible-devspaces@sha256:ce1ecc3b3c350eab2a9a417ce14a33f4b222a6aafd663b5cf997ccc8c601fe2c
   registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb

   Copy code to clipboard

2. Configure the cluster proxy to allow access to the following domains:

   .ansible.com
   .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com

   Copy code to clipboard
   Note

   Support for the following IDE and CPU architectures is planned for a future release:

   • CPU architectures

     • IBM Power (ppc64le)
     • IBM Z (s390x)

Procedure

1. Run the following command:

   oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'

   Copy code to clipboard

Procedure

1. Create a che-operator-cr-patch.yaml YAML file that contains the subset of the CheCluster Custom Resource to configure:

   spec:
     <component>:
         <property_to_configure>: <value>

   Copy code to clipboard

2. Deploy OpenShift Dev Spaces and apply the changes described in che-operator-cr-patch.yaml file:

   $ dsc server:deploy \
   --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \
   --platform <chosen_platform>

   Copy code to clipboard

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 5.3, “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 6.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 5.3, “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 13.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 10.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 10.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 10.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 10.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 This page is not included, but the link has been rewritten to point to the nearest parent document.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 5.3, “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.