ContributionsMost RecentNewest TopicsMost LikesSolutionsAdding Taints to Pod level As of L2023.3, in Sisense’s Helm Charts , “Tolerations” are supported by the micro-services. It prevents end-users from configuring “Taints” on the node that they want to dedicate to Sisense. Since no “Taints” are configured, so all nodes can become eligible to host Sisenses’s pods. They experienced that scenario when pods from some other application services were scheduled on a Sisense node. Would you please consider allowing the pods to be protected not only with “Toleration” but also with “Taints”. The justification for this is that, even though it is mentioned in prerequisites documents that Sisense should be installed on dedicated servers, there is a non-negligible factor from the customers perspective that is the overhead administrative costs, especially for customers who must already manage numerous clusters for several applications, multiple environments, and redundancy. Selection of default CSI for Persistent Storage 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. Retrieving logs via File management Would you consider allowing the retrieval of files from the nodes with the file management so that end-users can retrieve logs with having ssh access. Recompiling views There are cases where the Sisense queries have to read from views. Would you consider allowing to issue queries like “ALTER database.materializedView REBUILD” instead of only allowing select commands, in this case this would allow to refresh data that would be selected by the jdbc connector. JDBC connector - Kerberos Some end-users have strict environmental and security constraints for their operations. Please consider including M.I.T. Kerberos binaries and environment variable so that JDBC connectors could leverage Kerberos without having to access Kubernetes hosts machines. Helm Charts - Flexibility of features 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.