Best practice of setting up sandbox instances

You can optimize sandbox instances provisioning by overriding the default behavior.

Audience: Cluster administrator and application developers

WaziSandboxSystem and WaziSandboxVolumeCopy

Sandbox provides the following Custom Resources:

WaziSandboxSystem: Creates personal z/OS® sandbox system for development and testing. This Custom Resource fulfills the main functionality of Sandbox.
WaziSandboxVolumeCopy: Copies z/OS volume files for use with Sandbox. You can use this Custom Resource to optimize sandbox instances provisioning.

Why using WaziSandboxVolumeCopy

When you use WaziSandboxSystem Custom Resource to create sandbox instances, by default, the sandbox instance is created with a new PersistentVolumeClaim. Sandbox calls a PersistentVolumeClaim with the labels "cloud-ready Sandbox z/OS volume image" or "cloud-ready image" for short. Using a new PersistentVolumeClaim means that the instance will copy ADCD volume files from the configured SFTP server. However, the transfer from SFTP server to Sandbox storage might take some time to complete.

Therefore, instead of having the sandbox instance copy the file from SFTP during sandbox instance provisioning, the best practice is to let a cluster administrator or a developer to create a cloud-ready image from SFTP with WaziSandboxVolumeCopy Custom Resource before using WaziSandboxSystem to create sandbox instances. If a single sandbox instance is needed, the cloud-ready image can then be used with WaziSandboxSystem. If multiple sandbox instances are needed, that cloud-ready image can be served as a base to create more cloud-ready images, either by using CSI Volume Cloning, if available, or by using WaziSandboxVolumeCopy again if cloning is not available. For more information, see Copying volume files with WaziSandboxVolumeCopy.

Best practice of using WaziSandboxSystem and WaziSandboxVolumeCopy

The relevant instructions are summarized as follows.

Table 1. Best practice to create a single or multiple sandbox instances
	Task	For detailed instructions, see...	Notes
1	Create a `PersistentVolumeClaim`	Creating PersistentVolumeClaims in Kubernetes documentation	Why to create a PersistentVolumeClaim manually
2	Use `WaziSandboxVolumeCopy` to convert the `PersistentVolumeClaim` to a cloud-ready image by copying volumes from an SFTP server.	Copying volumes from an SFTP server	Prepare a cloud-ready image for future faster sandbox instance provisioning
3	Use `WaziSandboxVolumeCopy` or CSI volume cloning to create one or more cloud-ready images by copying from the following sources: An existing cloud-ready image in the same namespace that is created in the previous step. An SFTP server. This is in essence to repeat the previous step.	To copy volumes from an existing cloud-ready image in the same namespace: If CSI Volume Cloning is supported in your cluster and storage, see Cloning volumes from an existing PersistentVolumeClaim. If CSI Volume Cloning is not supported, create a `PersistentVolumeClaim` and convert it to cloud-ready image by Copying volumes from an existing PersistentVolumeClaim. To copy volumes from an SFTP server: Create a `PersistentVolumeClaim` and convert it to cloud-ready image by Copying volumes from an SFTP server.	This is relevant if you want to create multiple sandbox instances from the same image. Compared with simply repeating the previous step of copying from an SFTP server, more choices are provided. Consider the following aspects when you make choice. Speed Among all the three options, cloning volumes from an existing `PersistentVolumeClaim` is the fastest. The speed of the other two copying approaches varies, depending on the network connection and storage on Red Hat® OpenShift®. Required resources Copying volumes from an existing cloud-ready image requires an existing `PersistentVolumeClaim` in the same namespace, which takes Red Hat OpenShift storage and costs if applicable.
4	Use `WaziSandboxSystem` to create a sandbox instance. Specify the following fields in the Custom Resource file. `zVolumes.existingClaimName`: The cloud-ready image created in the previous step `copyVolumes`: `false`	Creating a sandbox instance with WaziSandboxSystem	This overrides the default behavior and prevents `WaziSandboxSystem` from creating a PersistentVolumeClaim. By using a cloud-ready image created in previous steps, the PersistentVolumeClaim is ready for a developer to use immediately when the developer creates a sandbox instance.