Version specific upgrade instructions
This page provides specific instructions for upgrading to each currently supported version of StackState. The instructions detail any significant changes that may impact how StackState runs after upgrade, such as a change in memory requirements or configuration.
Review the instructions provided below before you upgrade!
No manual action needed.
No manual action needed.
No manual action needed.
No manual action needed.
StackState is tested to run on Kubernetes v1.17, v1.18 and v1.19, or the equivalent OpenShift release (version 4.4, 4.5 or 4.6).
CPU limits have been added to all pods. If you have customized any of the CPU requests in your
values.yaml, you will most likely need to also set the CPU limit for the same pod(s).CPU limits and requests have been re-evaluated and increased where needed for stable operation resulting in a change in the number and size of required nodes.
Two new permissions have been added -
manage-event-handlersandexecute-restricted-scripts:Guest users will no longer be able to create or edit event handlers.
Power Users will no longer be able to execute scripts using the HTTP script API.
Admin users will not be affected.
Baselines have been deprecated and will be removed in v4.4. To reflect this, baseline functions and check functions that use baselines have been renamed. Templates that resolve these functions by name will stop working after upgrade to StackState 4.3. The function identifiers have not changed and can still be used to reference functions, however, it is advised that you migrate to using the Autonomous Anomaly Detector.
A Slack integration StackPack is now available that includes a new Slack event handler. Existing Slack event handlers will continue to run in StackState v4.3, however, the old Slack event handler has been deprecated and will be removed in a future release of StackState. To continue using Slack event notifications, it is advised to install the Slack StackPack and configure view event handlers to use the new Slack event handler in place of the old
Notify via slack for component health state change. (deprecated)andNotify via slack for view health state change.(deprecated).Dynatrace StackPack - The location of the Dynatrace check config file has moved. If you choose to upgrade to the version of the Dynatrace StackPack shipped with StackState v4.3, the Agent check configuration file should also be moved. The new location is
/etc/sts-agent/conf.d/dynatrace.d/conf.yamlthe previous location was/etc/sts-agent/conf.d/dynatrace_topology.d/conf.yaml.
No manual action needed.
No manual action needed.
No manual action needed.
No manual action needed.
Two new permissions have been added -
manage-event-handlersandexecute-restricted-scripts:Guest users will no longer be able to create or edit event handlers.
Power Users will no longer be able to execute scripts using the HTTP script API.
Admin users will not be affected.
Baselines have been deprecated and will be removed in v4.4. To reflect this, baseline functions and check functions that use baselines have been renamed. Templates that resolve these functions by name will stop working after upgrade to StackState 4.3. The function identifiers have not changed and can still be used to reference functions, however, it is advised that you migrate to using the Autonomous Anomaly Detector.
A Slack integration StackPack is now available that includes a new Slack event handler. Existing Slack event handlers will continue to run in StackState v4.3, however, the old Slack event handler has been deprecated and will be removed in a future release of StackState. To continue using Slack event notifications, it is advised to install the Slack StackPack and configure view event handlers to use the new Slack event handler in place of the old
Notify via slack for component health state change. (deprecated)andNotify via slack for view health state change.(deprecated).Dynatrace StackPack - The location of the Dynatrace check config file has moved. If you choose to upgrade to the version of the Dynatrace StackPack shipped with StackState v4.3, the Agent check configuration file should also be moved. The new location is
/etc/sts-agent/conf.d/dynatrace.d/conf.yamlthe previous location was/etc/sts-agent/conf.d/dynatrace_topology.d/conf.yaml.
No manual action needed.
Authentication configuration for the Kubernetes Helm chart has been made easier for this release. If your StackState authentication was customized, it will need to be updated. To verify this, check if there is a stackstate.server.config or stackstate.api.config value that contains an authentication section in the values.yaml file(s) used for installation.
Refer to the Authentication configuration documentation to configure the same settings directly in the values.yaml file. After that, the authentication section can be completely removed. If this results in an empty config value it can be removed as well.
​Node sizing requirements have been increased.
The old
stackstate-serverpod has been replaced by a number of separate pods. Custom configuration invalues.yamlshould be updated:Configured email details in
stackstate.components.server.configshould be moved tostackstate.components.viewHealth.config.Other custom configuration in
stackstate.components.server.configshould be moved tostackstate.components.api.config.
A new mandatory parameter
stackstate.baseUrlhas been added. This is the public URL of StackState (how StackState is reachable from external machines) and is exposed via the UI script API. The filevalues.yamlshould be updated to include the newstackstate.baseUrlparameter. The oldstackstate.receiver.baseUrlparameter has been deprecated and will be removed in a future release, however, when nostackstate.baseUrlis provided in StackState v4.2, the configuredstackstate.receiver.baseUrlwill be used instead.
No manual action needed.
No manual action needed.
The following configuration must be manually added after upgrade:
etc/application_stackstate.conf
New mandatory parameter
stackstate.web.baseUrl. This is the public URL of StackState (how StackState is reachable from external machines) and is exposed via the UI script API. You can manually create a system environment variable calledSTACKSTATE_BASE_URLor add the value manually as a string in the fileapplication_stackstate.conf.
The following configuration changes must be manually processed if you are using a customized version of a file:
etc/stackstate-receiver/application.conf
Renamed the namespace
stackstate. This is nowstackstate.receiver.Renamed the parameter
apiKey. This is now namedapiKeysand should be a list in the format[${stackstate.receiver.key}, ${?EXTRA_API_KEY}].
processmanager.conf
Added new parameter
processes.kafkaToElasticsearch.topology-events.
processmanager/kafka-topics.conf`
Added new section
kafka.topics.sts_topology_events.
Go to the StackState v4.1 docs site.
There are several changes to the processmanager.conf file that must be manually processed if you are using a customized version of this file:
The
sts-healthcheckurihas been moved from port 7071 to 7080The
startup-checkblock has been removed completely
Go to the StackState v4.0 docs site.
With this version the minimal system requirements for the StackState node of the production setup raised from 16GB to 20GB
The configuration
processmanager-properties.confwas merged intoprocessmanager.conffor both StackState and StackGraph. If you have changes to either one of those configuration files, you changes will need to be reapplied after upgrade.For trace processing StackState Agent needs an upgrade to version 2.5.0.
This release deprecates the
withCauseOftopology query filter, in favor of the `RootCause Analysis` topology visualization setting. Stored views
which require make use of the
withCauseOfconstruct will need to be manually adapted.New versions of StackPacks already contain these changes, for custom views, the following
script can be used in the StackState Analytics panel to list the views that need
migrating.
Graph.query { it.V().hasLabel("QueryView").forceLoadBarrier().filter(__.has("query", TextP.containing('withCauseOf'))).properties("name").value() }In this release a new way of scripting propagation functions has been introduced so that the script APIs can be used. Propagation functions using the old script style will still work, but have been made read-only via the UI. Old style propagation functions can still be created via StackPacks, the CLI and API.