Chapter 3. Configure projects


Configure projects for OpenShift Dev Spaces workspaces, including namespace templates, pre-provisioning, and resource synchronization.

3.1. Project configuration

OpenShift Dev Spaces isolates workspaces for each user in a project, identified by labels and annotations. If the project does not exist, OpenShift Dev Spaces creates it from a template.

You can modify OpenShift Dev Spaces behavior by configuring the project name, provisioning projects in advance, or configuring a user project.

3.2. Configure project name

Configure the project name template that OpenShift Dev Spaces uses when creating workspace projects to enforce naming conventions and organizational compliance.

A valid project name template follows these conventions:

  • The <username> or <userid> placeholder is mandatory.
  • Usernames and IDs cannot contain invalid characters. If a username or ID is incompatible with OpenShift naming conventions, OpenShift Dev Spaces replaces incompatible characters with the - symbol.
  • OpenShift Dev Spaces evaluates the <userid> placeholder into a 14 character long string, and adds a random six character long suffix to prevent IDs from colliding. The result is stored in the user preferences for reuse.
  • Kubernetes limits the length of a project name to 63 characters.
  • OpenShift limits the length further to 49 characters.

Prerequisites

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>

    where:

    <workspace_namespace_template>

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

    Expand
    Table 3.1. User workspaces project name template examples
    User workspaces project name templateResulting project example

    <username>-devspaces (default)

    user1-devspaces

    <userid>-namespace

    cge1egvsb2nhba-namespace-ul1411

    <userid>-aka-<username>-namespace

    cgezegvsb2nhba-aka-user1-namespace-6m2w2b

Verification

  • Start a workspace and verify that the workspace project name matches the configured template:

    {orch-cli} get devworkspaces -A -o jsonpath='\{range .items[*]}\{.metadata.namespace}\{"\n"}{end}'

3.3. Provision projects in advance

Provision workspace projects in advance, rather than relying on automatic provisioning, to control namespace naming and apply custom resource quotas. Repeat the procedure for each user.

Prerequisites

Procedure

  1. Disable automatic namespace provisioning on the CheCluster level:

    devEnvironments:
      defaultNamespace:
        autoProvision: false
  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>

    where:

    <project_name>
    A project name of your choosing.
    <username>
    The username of the OpenShift Dev Spaces user.

Verification

  • Verify that the project was created with the correct labels:

    $ oc get namespace <project_name> --show-labels

3.4. Configure a user namespace

Synchronize ConfigMaps, Secrets, PersistentVolumeClaims, and other Kubernetes objects from the openshift-devspaces namespace to user-specific namespaces to provide consistent workspace configurations.

If you make changes to a Kubernetes resource in the openshift-devspaces namespace, OpenShift Dev Spaces immediately synchronizes the changes across all user namespaces. In reverse, if a Kubernetes resource is modified in a user namespace, OpenShift Dev Spaces immediately reverts the changes.

Prerequisites

Warning

Applying or modifying a Secret or ConfigMap with the controller.devfile.io/mount-to-devworkspace: 'true' label restarts all running workspaces in the project. Ensure that users save their work before you apply these changes.

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

    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>

    The ConfigMap propagates the SSH configuration as an extension by using Include /etc/ssh/ssh_config.d/*.conf. For details, see Include definition.

    For other labels and annotations, see the 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"
  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"
  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:
        ...

    See the 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"
  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"
  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:
      ...

    See the 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"
  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

      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
      Note

      Creating Template Kubernetes resources is supported only on OpenShift.

Verification

  • Verify that the Kubernetes objects are synchronized to a user project:

    $ oc get configmaps,secrets -n <user_namespace> -l app.kubernetes.io/part-of=che.eclipse.org

Configure OpenShift Dev Spaces to create standard Kubernetes namespaces directly on OpenShift Container Platform instead of using the ProjectRequest API to bypass cluster-specific Project Templates.

By default, on OpenShift Container Platform clusters, OpenShift Dev Spaces uses the ProjectRequest API to create projects. This triggers cluster-specific Project Templates, which can apply additional resources or policies.

On OpenShift Container Platform, you can bypass Project Templates and create standard Kubernetes namespaces directly. For example, this is useful when Project Templates introduce unwanted side effects.

Prerequisites

  • You have an active oc session with administrative permissions to the destination OpenShift cluster.

Procedure

  • Set the createKubernetesNamespaces field to true:

    oc patch checluster devspaces \
      --namespace openshift-devspaces \
      --type merge \
      --patch '{
        "spec": {
          "devEnvironments": {
            "defaultNamespace": {
              "createKubernetesNamespaces": true
            }
          }
        }
      }'
    Note

    This setting applies only to OpenShift Container Platform clusters. On Kubernetes clusters, namespaces are always created directly regardless of this setting.

Verification

  • Verify the configuration:

    oc get checluster devspaces \
      --namespace openshift-devspaces \
      --output jsonpath='{.spec.devEnvironments.defaultNamespace.createKubernetesNamespaces}'

    The command returns true.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

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

Making open source more inclusive

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

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top