Wallaroo Configuration Guide

• 1: DNS Integration Guide
• 2: Model Endpoints Guide
• 3: Manage Minio Storage for Models Storage
• 4: Private Containerized Model Container Registry Guide
• 5: Edge Deployment Registry Guide
• 6: Wallaroo Support Bundle Generation Guide

1 - DNS Integration Guide

The following guide demonstrates how to integrate a Wallaroo Enterprise instance with an organization’s DNS. DNS services integration is required for Wallaroo Enterprise edition. It is not required for Wallaroo Community. This guide is indented to assist organizations complete their Wallaroo Enterprise installation, and can be used as a reference if changes to the DNS services are modified and updates to the Wallaroo Enterprise instance are required.

DNS Services Integration Introduction

DNS services integration is required for Wallaroo Enterprise to provide access to the various supporting services that are part of the Wallaroo instance. These include:

• Simplified user authentication and management.
• Centralized services for accessing the Wallaroo Dashboard, Wallaroo SDK and Authentication.
• Collaboration features allowing teams to work together.
• Managed security, auditing and traceability.

This guide is not intended for Wallaroo Community, as those DNS entries are managed by Wallaroo during the installation. For more information on installing Wallaroo Community, see the Wallaroo Community Install Guides.

Once integrated, users can access the following services directly from a URL starting with the suffix domain - this is the domain name where other DNS entries are appended to. For example, if the suffix domain is sales.example.com, then the other services would be referenced by https://api.sales.sample.com, etc.

Note that even when accessing specific Wallaroo services directly that the user must still be authenticated through Wallaroo.

Connections to Wallaroo services are provided as https://service.{suffix domain}. For example, if the domain suffix is wallaroo.example.com then the URLs to access the various Wallaroo services would be:

• https://wallaroo.example.com
• https://jupyter.wallaroo.example.com
• https://api.wallaroo.example.com
• https://keycloak.wallaroo.example.com

Prerequisites

• Install Wallaroo Enterprise into a qualified environment. For more details, see the Wallaroo Install Guides and the Wallaroo Enterprise Install Guides.
• Determine whether your organization will use a prefix or not as detailed above.
• Have access to the Wallaroo Administrative Dashboard - this requires access to the Kubernetes environment that the Wallaroo instance is installed into.
• Have access to internal corporate DNS configurations that can be updated. A subdomain for the Wallaroo instance will be created through this process.
• Have the IP address for the Wallaroo instance.
• Install kubectl into the Kubernetes cluster administrative node.

Wallaroo IP Address Retrieval Methods

Retrieve LoadBalancer IP with kubectl

For most organizations that install Wallaroo into a cloud based Kubernetes cluster such as Micosoft Azure, AWS, etc the external IP address is tied to Wallaroo Loadbalancer service. This can be retrieved with the kubectl command as follows:

1. Retrieve the external IP address for your Wallaroo instance LoadBalancer. For example, this can be performed through the following kubectl command:

   kubectl get svc  -A
   

   Example Result:

   NAMESPACE     NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                                     AGE
   default       kubernetes                     ClusterIP      10.64.16.1     <none>         443/TCP                                     3d19h
   wallaroo      alertmanager                   ClusterIP      10.64.16.48    <none>         9093/TCP                                    2d22h
   wallaroo      api-lb                         LoadBalancer   10.64.30.169   34.173.211.9   80:32176/TCP,443:32332/TCP,8080:30971/TCP   2d22h
   

   In this example, the External-IP of the wallaroo LoadBalancer is 34.173.211.9. A more specific command to retrieve just the LoadBalancer address would be:

   kubectl get svc api-lb -n wallaroo -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
   

   34.173.211.9
   

   This procedure is appropriate for both clusters that are in external or internal mode.

Other Methods

For organizations install Wallaroo other methods, such as Air Gap or Single Node Linux may find the kubectl get svc api-lb command only returns the internal IP address.

Depending on the instance, there are different methods of acquiring that IP address. The links below reference difference sources.

• AWS: How do I get the ID and IP address of an Amazon EC2 instance for an AWS Batch job?
• GCP: Locating IP addresses for an instance
• Azure: IP addresses in Azure Functions

Refer to your Wallaroo support representative if further assistance is needed.

DNS Integration Steps

To integrate the Wallaroo instance IP address with a DNS service:

