The following section describes advanced deployment and configuration methods for Eclipse Che.

Che configMaps and their behavior

The following section describes Che configMaps and how they behave.

A configMap is provided as an editable file that lists options to customize the Che environment. Based on the Che installation method, configMaps can be used to customize the working environment. The type of configMaps available in your Che environment varies based on the method used for installing Che.

Che installed using an Operator

Operators are software extensions to Kubernetes that use custom resources to manage applications and their components.

Che installed using the Operator provides the user with an automatically generated configMap called che.

The che configMap contains the main properties for the Che server, and is in sync with the information stored in the CheCluster Custom Resource file. User modifications of the che configMap after installing Che using the Operator are automatically overwritten by values that the Operator obtains from the CheCluster Custom Resource.

To edit the che configMap, edit the Custom Resource manually. The configMap derives values from the CheCluster field. User modifications of the CheCluster Custom Resource field cause the Operator to change the attributes of the che configMap accordingly. The configMap changes automatically trigger a restart of the Che Pod.

To add custom properties to the Che server, such as environment variables that are not automatically generated in the che configMap by the Operator, or to override automatically generated properties, the CheCluster Custom Resource has a customCheProperties field, which expects a map.

For example, to override the default memory limit for workspaces, add the CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB property to customCheProperties:

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: che
spec:
  server:
    cheImageTag: ''
    devfileRegistryImage: ''
    pluginRegistryImage: ''
    tlsSupport: false
    selfSignedCert: false
    customCheProperties:
      CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB: "2048"
  auth:
...

Previous versions of the Che Operator had a configMap named custom to fulfill this role. If the Che Operator finds a configMap with the name custom, it adds the data it contains into the customCheProperties field, redeploys Che, and deletes the custom configMap.

Che installed using a Helm Chart

A Helm Chart is a Kubernetes extension for defining, installing, and upgrading Kubernetes applications.

When Che is installed using a Helm Chart, the user configures Che manually by modifying the configMap object. The configMap object is called che and is generated as an editable template after the installation. To apply manual changes to the custom configMap, delete the Che pod to manually restart it. Alternatively, use the following kubectl command:

$ kubectl rollout restart deployment/che

This avoids the downtime associated with deleting a Pod because it deploys and starts a new Pod, and only then deletes the old Pod.

Configuring namespace strategies

The term namespace (Kubernetes) is used interchangeably with project (OpenShift).

The namespace strategies are configured using the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT environment variable.

There are legacy variables CHE_INFRA_KUBERNETES_NAMESPACE and CHE_INFRA_OPENSHIFT_PROJECT. These should be left unset for new installations. Changing these variables during update can lead to data loss.

One namespace per workspace strategy

The strategy creates a new namespace for each new workspace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain the <workspaceid> identifier. It can be used alone or combined with other identifiers or any string.

Example 1. One namespace per workspace

To assign namespace names composed of a che-ws prefix and workspace id, set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<workspaceid>

One namespace for all workspaces strategy

The strategy uses one predefined namespace for all workspaces.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must be the name of the desired namespace to use.

Example 2. One namespace for all workspaces

To have all workspaces created in che-workspaces namespace, set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-workspaces
To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

One namespace per user strategy

The strategy isolates each user in their own namespace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain one or more user identifiers. Currently supported identifiers are <username> and <userid>.

Example 3. One namespace per user

To assign namespace names composed of a che-ws prefix and individual usernames (che-ws-user1, che-ws-user2), set:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<username>

To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

To limit the number of concurrently running workspaces per user to one, set the CHE_LIMITS_USER_WORKSPACES_RUN_COUNT environment variable to 1.

To limit the number of concurrently running workspaces per user to one (1):

  • For Helm Chart deployments: set the .global.workspace.number parameter to 1.

  • For Operator deployments: set the spec.server.cheCustomProperties.CHE_LIMITS_USER_WORKSPACE_RUN_COUNT variable of the CheCluster Custom Resource (CR) to 1.

Allowing user-defined workspace namespaces

Che server can be configured to honor the user selection of a namespace when a workspace is created. This feature is disabled by default. To allow user-defined workspace namespaces, set:

