Aktualizace scénářů
- Správa scénářů
- jak funguje upgrade scénářů
- vysvětlit všechny možnosti co se může stát a jak postupovat
- jak funguje upgrade scénářů
Jak probíhá aktualizace scénářů když běží runy. Text bude koncepčně OK, ale chce to projít a doupravit.
Upgrading Scenarios to new version is one of the most common operations. The process consists of updating the Scenario artifact and applying the changes correctly. The exact steps depend on the situation, mostly on the fact whether the new version is compatible with the previous and if the Scenario is running.
The Scenario artifact will be provided by us, with it you’ll get information about the
compatibility. At the moment there is no way to find yourself whether the scenario is compatible or
not. When you get the artifact simply put in in ENV/scenarios/ and replace the previous artifact.
When you install the deployment the new version of the Scenario will be loaded.
However, if the new version is incompatible and if there’s at least one Run of the upgraded Scenario, you have to perform additional tasks. Such upgrade requires you to intervene and make sure the Run works with the new version of the Scenario. This is required because the old state of the Run is not compatible with the new Scenario, therefore it would break when upgraded. Note that if the new version is compatible or if there’s no Run you don’t have to perform any additional tasks, just install the deployment and you are done.
Upgrading incompatible Run can be done in various ways, we call them upgrade strategies. Currently we fully support only one strategy - forward-only. However, two strategies are described below and you can also come up with your own. The forward-only strategy is guaranteed to work with any Scenario, for specific Scenarios there might be more efficient or simpler strategies. The strategy ensures the new Scenario never uses the old state, which was created by the previous Scenario.
The forward-only strategy is quite simple - all data are recomputed from start. The old run is removed and new run recomputes the state from scratch. The process is as follows.
- Stop the old Run.
- Install the deployment with the new Scenario artifact.
- Revert and delete the old Run.
- Start a new run from the beginning or from the required time.
The parameters of the new Run are mostly up to you, they don’t have to be the same as the old Run if
you don’t need it that way. For example, you can change start_from if you don’t need the full
history.
However, if the Scenario generates notifications you most likely don’t want to send old
notifications that were already sent. In that case use notifications_from: System.os_time(:millisecond), this will ensure only new notifications are sent.
The continuation strategy is slightly more complicated and doesn’t work as well. The gist of this strategy is that we keep the results of the previous Run and the new Run will continue where the old finished. The steps are as follows.
- Stop the old Run.
- Install the deployment with the new Scenario artifact.
- Start a new run to continue from where the last left off.
The new run must be started with output_actions_from: System.os_time(:millisecond), therefore it
continues where the last Run finished. However, this may be problematic in some cases. For example,
if the incident IDs were to change (due to change in logic) the new data would not match the old,
and some old incidents could be stuck open without a way to close them.
The start_from of the new Run can be adjusted as is needed. It basically specifies for how long
the Run should be in learning phase, where it consumes and processes data but doesn’t produce any
side effects. You can use the same start_from as the previous run, but some Scenarios don’t need
long training time.