1. Create a CA-signed TLS certificate for your Wallaroo domain with the following settings:

   1. Certificate Authority Options:
      1. Use a public Certificate Authority such as Let’s Encrypt or Verisign. In general, you would send a Certificate Signing Request to your CA and they would respond with your certificates.
      2. Use a private Certificate Authority (CA) to provide the certificates. Your organization will have procedures for clients to verify the certificates from the private CA.
      3. Use a Wallaroo certificate and public name server. Contact our CSS team for details.
   2. Subject Domain:
      1. Set the certificate’s Subject CN to your Wallaroo domain.
         1. With Wildcards: To use wildcards, use the wildcard *.{suffix domain}. For example, if the domain suffix is wallaroo.example.com, then the Subject CNs would be:
            1. wallaroo.example.com
            2. *.wallaroo.example.com
         2. If wildcard domains are not desired, use a combination of Subject and Subject Alternative Names to set names as follows:
            1. wallaroo.example.com
            2. api.wallaroo.example.com
            3. jupyter.wallaroo.example.com
            4. keycloak.wallaroo.example.com
   3. Save your certificates.
      1. You should have two files: the TLS Certificate (.crt) and TLS private key (.key). Store these in a secure location - these will be installed into Wallaroo at a later step.

2. Create DNS the following entries based on the list above for the Wallaroo instance’s IP address, updating the domain name depending on whether there is a prefix or not:

   1. api: A (address) record
   2. jupyter: A (address) record
   3. keycloak: A (address) record
   4. Suffix domain: A record, NS (Name Server) record, SOA (Start Of Authority) record.

   For example:

   

3. Access the Wallaroo Administrative Dashboard in your browser. This can be done either after installation, or through the following command (assuming your Wallaroo instance was installed into the namespace wallaroo). By default this provides the Wallaroo Administrative Dashboard through the URL https://localhost:8080.

   kubectl-kots admin-console --namespace wallaroo
   

4. From the Wallaroo Dashboard, select Config and set the following:

   1. Networking Configuration
      1. Ingress Mode for Wallaroo Endpoints:
         1. None: Port forwarding or other methods are used for access.
         2. Internal: For environments where only nodes within the same Kubernetes environment and no external connections are required.
         3. External: Connections from outside the Kubernetes environment is allowed.
            1. Enable external URL inference endpoints: Creates pipeline inference endpoints. For more information, see Model Endpoints Guide.
   2. DNS
      1. DNS Suffix (Mandatory): The domain name for your Wallaroo instance.
   3. TLS Certificates
      1. Use custom TLS Certs: Checked
      2. TLS Certificate: Enter your TLS Certificate (.crt file).
      3. TLS Private Key: Enter your TLS private key (.key file).
   4. Other settings as desired.

   

5. Once complete, scroll to the bottom of the Config page and select Save config.

6. A pop-up window will display The config for Wallaroo Enterprise has been updated.. Select Go to updated version to continue.

7. From the Version History page, select Deploy. Once the new deployment is finished, you will be able to access your Wallaroo services via their DNS addresses.

To verify the configuration is complete, access the Wallaroo Dashboard through the suffix domain. For example if the suffix domain is wallaroo.example.com then access https://wallaroo.example.com in a browser and verify the connection and certificates.

Edge Observability Enablement

For organizations that deploy Wallaroo pipelines on edge devices as Wallaroo Servers, see the DNS settings from the Edge Deployment Registry Guide.

2 - Model Endpoints Guide

Wallaroo provides the ability to perform inferences through deployed pipelines via both internal and external inferences URLs. These URLs allow inferences to be performed by submitting data to the internal or external inferences URL, with the inference results returned in the same format as the InferenceResult Object.

Internal URLs are available only through the internal Kubernetes environment hosting the Wallaroo instance.
External URLs are available outside of the Kubernetes environment, such as the public internet. Authentication will be required to connect to these external deployment URLs.

The following process will enable external inference URLs