CHE_INFRA_KUBERNETES_NAMESPACE_ALLOWUSERDEFINED=true

Deploying Che with support for Git repositories with self-signed certificates

This procedure describes how to configure Che for deployment with support for Git operations on repositories that use self-signed certificates.

Prerequisites

  • Git version 2 or later

  • Helm version 2.15 or higher

Configuring support for self-signed Git repositories on Kubernetes

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

    $ kubectl create configmap che-git-self-signed-cert --from-file=ca.crt \
  --from-literal=githost=<host:port> -n=che

    In the command, substitute <host:port> for the host and port of the HTTPS connection on the Git server (optional).

    When githost is not specified, the given certificate is used for all HTTPS repositories.
    The certificate file must be named ca.crt.

  2. Configure the workspace exposure strategy

    If Che is deployed using a Helm Chart

    1. Clone the che project

    2. Go to deploy/kubernetes/helm/che directory

    3. Update the global.useGitSelfSignedCerts property. To do that, add the following option to the helm upgrade command:

      $ helm upgrade che -n che --set global.useGitSelfSignedCerts=true --set global.ingressDomain=<kubernetes-cluster-domain> .

      <kubernetes-cluster-domain> On Minikube, use $(minikube ip).nip.io

    If Che is deployed using Operators

    Update the gitSelfSignedCert property. To do that, execute:

    $ kubectl patch checluster eclipse-che -n che --type=json -p '[{"op": "replace", "path": "/spec/server/gitSelfSignedCert", "value": true}]'

  3. Create and start new workspace. Every container used by the workspace mounts a special volume that contains a file with the self-signed certificate. The repository’s .git/config file contains information about the Git server host (its URL) and the path to the certificate in the http section (see Git documentation about git-config). For example:

    [http "https://10.33.177.118:3000"]
        sslCAInfo = /etc/che/git/cert/ca.crt

Installing Che using storage classes

To configure Che to use a configured infrastructure storage, install Che using storage classes. This is especially useful when a user wants to bind a persistent volume provided by a non-default provisioner. To do so, a user binds this storage for the Che data saving and sets the parameters for that storage. These parameters can determine the following:

  • A special host path

  • A storage capacity

  • A volume mod

  • Mount options

  • A file system

  • An access mode

  • A storage type

  • And many others

Che has two components that require persistent volumes to store data:

  • A PostgreSQL database.

  • A Che workspaces. Che workspaces store source code using volumes, for example /projects volume.

Che workspaces source code is stored in the persistent volume only if a workspace is not ephemeral.
Persistent volume claims facts:

  • Che does not create persistent volumes in the infrastructure.

  • Che uses persistent volume claims (PVC) to mount persistent volumes.

  • The Che server creates persistent volume claims.

    A user defines a storage class name in the Che configuration to use the storage classes feature in the Che PVC. With storage classes, a user configures infrastructure storage in a flexible way with additional storage parameters. It is also possible to bind a static provisioned persistent volumes to the Che PVC using the class name.

Procedure

Use CheCluster custom resource definition to define storage classes:

  1. Define storage class names

    To do so, use one of the following methods:

    • Use arguments for the server:start command

      1. Provide the storage class name for the PostgreSQL PVC

        Use the chectl server:start command with the --postgres-pvc-storage-class-name flag:

        $ chectl server:start -m -p minikube -a operator --postgres-pvc-storage-class-name=postgress-storage

      2. Provide the storage class name for the Che workspaces

        Use the server:start command with the --workspace-pvc-storage-class-name flag:

        $ chectl server:start -m -p minikube -a operator --workspace-pvc-storage-class-name=workspace-storage

        For Che workspaces, the storage class name has different behavior depending on the workspace PVC strategy.

        postgres-pvc-storage-class-name=postgress-storage and workspace-pvc-storage-class-name work for the Operator installer and the Helm installer.

    • Define storage class names using a custom resources YAML file:

      1. Create a YAML file with custom resources defined for the Che installation.

      2. Define fields: spec#storage#postgresPVCStorageClassName and spec#storage#workspacePVCStorageClassName.

        apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
