-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
When upgrading, if the installer doesn't detect a service installation, we should:
- Warn the customer that any previously installed/custom service will still refer to their old binaries as we didn't update them. This is a dangerous situation: they should remove any previously deployed services as rebooting their server with such scripts deployed might cause damage to their Stash home
- Give the customer an option to install the service with our standard service scripts. That way, customers will be able to start a newly deployed service and that will be supported for their instance's lifetime.
This is important because this document is not the same as what the current service script deployed by the Linux installer does.
Customer Story: As of Stash 3.8 an upgrade workflow was introduced in the Stash installer. When using the installer and following the upgrade workflow, the installer is unable to detect and therefore update custom previously deployed Stash services on both Windows and Linux environments. If a customer has a service set up previously done by our installer, the upgrade path will work and update the binaries it needs to start/stop the newly upgraded instance. Therefore, when the upgrade workflow is finished, starting/stopping Stash using the "old" (or custom services/scripts) will work normally for the operations team. If the installer doesn't detect the expected service installations, however, it should warn the customers that previously installed/custom service installations will still be referring to their old binaries as we don't update them. From here we should warn them:
|
- mentioned in
-
Page Loading...