1. Enable external URl inference endpoints through the Wallaroo Administrative Dashboard or through helm setup. This can be accessed through the kots or helm as detailed in the Wallaroo Install Guides and the How to Install Wallaroo Enterprise via Helm guides.

   helm users can update the configuration and enable endpoints by setting the apilb\external_inference_endpoints_enabled to true as follows:

   apilb:
       # Required to perform remote inferences either through the SDK or the API
       external_inference_endpoints_enabled: true
   

   For kots users: To access the Wallaroo Administrative Dashboard:

   1. From a terminal shell connected to the Kubernetes environment hosting the Wallaroo instance, run the following kots command:

   kubectl kots admin-console --namespace wallaroo
   

   This provides the following standard output:

     • Press Ctrl+C to exit
     • Go to http://localhost:8800 to access the Admin Console
   

   This will host a http connection to the Wallaroo Administrative Dashboard, by default at http://localhost:8800.

   1. Open a browser at the URL detailed in the step above and authenticate using the console password set as described in the as detailed in the Wallaroo Install Guides.

   2. From the top menu, select Config then verify that Networking Configuration -> Ingress Mode for Wallaroo interactive services -> Enable external URL inference endpoints is enabled.

      

   3. Save the updated configuration, then deploy it. Once complete, the external URL inference endpoints will be enabled.

3 - Manage Minio Storage for Models Storage

Organizations can manage their ML Model storage in their Wallaroo instances through the MinIO interface included in the standard Wallaroo installation.

The following details how to access and the Wallaroo MinIO service. For full details on using the MinIO service, see the MinIO Documentation site.

All of the steps below require administrative access to the Kubernetes service hosting the Wallaroo instance.

Wallaroo MinIO Model Storage

Wallaroo ML Models are stored in the MinIO bucket model-bucket.

Retrieving the Wallaroo MinIO Password

Access to the Wallaroo MinIO service is password protected. DevOps with administrative access to the Kubernetes cluster hosting the Wallaroo instance can retrieve this password with the following:

• The kubectl command.
• The namespace the Wallaroo instance is installed to.

This command takes the following format:

kubectl -n {Wallaroo Namespace} get secret minio -o 'jsonpath={.data.rootPassword}' | base64 -d

For example, if the Wallaroo instance is installed into the namespace wallaroo this command would be:

kubectl -n wallaroo get secret minio -o 'jsonpath={.data.rootPassword}' | base64 -d

Accessing the MinIO Service

Access to the MinIO service in a Wallaroo instance is performed either with the Command Line Interface (CLI), or through a browser based User Interface (UI).

Accessing the MinIO Service Through CLI

Access to the MinIO service included with the Wallaroo instance can be performed with the command line tool mc. For more details, see the MinIO Client documentation.

Installing Minio CLI

The following demonstrates installing the mc command for MacOS and Linux.

Installing for MacOS with Brew

MacOS users who have installed Homebrew can install mc with the following:

brew install minio/stable/mc

Installing for Linux

Linux users can install the MinIO CLI tool mc with the following:

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
sudo mv mc /usr/local/bin/mc

Port Forward for MinIO CLI Access

To access the Wallaroo MinIO service, use Kubernetes port-forward to connect. By default this is on port 9000. This command requires the following:

• The kubectl command.
• The namespace the Wallaroo instance is installed to.

This command is in the following format:

kubectl port-forward services/minio 9000:9000 -n {Wallaroo Namespace}

For example, if the Wallaroo instance is installed to the default namespace wallaroo, this command is:

kubectl port-forward services/minio 9000:9000 -n wallaroo

Show MinIO Disk Usage through CLI

To view the Wallaroo MinIO service through the CLI, the following is required:

• The kubectl command.
• The namespace the Wallaroo instance is installed to.
• The MinIO CLI tool mc.
• The MinIO password.

Here’s an example showing MinIO disk usage via the CLI for the namespace wallaroo. When prompted for the Secret Key, press Enter for none.

The following script displays the space used for a default installation of Wallaroo in the namespace wallaroo.

#!/bin/bash
if kubectl -n wallaroo get secret minio >& /dev/null; then
    u="$(kubectl -n wallaroo get secret minio -o jsonpath='{ .data.rootUser }' | base64 -d)"
    p="$(kubectl -n wallaroo get secret minio -o jsonpath='{ .data.rootPassword }' | base64 -d)"
    creds="$u $p"
fi

mc alias set --insecure wallaroo http://localhost:9000 $creds; mc du --recursive wallaroo

The output:

Added `wallaroo` successfully.
2.2GiB	22 objects	model-bucket
2.2GiB	22 objects

