Configure 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 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 https://open-vsx.orgopen in new window site instead, as documented in the Administration Guideopen in new window.

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 hereopen in new window.

Image Puller

The Kubernetes Image Puller is used for caching images on a cluster. It creates a separate Pod, which downloads and runs the relevant container on each node. This allows 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 here: https://github.com/IBM/wazi-devspaces-imagesopen in new window

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 pageopen in new window.
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 hereopen in new window.

Configure the image puller as described in the Red Hat documentationopen in new window. 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 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.

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 Guideopen in new window 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 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.

Configure the Dashboard

The OpenShift Dev Spaces documentation describes how you can customize the Dashboard with additional example tilesopen in new window.

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

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

Clone the repo or copy the scripts in the "config" folder.
Determine if you installed Dev Spaces in the "openshift-operators" namespace (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 Guideopen in new window provides complete reference of all the parameters.

The following table lists some commonly used parameters that we find 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, 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 idles, 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 increased 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 deploy Dev Spaces on OpenShift fail to provide storage for their OpenShift clusters that meet the storage class requirements specified. 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 sectionopen in new window in 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 to maintain and use Red Hat OpenShift Dev Spaces, is shared with the end users as well.

# Configure Red Hat® OpenShift Dev Spaces

# Configuration suggestions

# Public Open VSX server

# Image Puller

# Configure Git integrations

# Configure the Dashboard

# Other useful settings to configure

# Common issues

# Storage

# Other resources