Configuring Red Hat OpenShift Dev Spaces

The Red Hat OpenShift Dev Spaces Administration Guide covers all the required steps to check the prerequisites, prepare the installation and configure how to run the environment. This page covers 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. Z Open Editor and Zowe™ Explorer are included in this registry, but the versions available might be three months behind the currently available release as Dev Spaces is refreshed only once a quarter. An easy workaround is to switch Dev Spaces to use the public site Open VSX instead, as documented in the Administration Guide.

If you run your OpenShift cluster in an air-gapped installation or without a public gateway, it is possible to add these and other extensions to the so-called "plugin registry" of Dev Spaces, as described here.

Image Puller

The Kubernetes Image Puller is used to cache images on a cluster. It creates a separate Pod, which downloads and runs the relevant container on each node. This enables for faster start up times for Dev Spaces workspaces. 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 at https://github.com/IBM/wazi-devspaces-images.

Install the Image Puller on x86 based OpenShift Container Platform Cluster: The Community Operators Catalog contains the Kubernetes Image Puller available on x86 based Clusters. 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 page.
Install 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 is required to install and configure the Kubernetes Image Puller using the CLI. Follow the instructions listed here.

Configure the image puller as described in the Red Hat documentation. If you have a custom image 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 looks 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 is in a format such as this

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

See the OpenShift manual for more details on pull secrets.

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

Configure Git integrations

OpenShift Dev Spaces provides many different ways to integrate with various Git-server technologies such as GitHub, GitLab, and Bitbucket. The Administration Guide provides instructions on how administrators configure identities and authorizations to these servers.

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

Configure the Dashboard

The OpenShift Dev Spaces documentation describes how you can customize the Dashboard with additional example tiles.

To add to your dashboard an example tile for Z Open Editor and its devfile sample, a simple script is provided based on those instructions, which you can use as is. It contains the data for the icon and links to the "zopeneditor-sample" Git repository used in the sections above.

The sample is provided in the images Git repository at https://github.com/IBM/wazi-devspaces-images that is discussed in Create and use custom images.

Clone the repository or copy the scripts in the "config" folder.
Determine if you installed Dev Spaces in the "openshift-operators" namespace by default or followed the Red Hat® documentation and installed it in "openshift-devspaces".
Adjust the "add-sample.sh" script to use the correct namespace.
Logon to your cluster with "oc".
Run the "add-sample.sh" script.
Refresh the dashboard.
If the new sample does not appear then check the logs of your "devspaces-dashboard" pod for any errors.

Other useful settings to configure

There are many parameters in the Dev Spaces custom resource to configure Dev Spaces behavior. The Administration Guide provides complete reference of all the parameters.

The following table lists some commonly used parameters that are useful for Z Open Editor and Zowe Explorer, which you can 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, enables users to run an unlimited number of workspaces.
`secondsOfInactivityBeforeIdling`	Idle timeout for workspaces in seconds. This timeout is the duration after which a workspace idles, if there is no activity. To disable workspace idling due to inactivity, set this value to `-1`.
`startTimeoutSeconds`	The amount of time after a workspace startup times out. The default value of 300 seconds sometimes needs to be increased when you pull 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 here.

Common issues

Storage

If cluster administrators fail to configure OpenShift clusters with storage that meets the storage class requirements as specified in the Red Hat documentation then deploying Dev Spaces can fail. In addition to provide the correct storage classes, it is also necessary to set the matching storage strategy settings for the Dev Spaces operation. See the Configuring storage section in the administrator guide for details. Also read the OpenShift Understanding persistent storage documentation page for more background. For the optimal user experience, "ReadWriteMany" storage with a "per-workspace" or "per-user" strategy is recommended.

Other resources

A collection of important references to maintain and use Red Hat OpenShift Dev Spaces, is shared with the end users as well.