spec:
  # ...
  storage:
    # ...
    # keep blank unless you need to use a non default storage class for PostgreSQL PVC
    postgresPVCStorageClassName: 'postgres-storage'
    # ...
    # keep blank unless you need to use a non default storage class for workspace PVC(s)
    workspacePVCStorageClassName: 'workspace-storage'
    # ...

      3. Start the che server with your custom resources:

        $ chectl server:start -m -p minikube -a operator --che-operator-cr-yaml=/path/to/custom/che/resource/org_v1_che_cr.yaml

  2. Configure Che to store workspaces in one persistent volume and postrges in the second one:

    1. Modify your custom resources YAML file:

      • Set pvcStrategy as common.

      • Configure Che to start workspaces in a single namespace.

      • Define storage class names for postgresPVCStorageClassName and workspacePVCStorageClassName.

      • Example of the YAML file:

        apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
spec:
  server:
    # ...
    workspaceNamespaceDefault: 'che'
    # ...
  storage:
    # ...
    # Defaults to common
    pvcStrategy: 'common'
    # ...
    # keep blank unless you need to use a non default storage class for PostgreSQL PVC
    postgresPVCStorageClassName: 'postgres-storage'
    # ...
    # keep blank unless you need to use a non default storage class for workspace PVC(s)
    workspacePVCStorageClassName: 'workspace-storage'
    # ...

    2. Start the che server with your custom resources:

      $ chectl server:start -m -p minikube -a operator --che-operator-cr-yaml=/path/to/custom/che/resource/org_v1_che_cr.yaml

  3. Bind static provisioned volumes using class names:

    1. Define the persistent volume for a PostgreSQL database:

      # che-postgres-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv-volume
  labels:
    type: local
spec:
  storageClassName: postgres-storage
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data/che/postgres"

    2. Define the persistent volume for a Che workspace:

      # che-workspace-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: workspace-pv-volume
  labels:
    type: local
spec:
  storageClassName: workspace-storage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data/che/workspace"

    3. Bind the two persistent volumes:

$ kubectl apply -f che-workspace-pv.yaml -f che-postgres-pv.yaml

You must provide valid file permissions for volumes. You can do it using storage class configuration or manually. To manually define permissions, define storageClass#mountOptions uid and gid. PostgreSQL volume requires uid=26 and gid=26.

Adding custom public SSL certificates to Che trust-store

This procedure describes how to configure Che to be able to perform HTTP requests to unrecognized resources.

Procedure

  1. Save the public certificate(s) that you want to apply.

  2. Create a new configMap with the certificate(s):

    $ kubectl create configmap <config-map name> --from-file=<certificate file path> -n=che

    To apply more then one certificate, add --from-file=<certificate file path> key to the command.

  3. Define the certificates config-map name.

    If Che is deployed using a Helm Chart

    1. Clone the che project

    2. Go to deploy/kubernetes/helm/che directory

    3. Set the global.tls.serverTrustStoreConfigMapName property to previously created config-map name. To do that, add the following option to the helm upgrade command:

      $ helm upgrade che -n che --set global.tls.serverTrustStoreConfigMapName=<config-map name> --set global.ingressDomain=<kubernetes-cluster-domain> .

      <kubernetes-cluster-domain> On Minikube, use $(minikube ip).nip.io

    If Che is deployed using Operators

    Set the serverTrustStoreConfigMapName property to previously created config-map name. To do that, execute:

    $ kubectl patch checluster eclipse-che -n che --type=json -p '[{"op": "replace", "path": "/spec/server/serverTrustStoreConfigMapName", "value": "<config-map name>"}]'

Che configMaps fields reference

Property Default value Description

airGapContainerRegistryHostname

omit

An optional host name or URL to an alternate container registry to pull images from. This value overrides the container registry host name defined in all default container images involved in a Che deployment. This is particularly useful to install Che in an air-gapped environment.

airGapContainerRegistryOrganization

omit

Optional repository name of an alternate container registry to pull images from. This value overrides the container registry organization defined in all the default container images involved in a Che deployment. This is particularly useful to install Che in an air-gapped environment.

cheDebug

false