Accessing the MinIO Service Through the UI

The MinIO service included with the Wallaroo instance can be access through the MinIO user interface. By default this is port 9001.

Port Forward for MinIO UI Access

The MinIO UI port 9001 can be access through the kubectl port-forward command.

This command requires the following:

• The kubectl command.
• The namespace the Wallaroo instance is installed to.

This command is in the following format:

kubectl port-forward services/minio-console 9001:9001 -n {Wallaroo Namespace}

For example, to port forward through the default installation namespace wallaroo:

kubectl port-forward services/minio-console 9001:9001 -n wallaroo

Accessing the Wallaroo MinIO UI

Once the port forward command is running, the MinIO UI is access through a browser on port 9001 with the user minio and the MinIO administrative password retrieved through the step Retrieving the Minio Administrative Password.

Viewing General Storage

General disk usage is displayed through Monitoring->Metrics.

Viewing ML Model Storage

ML Models stored for Wallaroo are accessed through the bucket model-bucket.

Select Browse to view the contents of the model-bucket. To determine the specific file name, access the Name of the object and view the Tags. The file name is access via the Tag file-name.

Objects can be deleted from this bucket with the Delete option.

4 - Private Containerized Model Container Registry Guide

Configure Wallaroo with a Private Containerized Model Container Registry

Organizations can configure Wallaroo to use private Containerized Model Container Registry. This allows for the use of containerized models such as MLFlow.

The following steps will provide sample instructions on setting up different private registry services from different providers. In each case, refer to the official documentation for the providers for any updates or more complex use cases.

• Environments:
• GitHub Container Registry
• GCP Artifact Registry
• Generic Containerized Model Registry

REPOSITORY_NAME="YOUR NAME"
LOCATION="us-west1"
DESCRIPTION="My amazing registry."

gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description="$DESCRIPTION" \
    --async

KEY_FILE = ~/.gcp-sa-registry-keyfile.json
KEYFILEBASE64 = ~/.gcp-sa-registry-keyfile-b64.json
base64 -i $KEY_FILE -o $KEYFILEBASE64

5 - Edge Deployment Registry Guide

Wallaroo pipelines can be published to a Edge Open Container Initiative (OCI) Registry Service, known here as the Edge Registry Service, as a container images. This allows the Wallaroo pipelines to be deployed in other environments, such as Docker or Kubernetes with all of the pipeline model. When deployed, these pipelines can perform inferences from the ML models exactly as if they were deployed as part of a Wallaroo instance.

When a pipeline is updated with new model steps or deployment configurations, the updated pipeline is republished to the Edge Registry as a new repo and version. This allows DevOps engineers to update an Wallaroo pipeline in any container supporting environment with the new versions of the pipeline.

Pipeline Publishing Flow

A typical ML Model and Pipeline deployment to Wallaroo Ops and to remote locations as a Wallaroo Inference server is as follows:

• Components:
  • Wallaroo Ops: The Wallaroo Ops provides the backbone services for ML Model deployment. This is where ML models are uploaded, pipelines created and deployed for inferencing, pipelines published to OCI compliant registries, and other functions.
  • Wallaroo Inference Server: A remote deployment of a published Wallaroo pipeline with the Wallaroo Inference Engine outside the Wallaroo Ops instance. When the edge name is added to a Wallaroo publish, the Wallaroo Inference Server’s inference logs are submitted to the Wallaroo Ops instance. These inference logs are stored as part of the Wallaroo pipeline the remote deployment is published from.

1. DevOps:
   1. Add Edge Publishing and Edge Observability to the Wallaroo Ops center. See Edge Deployment Registry Guide for details on updating the Wallaroo instance with Edge Publishing and Edge Observability.
2. Data Scientists:
   1. Develop and train models.
   2. Test their deployments in Wallaroo Ops Center as Pipelines with:
      1. Pipeline Steps: The models part of the inference flow.
      2. Pipeline Deployment Configurations: CPUs, RAM, GPU, and Architecture settings to run the pipeline.
   3. Publish the Pipeline from the Wallaroo Ops to an OCI Registry: Store a image version of the Pipeline with models and pipeline configuration into the OCI Registry set by the DevOps engineers as the Wallaroo Edge Registry Service.
