Troubleshooting Sisense helm provisioner [Linux]

Step-by-Step Guide: 

Sisense Helm Provisioner is a Kubernetes job that runs the Sisense installer, skipping the Kubernetes installation part. As it runs within the container, it already has all the dependencies that usually need to be satisfied on a Linux bastion. Thus, it runs on the cluster and instead of a dedicated bastion, you can use even macOS or Windows terminal as soon as you have ‘helm’ and ‘kubectl’ installed and configured for your Kubernetes cluster.

1. Checking Provisioner logs

When the Helm Provisioner fails, check the logs of the container first if there is an obvious reason for the issue, e.g, a typo in the values.yaml, etc.

kubectl logs -f --namespace $NAMESPACE -l app.kubernetes.io/name=provisioner

If the logs in not detailed enough and you need to see more information on the issue, consider enabling debug mode for the Provisioner. 

2 . Enabling Debug Mode

The Helm Provisioner supports debug options, which are crucial when you need to dig into configuration or log output:

• Enable Sleep Mode:
  Set debug.sleepMode: true in your values file. This will pause the provisioner pod after completion or failure, allowing you to kubectl exec into the running container and inspect its environment:

debug:

  sleepMode: true

• Enable Verbose Logging:
  Increase Ansible verbosity (which the provisioner uses under the hood) with:

debug:
  verbose:
    enabled: true
    level: 3  # Set the desired verbosity level (e.g., 1 for -v, 2 for -vv, 3 for -vvv)

With these flags, logs should contain more detailed information about the provisioning steps and errors.

3. Joining the Provisioner Container

To execute the container for debugging, run:

kubectl exec -n sisense -it $(kubectl get pods -n sisense -l app.kubernetes.io/name=provisioner --output=jsonpath={.items..metadata.name}) -- /bin/bash

You can find the provisioner in the ‘/app’ folder. The “installer”  subfolder contains the code of the provisioner itself, and the “configuration” subfolder contains the installation values. 

After applying the required changes on ‘installer’ and/or ‘configuration’, or can reinitialize the Provisioner by running “/app/bootstrap.sh” 

Alternatively, you can check the exact command that fails or temporary files, generated helm values, etc. 

Conclusion

The Helm Provisioner is a good choice for deploying Sisense on Kubernetes, simplifying the installation process. When issues arise, checking the Provisioner logs can reveal immediate problems, while enabling debug mode offers deeper insights into errors. Joining the Provisioner container allows for direct interaction, enabling necessary adjustments and reinitialization. These troubleshooting steps empower users to effectively resolve challenges, ensuring a smoother deployment experience.

References/Related Content 

• https://docs.sisense.com/main/SisenseLinux/installing-sisense-using-provisioner-and-helm.htm

Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.