Enables the debug mode for Che server.

cheFlavor

che

Flavor of the installation.

cheHost

The Operator automatically sets the value.

A public host name of the installed Che server.

cheImagePullPolicy

Always for nightly or latest images, and IfNotPresent in other cases

Overrides the image pull policy used in Che deployment.

cheImageTag

omit

Overrides the tag of the container image used in Che deployment. Omit it or leave it empty to use the default image tag provided by the Operator.

cheImage

omit

Overrides the container image used in Che deployment. This does not include the container image tag. Omit it or leave it empty to use the default container image provided by the Operator.

cheLogLevel

INFO

Log level for the Che server: INFO or DEBUG.

cheWorkspaceClusterRole

omit

Custom cluster role bound to the user for the Che workspaces. Omit or leave empty to use the default roles.

customCheProperties

omit

Map of additional environment variables that will be applied in the generated che config map to be used by the Che server, in addition to the values already generated from other fields of the CheCluster custom resource (CR). If customCheProperties contains a property that would be normally generated in che config map from other CR fields, then the value defined in the customCheProperties will be used instead.

devfileRegistryImage

omit

Overrides the container image used in the Devfile registry deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.

devfileRegistryMemoryLimit

256Mi

Overrides the memory limit used in the Devfile registry deployment.

devfileRegistryMemoryRequest

16Mi

Overrides the memory request used in the Devfile registry deployment.

devfileRegistryPullPolicy

Always for nightly or latest images, and IfNotPresent in other cases

Overrides the image pull policy used in the Devfile registry deployment.

devfileRegistryUrl

The Operator automatically sets the value.

Public URL of the Devfile registry that serves sample, ready-to-use devfiles. Set it if you use an external devfile registry (see the externalDevfileRegistry field).

externalDevfileRegistry

false

Instructs the Operator to deploy a dedicated Devfile registry server. By default a dedicated devfile registry server is started. If externalDevfileRegistry set to true, the Operator does not start a dedicated registry server automatically and you need to set the devfileRegistryUrl field manually.

externalPluginRegistry

false

Instructs the Operator to deploy a dedicated Plugin registry server. By default, a dedicated plug-in registry server is started. If externalPluginRegistry set to true, the Operator does not deploy a dedicated server automatically and you need to set the pluginRegistryUrl field manually.

nonProxyHosts

omit

List of hosts that should not use the configured proxy. Use |` as delimiter, for example localhost|my.host.com|123.42.12.32 Only use when configuring a proxy is required (see also the proxyURL field).

pluginRegistryImage

omit

Overrides the container image used in the Plugin registry deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.

pluginRegistryMemoryLimit

256Mi

Overrides the memory limit used in the Plugin registry deployment.

pluginRegistryMemoryRequest

16Mi

Overrides the memory request used in the Plugin registry deployment.

pluginRegistryPullPolicy

Always for nightly or latest images, and IfNotPresent in other cases

Overrides the image pull policy used in the Plugin registry deployment.

pluginRegistryUrl

the Operator sets the value automatically

Public URL of the Plugin registry that serves sample ready-to-use devfiles. Set it only when using an external devfile registry (see the externalPluginRegistry field).

proxyPassword

omit

Password of the proxy server. Only use when proxy configuration is required.

proxyPort

omit

Port of the proxy server. Only use when configuring a proxy is required (see also the proxyURL field).

proxyURL

omit

URL (protocol+host name) of the proxy server. This drives the appropriate changes in the JAVA_OPTS and https(s)_proxy variables in the Che server and workspaces containers. Only use when configuring a proxy is required.

proxyUser

omit

User name of the proxy server. Only use when configuring a proxy is required (see also the proxyURL field).

selfSignedCert

false

Enables the support of OpenShift clusters with routers that use self-signed certificates. When enabled, the Operator retrieves the default self-signed certificate of OpenShift routes and adds it to the Java trust store of the Che server. Required when activating the tlsSupport field on demo OpenShift clusters that have not been setup with a valid certificate for the routes.

serverMemoryLimit

1Gi

Overrides the memory limit used in the Che server deployment.

serverMemoryRequest

512Mi

Overrides the memory request used in the Che server deployment.

tlsSupport

false

Instructs the Operator to deploy Che in TLS mode. Enabling TLS requires enabling the selfSignedCert field.
Property Default value Description

chePostgresDb

dbche

PostgreSQL database name that the Che server uses to connect to the database.

chePostgresHostName

the Operator sets the value automatically

PostgreSQL Database host name that the Che server uses to connect to. Defaults to postgres. Override this value only when using an external database. (See the field externalDb.)

chePostgresPassword

auto-generated value

PostgreSQL password that the Che server uses to connect to the database.

chePostgresPort

5432

PostgreSQL Database port that the Che server uses to connect to. Override this value only when using an external database (see field externalDb).

chePostgresUser

pgche

PostgreSQL user that the Che server uses to connect to the database.

externalDb

false

Instructs the Operator to deploy a dedicated database. By default, a dedicated PostgreSQL database is deployed as part of the Che installation. If set to true, the Operator does not deploy a dedicated database automatically, you need to provide connection details to an external database. See all the fields starting with: chePostgres.

postgresImagePullPolicy

Always` for nightly or latest images, and IfNotPresent in other cases