3. DevOps:
   1. Retrieve the new or updated Wallaroo published pipeline from the Wallaroo Edge Registry Service.
   2. (Optional): Add an edge to the Wallaroo publish. This provides the EDGE_BUNDLE with the credentials for the Wallaroo Inference Server to transmit its inference result logs back to the Wallaroo Ops instance. These inference logs are added to the originating Wallaroo pipeline, labeled with the metadata.partition being the name of the edge deployed Wallaroo Inference server. For more details, see Wallaroo SDK Essentials Guide: Pipeline Edge Publication: Edge Observability
   3. Deploy the Pipeline as a Wallaroo Inference Server as a Docker or Kubernetes container, updating the resource allocations as part of the Helm chart, Docker Compose file, etc.

Enable Wallaroo Edge Deployment Registry

Set Edge Registry Service

Wallaroo Pipeline Publishes aka Wallaroo Servers are automatically routed to the Edge Open Container Initiative (OCI) Registry Service registered in the Wallaroo instance. This is enabled through either the Wallaroo Administrative Dashboard through kots, or by enabling it through a helm chart setting. From here on out, we will refer to it as the Edge Registry Service.

Set Edge Registry Service through Kots

To set the Edge Registry Settings through the Wallaroo Administrative Dashboard:

1. Launch the Wallaroo Administrative Dashboard using the following command, replacing the --namespace parameter with the Kubernetes namespace for the Wallaroo instance:

   kubectl kots admin-console --namespace wallaroo
   

2. Open a browser at the URL detailed in the step above and authenticate using the console password set as described in the as detailed in the Wallaroo Install Guides.

3. From the top menu, select Config then scroll to Edge Deployment.

4. Enable Provide OCI registry credentials for pipelines.

5. Enter the following:

   

   1. Registry URL: The address of the registry service. For example: us-west1-docker.pkg.dev.
   2. email: The email address of the user account used to authenticate to the service.
   3. username: The account used to authenticate to the registry service.
   4. password: The password or token used to authenticate to the registry service.

6. Save the updated configuration, then deploy it. Once complete, the edge registry settings will be available.

Set Edge Registry Service through Helm

The helm settings for adding the Edge Server configuration details are set through the ociRegistry element, with the following settings.

• ociRegistry: Sets the Edge Server registry information.
  • enabled: true enables the Edge Server registry information, false disables it.
  • registry: The registry url. For example: reg.big.corp:3579.
  • repository: The repository within the registry. This may include the cloud account, or the full path where the Wallaroo published pipelines should be kept. For example: account123/wallaroo/pipelines.
  • email: Optional field to track the email address of the registry credential.
  • username: The username to the registry. This may vary based on the provider. For example, GCP Artifact Registry with service accounts uses the username _json_key_base64 with the password as a base64 processed token of the credential information.
  • password: The password or token for the registry service.

Set Edge Observability Service

Edge Observability allows published Wallaroo Servers to community with the Wallaroo Ops center to update their associated Wallaroo Pipeline with inference results, visible in the Pipeline logs.

This process will create a new Kubernetes service edge-lb. Based on the configuration options below, the service will require an additional IP address separate from the Wallaroo service api-lb. The edge-lb will require a DNS hostname.

Set Edge Observability Service through Kots

To enable Edge Observability using the Wallaroo Administrative Dashboard for kots installed instances of Wallaroo Ops:

1. Launch the Wallaroo Administrative Dashboard using the following command, replacing the --namespace parameter with the Kubernetes namespace for the Wallaroo instance:

   kubectl kots admin-console --namespace wallaroo
   

2. Open a browser at the URL detailed in the step above and authenticate using the console password set as described in the as detailed in the Wallaroo Install Guides.

3. Access Config and scroll to Edge Deployment and enable Enable pipelines deployed on the edge to send data back to the OpsCenter.

4. Set the following:

   

   1. Specify the OpsCenter hostname or IP address, as reachable from edge sites.: Set the DNS address in the format https://service.{suffix domain}. For example, if the domain suffix is wallaroo.example.com and the Wallaroo Edge Observabilty Service is set to the hostname edge, then the URL to access the edge service is:

      edge.wallaroo.example.com
      

   2. Edge ingress mode: Set one of the following.

      1. None - Services are cluster local and kubernetes port forwarding must be used for access.
      2. Internal - Private network users can connect directly and do not need to port forward anything.
      3. External - Internet facing users can connect directly to interactive Wallaroo services. Exercise caution.

