Configuring Red Hat OpenShift Dev Spaces

The Red Hat OpenShift Dev Spaces Administration Guideopen in new window covers all the required steps for checking prerequisites, preparing the installation, installing, and configuring the running environment. This page will cover some special considerations for Z Open Editor and Zowe Explorer use cases.

Configuration suggestions

Public Open VSX server

The default installation of OpenShift Dev Spaces uses a built-in instance of the Open VSX VS Code extensions marketplace. However, Z Open Editor and Zowe Explorer are not included in this registry so they cannot be found from within a running a workspace. An easy workaround is to switch Dev Spaces to use the public https://open-vsx.orgopen in new window site instead, which is documented in the Administration Guideopen in new window.

If you are running your OpenShift cluster in an air-gapped installation or without a public gateway then it is possible to add these and other extensions to the so-called "plugin registry" of Dev Spaces, which is described hereopen in new window.

Image Puller

The Kubernetes Image Puller is used for caching images on a cluster. It creates a separate Pod downloading and running the relevant container on each node. This allows for faster start up times for Dev Spaces workspaces. You need to collect a list of image names that you want to cache. In particular you want to list the latest IBM image that you find listed here: https://github.com/IBM/wazi-devspaces-imagesopen in new window

Installing the Image Puller on x86 based OpenShift Container Platform Cluster: The Community Operators Catalog contains the Kubernetes Image Puller available on x86 based Clusters. You can use the web console to install the Kubernetes Image Puller and configure the Dev Spaces custom resource based on the requirements that are specified on this pageopen in new window.
Installing the Image Puller on s390x based OpenShift Container Platform Cluster: The Kubernetes Image Puller cannot be installed using the Operator Hub on s390x based OpenShift Container Platform clusters. Therefore, it would be required to install and configure the Kubernetes Image Puller using the CLI by following the instructions that are listed hereopen in new window.

The you can configure the image puller as described in the Red Hat documentationopen in new window. If you have a custom image you want to use for Dev Spaces that is located in a private image registry that requires a pull secret then you need to create such as secret first in the openshift-operators namespace. Such a secret could look like this:

kind: Secret
apiVersion: v1
metadata:
  name: devworkspace-container-registry-dockercfg
  namespace: openshift-operators
data:
  .dockerconfigjson: <some base64 string>
type: kubernetes.io/dockerconfigjson

The .dockerconfigjson is the base64 encoding of the secret. For a container registry in the IBM Cloud it would in a format such as this

{
  "auths": {
    "jp.icr.io": {
      "username": "iamapikey",
      "password": "some-apikey",
      "auth": "some-auth-value"
    }
  }
}

See the OpenShift manualopen in new window for more details on pull secrets.

Once you have the secret in place you can list it in the che instance. Open the Che instance resource file and edit the image puller specification sections. For example,

imagePuller:
  enable: true
  spec:
    imagePullSecrets: devworkspace-container-registry-dockercfg
    images: "idzee=jp.icr.io/phaumer/ibm-wazi-for-devspaces-sidecar@sha256:5c073fabe1c016d67e19fa6155caf910fdf89c2ec0467178b34877dfa576c987"

The images section is a list with a random lowercase name following the image name. You can list many images separated by a ;. If your images do not require pull secrets then you can leave those out.

Configuring Git integrations

OpenShift Dev Spaces provides many different ways of integrating with various Git-server technologies such as GitHub, GitLab, and Bitbucket. The Administration Guideopen in new window provides instructions for how to configure identities and authorizations to these servers provides by administrators.

In addition the Dev Spaces User Guide covers many scenarios for using Git repositories, such as how to use these centrally managed authenticationsopen in new window, work with access tokensopen in new window, defining your personal Git configurationsopen in new window, and many more. This documentation also has a section on managing secrets that has content related to Git.

Other useful configuring settings

There are many parameters in the Dev Spaces custom resource to configure Dev Spaces behavior. The Administration Guideopen in new window has a complete reference of all parameters.

The following table lists some commonly used parameters that we found useful for Z Open Editor and Zowe Explorer that you could explore first. Note, that some of these can have a big impact on resource usage and cost of operation:

Parameter	Description
`maxNumberOfRunningWorkspacesPerUser`	The maximum number of running workspaces per user. The value, -1, allows users to run an unlimited number of workspaces.
`secondsOfInactivityBeforeIdling`	Idle timeout for workspaces in seconds. This timeout is the duration after which a workspace will be idled if there is no activity. To disable workspace idling due to inactivity, set this value to `-1`.
`startTimeoutSeconds`	The amount of time a workspace startup times out. The default value of 300 seconds sometimes needs to be increase when pulling very large images with a slow network connection to the registry.
`storage`	Workspaces persistent storage strategy. See below for more details.

To get a complete list of parameters used to configure and customize your workspace, see hereopen in new window.

Common issues

Storage

We see that administrators deploying Dev Spaces on OpenShift fail to provide storage for their OpenShift clusters that meet the storage class requirements specified. In addition to providing the correct storage classes it also necessary to set the matching storage strategy settings for the Dev Spaces operation. See the Configuring storage sectionopen in new window of the administrator guide for details. Also read the OpenShift Understanding persistent storageopen in new window documentation page for more background. For the optimal user experience we recommend "ReadWriteMany" storage with a "per-workspace" or "per-user" strategy.

Other resources

A collection of important references for maintaining and using Red Hat OpenShift Dev Spaces to be shared with the end users as well.

# Configuring Red Hat OpenShift Dev Spaces

# Configuration suggestions

# Public Open VSX server

# Image Puller

# Configuring Git integrations

# Other useful configuring settings

# Common issues

# Storage

# Other resources