This release includes recipes for building container images and Helm charts for the following products.
- Spotfire Server 14.4.1
- Spotfire Web Player 14.4.1
- Spotfire Automation Services 14.4.1
- Spotfire Enterprise Runtime for R - Server Edition 1.21.1
- Spotfire Service for R 1.21.1
- Spotfire Service for Python 1.21.1
The recipes are validated with the listed Spotfire products and versions. They could work with other Spotfire versions with modifications.
Version mapping table:
| Chart name | Chart version | appVersion | Image tag |
|---|---|---|---|
| spotfire-platform | 0.3.0 | See below | See below |
| spotfire-server | 0.3.0 | 14.4.1 | 14.4.1-1 |
| spotfire-webplayer | 0.3.0 | 14.4.1 | 14.4.1-1 |
| spotfire-automationservices | 0.3.0 | 14.4.1 | 14.4.1-1 |
| spotfire-terrservice | 0.3.0 | 1.21.1 | 1.21.1-1 |
| spotfire-rservice | 0.3.0 | 1.21.1 | 1.21.1-1 |
| spotfire-pythonservice | 0.3.0 | 1.21.1 | 1.21.1-1 |
Changes
-
TSCDK-391 The previously available chart
spotfire-umbrella-examplehas been moved and renamed.
The chart has been renamed tospotfire-platformand it has been moved from examples to helm/charts.
The version has been modified to align with the rest of the charts.
In addition, the postgresql chart has been disabled by default. This means that you must have a value ofpostgresql.enable = truefor the spotfire-platform chart to work out-of-box. -
TSCDK-410 The example on installing with a new database in the spotfire-server README file has been updated to include
--set primary.resourcesPreset=smallas a parameter for the postgresql database pod, to eliminate multiple checkpoints and restarts. -
TSCDK-431 When building images on an ARM instruction set machine, the Docker engine downloads versions of applications on an ARM64 basis.
This created two problems:- Dependencies are installed in non-canonical paths.
- ARM-based software is installed. But the images are intended to run on an x86/64-based Kubernetes cluster.
These issues are now fixed.
-
TSCDK-446 On the Spotfire Server, Information Services action logs are not pruned, which can lead to a "full disk".
This issue has now been addressed by implementation of a rolling file configuration for Information Services action logs, in the `log4j2-is.xml´ file. This ensures that the logs are pruned and managed efficiently, preventing disk space from being exhausted.