The previous cube farm is not removed after the successful "Replace All build" [Linux]
In certain cases, performing a ‘Replace All’ build in Sisense results in the persistence of multiple cube farms. Specifically, after a successful build, the system retains both the newly created cube farm and the previous one, which should have been deleted automatically. This anomaly leads to storage bloat and potential confusion in managing cube versions.
After executing several ‘Replace All’ builds, administrators observed that two cube farms remain in the storage path. One is the new build with the current timestamp, and the other is the previous build, which should have been removed.
Symptoms:
Two directories (farms) remain on disk under the /opt/sisense/storage/tenants/<tenant_id>/farms directory.
The older farm is not detached or deleted.
Example:
New cube: <cube farm name>_2025.03.27.14.03.37.669
Old cube (still attached): <cube farm name>_2025.03.27.13.23.06.057
Step-by-step guide:
To check what farm is currently attached, please use the 'elasticubes list' command from CLI (here is the documentation on how to access Sisense CLI:
https://docs.sisense.com/main/SisenseLinux/using-sisense-cli-commands.htm)
The build log indicates:
[DEBUG] delete /opt/sisense/storage/.../<cube farm name>_2025.03.27.14.03.37.669/ElastiCubeTransactionLog.info
This implies that Sisense attempts to delete the newly created cube farm instead of the old one, which is likely due to a misidentification of which cube is obsolete.
Additional indicators:
No indication in the logs that the previous farm is being unmounted or deleted.
The delete operation returns NumberOfTouchFilesDeleted: [0], showing no actual cleanup occurred.
Resolution:
1. Access Sisense Configuration Manager (https://docs.sisense.com/main/SisenseLinux/configuration-manager-sisense-documentation.htm)
2. Click 5 times on the Sisense logo to access the hidden configuration.
3. Go to the Management configuration and ensure the ‘TimeToWaitForPodToStart (seconds)’ parameter is set to 2400 (the default value).
Conclusion:
With this guide, the user will know where the ‘TimeToWaitForPodToStart (seconds)’ parameter is located and how it should be adjusted.
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.
