Keep the pod configuration defined after Sisense update
In our use case, we need to modify the configuration of certain pods such as exporting, external-plugins, and exporter-xlsx using the kubectl edit command. We have noticed that with each Sisense version upgrade, these changes are lost — meaning the configuration values revert to their default, pre-modification state. Would it be possible to retain these modifications after a Sisense version upgrade?
WAT and ACL Security Model - Default to no access
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'.
Quick way to update SSL certificate
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.Global ElastiCube Builds Schedule Report
Currently there’s no way on the Sisense UI to have an overview of when the next ElastiCube Builds are set for. Having such info available would make it possible to easily select relevant time slots to run load testing scripts for instance, but also more broadly to help understand and finetune the current Builds orchestration. In order to do so, we would like for admin roles to have access to a single table-like page that would list all the Builds scheduled in the next 24 hours with the following columns: ElastiCube name Build start date Build theoretical end date* Last successful Build duration * Build theoretical end date = Build start date + Last successful Build duration * (or NULL in the rare event where the Build has never succeeded before) Additional features: CSV Export Sort option on column headers Pagination Note: a single Elasticube can have more than one entry (in the example below, we assume the admin user opens the page at 3:00 PM and the ElastiCube_B's Build is launched every 2 hours).
Different database connections on staging server vs production server
Hi, We have two cloud servers in Sisense: one for development (staging) and one for production. The staging server connects to our staging database. The production server connects to our production database. All cubes and dashboards are identical except for database connection strings and names. Our Git branching strategy follows these steps: Create a feature branch from staging. Make changes and push them to the feature branch. Open a pull request from the feature branch to staging. Test changes in staging. If approved, merge staging into master (production) to deploy changes. The Issue Git integration tracks database connection names, meaning both servers must either run on staging data or production data—this is not feasible for us. Proposed Solution We suggest implementing a decentralized environmental variable for storing database connections. For example: Use {database-server-name} as a placeholder in configurations. Set database-server-name = db_server_staging on staging. Set database-server-name = db_server_production on production. This would allow the same codebase to dynamically connect to the appropriate database without manual adjustments. Would love to hear your thoughts on this!
Bld Pod Annotation
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."Customizable LivenessProbe and ReadinessProbe in Helm Chart
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).
Add functionality to limit RAM usage (Windows)
Windows Sisense currently has no way for us as administrators to control how much ram is being used by elasticubes. From looking at the community site, it appears that linux has a way to do this through data groups, but when consulting with support, I have been told to increase our resources, simplify our models, etc. The big problems that we have observed at my company is that 1. Sisense seems to take up the resources it is given - when ram is increased, usage percentage stays at the same level 2. If something does go wrong and resources begin to get consumed, there are no guard rails in place to stop whatever incident is happening from taking down the whole server This second case has happened only a few times in the years we have had Sisense, but I don't like that I have no way to be proactive about these issues.
Here are some improvements looking for better usability
1. View all history of builds and its corresponding logs from the cubes. Because, I could not see the last build failure reason, if another build got started. I need to wait for another build to complete or fail. 2. View all history of changes and provide a way to revert as in Google docs for both the cubes and dashboards. Some times, if something went wrong, we should just be able to revert to the previous version and continue from there. 3. Provide a way to view the list of cubes in the queue waiting for the build. Also, allow remove or disable them for a period or rearrange the queue to build. This will help in prioritizing something manual on demand. 4. If a cube build fails due to the memory or other configurations issue, provide suggestions like what has to be changed and based on what before triggering another build. 5. Provide a page to derive the suggested the configurations like memory, cpu, timeouts etc by collecting details like 1. Number of cubes, 2. average cube size, max cube size, min cube size, or number of cubes by size range say <5g, <10G, <20G, <40G etc.., 3. Frequency of the build per cube etc.. 6. Provide a page to view all the slow running dashboards, slow running queries and some suggestions to improve it. 7. Some times, if a dashboard got changed and republished, it is not getting applied to all the users. Provide a way to view the version of the dashboard the user may view. 8. Between builds, if there is not much change in the data, Sisense build should go faster. Provide a way like one common place to build each table from other sources individually and keep it ready. From there, if we build say functional cubes, it should build in flashing fast using the locally stored data. I see the cubes are pulling the data faster from relational db but very slow from mongodb. Now, if we are pulling data from another sisense cube or from the source no big performance difference. 9. Also, I am not sure, if we are restarting the nodes, should we necessarily mark the cubes in queue as failed, instead adding back to the queue as it was before the restart and just marking the actual cube got failed should be good enough. More later .. Thanks, Muthusamy J
Simply Ask modified NLQ model import-export within a *.dash file
Current behavior of the Simply Ask feature doesn't support automatic saving of the modified NLQ model to the "*.dash" file. So you loose your development work after exporting the dashboard with already enabled and tuned "Simply Ask" to a "*.dash" file. After importing this dashboard back to Sisense the feature is automatically disabled. Also if a developer will enable it manually it starts running based on the "By Default" NLQ model. This forces to redo all the work on the model back again which is time consuming and not efficient. We expect Sisense to consider in the future the development work on making this more convenient for a BI engineer. If a "Simply Ask" feature will be automatically enabled on an imported dashboard with a corrected model, it would be beneficial for dashboard deploy automation and will reduce unneeded additional manual work on setting up this feature again and again for different working environments for the same dashboard.