5. Save the updated configuration, then deploy it. Once complete, the edge observability service is available.

6. Set the DNS Hostname as described in the steps Set Edge Observability Service DNS Hostname.

Set Edge Observability Service through Helm

To enable the Edge Observability Service for Wallaroo Ops Helm based installation, include the following variables for the helm settings. For these instructions they are stored in local-values.yaml:

edgelb:
    serviceType: LoadBalancer
    enabled: true
    opscenterHost: mitch4.edge.wallaroocommunity.ninja

pipelines:
    enabled: true

Update the Wallaroo Helm installation with the same version as the Wallaroo ops and the channel. For example, if updating Wallaroo Enterprise server, use the following:

helm upgrade wallaroo oci://registry.replicated.com/wallaroo/ee/wallaroo --version 2023.4.0-4092 --values local-values.yaml

This process will take 5-15 minutes depending on other configuration options. Once complete, set the DNS address as described in Set Edge Observability Service DNS Hostname.

Set Edge Observability Service DNS Hostname

Once enabled, the Wallaroo Edge Observability Service requires a DNS address. The following instructions are specified for Edge ingress mode:External.

1. Obtain the external IP address of the the Wallaroo Edge Observability Service with the following command, replacing the -n wallaroo namespace option with the one the Wallaroo Ops instance is installed into.

   EDGE_LOADBALANCER=$(kubectl get svc edge-lb -n wallaroo -o jsonpath='{.status.loadBalancer.ingress[0].ip}') && echo $EDGE_LOADBALANCER
   

2. Set the DNS address to the hostname set in the step Set Edge Observability Service through Kots if using kots to install, or Set Edge Observability Service through Helm if using helm.

Registry Setup Guides

The following are short guides for setting up the credentials for different registry services. Refer to the registry documentation for full details.

• Environments:
• GitHub Container Registry
• GCP Artifact Registry

docker login -u {Github Username} --password {Your Token} ghcr.io/{Your Github Username or Organization}

REPOSITORY_NAME="YOUR NAME"
LOCATION="us-west1"
DESCRIPTION="My amazing registry."

gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description="$DESCRIPTION" \
    --async

KEY_FILE = ~/.gcp-sa-registry-keyfile.json
KEYFILEBASE64 = ~/.gcp-sa-registry-keyfile-b64.json
base64 -i $KEY_FILE -o $KEYFILEBASE64

token=$(cat $KEYFILEBASE64)
cat $tok | docker login -u _json_key_base64 --password-stdin https://{GCP artifact registry region}.pkg.dev

6 - Wallaroo Support Bundle Generation Guide

To track potential issues, Wallaroo provides a method to create a support bundle: a collection of logs, configurations, and other information that is submitted to Wallaroo support staff to determine where an issue may be and offer a correction.

Support bundles are generated depending on the method of installation:

• kots: If Wallaroo was installed via kots, the support bundle is generated through the Wallaroo Administrative Dashboard.
• helm: If Wallaroo was installed via helm, the support bundle is generated through a command line process.

Generating via Kots

At any time, the administration console can create troubleshooting bundles for Wallaroo technical support to assess product health and help with problems. Support bundles contain logs and configuration files which can be examined before downloading and transmitting to Wallaroo. The console also has a configurable redaction mechanism in cases where sensitive information such as passwords, tokens, or PII (Personally Identifiable Information) need to be removed from logs in the bundle.

To manage support bundles:

1. Log into the administration console.
2. Select the Troubleshoot tab.
3. Select Analyze Wallaroo.
4. Select Download bundle to save the bundle file as a compressed archive. Depending on your browser settings the file download location can be specified.
5. Send the file to Wallaroo technical support.

At any time, any existing bundle can be examined and downloaded from the Troubleshoot tab.

Generating via Helm

If issues are detected in the Wallaroo instance, a support bundle file is generated using the support-bundle.yaml file provided by the Wallaroo support representative.

This creates a collection of log files, configuration files and other details into a .tar.gz file in the same directory as the command is run from in the format support-bundle-YYYY-MM-DDTHH-MM-SS.tar.gz. This file is submitted to the Wallaroo support team for review.

This support bundle is generated through the following command:

kubectl support-bundle support-bundle.yaml --interactive=false