Overrides the image pull policy used in the PostgreSQL database deployment.

postgresImage

omit

Overrides the container image used in the PostgreSQL database deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.
Property Default value Description

externalIdentityProvider

false

By default, a dedicated Identity Provider server is deployed as part of the Che installation. But if externalIdentityProvider is true, then no dedicated identity provider will be deployed by the Operator and you might need to provide details about the external identity provider you want to use. See also all the other fields starting with: identityProvider.

identityProviderAdminUserName

admin

Overrides the name of the Identity Provider admin user.

identityProviderClientId

omit

Name of an Identity provider (Keycloak / RH SSO) client-id that should be used for Che. This is useful to override it ONLY if you use an external Identity Provider (see the externalIdentityProvider field). If omitted or left blank, it will be set to the value of the flavor field suffixed with -public.

identityProviderImagePullPolicy

Always for nightly or latest images, and IfNotPresent in other cases

Overrides the image pull policy used in the Identity Provider (Keycloak / RH SSO) deployment.

identityProviderImage

omit

Overrides the container image used in the Identity Provider (Keycloak / RH SSO) deployment. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator.

identityProviderPassword

omit

Overrides the password of Keycloak admin user. Override it only when using an external Identity Provider (see the externalIdentityProvider field). Omit or leave empty to set an auto-generated password.

identityProviderPostgresPassword

the Operator sets the value automatically

Password for The Identity Provider (Keycloak / RH SSO) to connect to the database. This is useful to override it ONLY if you use an external Identity Provider (see the externalIdentityProvider field).

identityProviderRealm

omit

Name of an Identity provider (Keycloak / RH SSO) realm. Override it only when using an external Identity Provider (see the externalIdentityProvider field). Omit or leave empty blank to set it to the value of the flavor field.

identityProviderURL

the Operator sets the value automatically

Instructs the Operator to deploy a dedicated Identity Provider (Keycloak or RH SSO instance). Public URL of the Identity Provider server (Keycloak / RH SSO server). Set it only when using an external Identity Provider (see the externalIdentityProvider field).

oAuthClientName

the Operator sets the value automatically

Name of the OpenShift OAuthClient resource used to setup identity federation on the OpenShift side. See also the OpenShiftoAuth field.

oAuthSecret

the Operator sets the value automatically

Name of the secret set in the OpenShift OAuthClient resource used to setup identity federation on the OpenShift side. See also the OAuthClientName field.

openShiftoAuth

true on OpenShift

Enables the integration of the identity provider (Keycloak / RHSSO) with OpenShift OAuth. This allows users to login with their OpenShift login and have their workspaces created under personal OpenShift namespaces. The kubeadmin user is not supported, and logging through does not allow access to the Che Dashboard.

updateAdminPassword

false

Forces the default admin Che user to update password on first login.
Property Default value Description

postgresPVCStorageClassName

omit

Storage class for the Persistent Volume Claim dedicated to the PostgreSQL database. Omitted or leave empty to use a default storage class.

