We'd like to be able to annotate our bld pods using the helm provisioner. Annotation we're wanting to apply: karpenter.sh/do-not-disrupt: "true" Per Sisense support:  "If we are discussing the -bld- pods, it’s important to note that their configuration cannot be overridden manually. These pods are dynamically generated by the Management service, and the logic for their creation and configuration is embedded within the Management service code. As such, direct modifications to their configuration are not supported." ... View more

We have found that if an ACL in a WAT does not match the Elasticube table/column security field, it defaults to providing 'all data'. To avoid a potential human error where a table/column has been renamed, we would like the default position to be 'nothing'.  ... View more

It would be interesting to be able to modify livenessProbe and readinessProbe values in Sisense Provisioner's Helm charts (chart.png).   Currently, the values are hardcoded in the deployment charts. It is therefore not possible for us to change the values using a value file (configuration.png). ... View more

Idea: Allow developers to build/test add-ons in a local environment rather than requiring a live environment. Note that this would be for the purpose of creating custom add-ons for additional functionality that would require testing on the "out of the box" Sisense UI. Background/Context: In most development workflows it is common practice to work on your code locally on your machine and deploy to a local server aka "localhost" to test/view your work in the browser. An example of this is building and deploying a local React.js app to your browser. As you make changes to the code it will recompile locally and update what you see on your localhost. If you're using Sisense out of the box however, to test/view any changes to an add-on developers are forced to upload the files in some way to a live Sisense Environment. This not only limits the innovation of add-ons to developers with an active license and live environment, it makes it painfully inefficient to develop customizations on top of the Sisense application. I understand there are likely some business concerns with allowing the use of the product locally but I'd argue that there are ways to prevent that, such as enforcing some default sample data etc., but in such a way that would give developers a "local playground" to develop/innovate on. ... View more

The helm chart supplied with Sisense allows global annotation of all service accounts within the sisense namespace. For example I can annotate an AWS role that is able to be assumed by pods: helm upgrade sisense ${sisense_chart} --namespace sisense \ --reuse-values \ --set global.serviceAccountAnnotations."eks\.amazonaws\.com/role-arn"=${pod_role_arn} While this covers most of the pods by updating all the sisense-* service accounts in kubernetes the ec-build pod (the one that actually builds the elasticube) only uses the default service account in the sisense namespace. A workaround is to annotate the default service account: kubectl annotate serviceaccount default eks.amazonaws.com/role-arn=${pod_role_arn} --namespace sisense But it seems odd that the pod would a) assume the default service account when all other pods have service accounts explicitly defined for them and b) despite having gone to the trouble of wiring up global service account annotations in helm for them not to be applied at the final step of elasticube building. This specific use case is for supplying web identity tokens to a JDBC driver so that you can interact with AWS by using a specific OIDC assumed pod role, rather than using an EC2 role or worse, static credentials in a file or connection string. Even more specifically using CData JDBC parquet driver with S3.   ... View more

It would have been great if there was a quicker way to update the SSL certificates on the Sisense server without having to run the update install. There are clients who do not wish to provide internet connection on the server once Sisense install is complete. As I understand it, if Sisense was installed with internet connection on, then we need to have internet connection in order to re-run the installer successfully. So we will have to make a request to the client to provide internet connection again to run the update install. It would have been good if there was an alternative way to update the SSL certificate.  ... View more

Please enable the possibility of selecting a default CSI (storage class interface)  from a set of existing CSIs so that it may be used as default Sisense persistent storage option. This is is a necessary feature for persistence of storage in cases such as autonomous cluster scaling or rebalancing, as well as disaster recovery.   ... View more

Some end-users have several environments where they must provision Sisense and they strive to standardize and automate the processes as much as possible for efficiency. It would be great to be able to extend standardization and potential automation of configuration to the Helm Chart level: Please include some ways to enable feature or disable feature with the helm chart so that if we want to enable file management everywhere we could provide a value to all our helm charts so we can have uniform configuration. ... View more

Hi. It would be cool to have a possibility do use external RabbitMQ instead one provided with Sisense Provisioner and hosted in Kubernetes cluster as StatefulSet. We would like to use managed rabbit cluster from AWS. The same case could be for MongoDB with AWS Document DB. ... View more