preCreateSubPaths

false

Instructs the Che server to launch a special Pod to pre-create a subpath in the Persistent Volumes. Enable it according to the configuration of your K8S cluster.

pvcClaimSize

1Gi

Size of the persistent volume claim for workspaces.

pvcJobsImage

omit

Overrides the container image used to create sub-paths in the Persistent Volumes. This includes the image tag. Omit it or leave it empty to use the default container image provided by the Operator. See also the preCreateSubPaths field.

pvcStrategy

common

Available options:`common` (all workspaces PVCs in one volume), per-workspace (one PVC per workspace for all declared volumes) and unique (one PVC per declared volume).

workspacePVCStorageClassName

omit

Storage class for the Persistent Volume Claims dedicated to the Che workspaces. Omit or leave empty to use a default storage class.

k8s configuration settings specific to Che installations on Kubernetes

Property Default value Description

ingressClass

nginx

Ingress class that defines which controller manages ingresses.

ingressDomain

omit

Global ingress domain for a K8S cluster. This field must be explicitly specified. This drives the is kubernetes.io/ingress.class annotation on Che-related ingresses.

ingressStrategy

multi-host

Strategy for ingress creation. This can be multi-host (host is explicitly provided in ingress), single-host (host is provided, path-based rules) and default-host.*(no host is provided, path-based rules).

securityContextFsGroup,omitempty

1724

FSGroup the Che Pod and Workspace Pods containers should run in.

securityContextRunAsUser

1724

ID of the user the Che Pod and Workspace Pods containers should run as.

tlsSecretName

omit

Name of a secret that is used to set ingress TLS termination if TLS is enabled. See also the tlsSupport field.

installation defines the observed state of Che installation

Property Description

cheClusterRunning

Status of a Che installation. Can be Available, Unavailable, or Available, Rolling Update in Progress.

cheURL

Public URL to the Che server.

cheVersion

Currently installed Che version.

dbProvisioned

Indicates whether a PostgreSQL instance has been correctly provisioned.

devfileRegistryURL

Public URL to the Devfile registry.

helpLink

A URL to where to find help related to the current Operator status.

keycloakProvisioned

Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been provisioned with realm, client and user.

keycloakURL

Public URL to the Identity Provider server (Keycloak / RH SSO).

message

A human-readable message with details about why the Pod is in this state.

openShiftoAuthProvisioned

Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been configured to integrate with the OpenShift OAuth.

pluginRegistryURL

Public URL to the Plugin registry.

reason

A brief CamelCase message with details about why the Pod is in this state.

Limits for workspaces

Property Default value Description

che.limits.workspace.env.ram

16gb

The maximum amount of RAM that a user can allocate to a workspace when they create a new workspace. The RAM slider is adjusted to this maximum value.

che.limits.workspace.idle.timeout

1800000

The length of time that a user is idle with their workspace when the system will suspend the workspace and then stopping it. Idleness is the length of time that the user has not interacted with the workspace, meaning that one of our agents has not received interaction. Leaving a browser window open counts toward idleness.

Limits for the workspaces of an user

Property Default value Description

che.limits.user.workspaces.ram

16gb

he total amount of RAM that a single user is allowed to allocate to running workspaces. A user can allocate this RAM to a single workspace or spread it across multiple workspaces.

che.limits.user.workspaces.count

1800000

The maximum number of workspaces that a user is allowed to create. The user will be presented with an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.

che.limits.user.workspaces.run.count

1

The maximum number of running workspaces that a single user is allowed to have. If the user has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The user will need to stop a running workspace to activate another.

Limits for the workspaces of an organization

Property Default value Description

che.limits.organization.workspaces.ram

-1

The total amount of RAM that a single organization (team) is allowed to allocate to running workspaces. An organization owner can allocate this RAM however they see fit across the team’s workspaces.

che.limits.organization.workspaces.count

-1

The maximum number of workspaces that a organization is allowed to own. The organization will be presented an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.

che.limits.organization.workspaces.run.count

-1

The maximum number of running workspaces that a single organization is allowed. If the organization has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The organization will need to stop a running workspace to activate another.
Tags: