You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: migration/README.md
+13-10Lines changed: 13 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,26 +10,26 @@ This directory contains the upgrade and migration steps for each major and minor
10
10
Notice to developers on writing migration steps:
11
11
12
12
- Migration steps:
13
-
- are written per major and minor version and placed in a subdirectory of the migration directory with the name `main/`,
13
+
- are written for every major and minor version and placed in a subdirectory of the migration directory with the name `main/`,
14
14
- during release this is promoted to the next release series `vX.Y/`,
15
15
- are written to be idempotent and usable no matter which patch version you are upgrading from and to,
16
16
- are documented in `main/README.md` to be able to run them manually,
17
17
- are divided into prepare and apply steps:
18
18
- Prepare steps:
19
19
- are placed in the `prepare/` directory,
20
-
- may **only** modify the configuration of the environment,
21
-
- may **not** modify the state of the environment,
20
+
- may **only** modify the configuration of an environment,
21
+
- may **not** modify the state of an environment,
22
22
- steps are run in order of their names using two digit prefixes.
23
23
- Apply steps:
24
24
- are placed in the `apply/` directory,
25
-
- may **only** modify the state of the environment,
26
-
- may **not** modify the configuration of the environment,
25
+
- may **only** modify the state of an environment,
26
+
- may **not** modify the configuration of an environment,
27
27
- are run in order of their names using two digit prefixes,
28
28
- are run with the argument `execute` on upgrade and should return 1 on failure and 2 on successful internal rollback,
29
29
- are rerun with the argument `rollback` on execute failure and should return 1 on failure.
30
30
31
-
[Prepare snippets](main/prepare) are supposed to update the environment configuration to the target version, an example snippet is the init step which runs the `ck8s init` command.
32
-
[Apply snippets](main/apply) are supposed to update the environment application to the target version, and example snippet is the apply step which run `helmfile upgrade` on all releases that have changed.
31
+
[Prepare snippets](main/prepare) are supposed to update the environment's configuration to the target version, an example snippet is the init step which runs the `ck8s init` command.
32
+
[Apply snippets](main/apply) are supposed to update the environment's applications to the target versions, and example snippet is the apply step which run `helmfile upgrade` on all releases that have changed.
33
33
It is expected that releases upgraded in other snippets are excluded from the apply snippet.
34
34
35
35
> [!tip]
@@ -65,10 +65,13 @@ This script expects the `ROOT` environment variable to be set pointing to the ro
65
65
As with all scripts in this repository `CK8S_CONFIG_PATH` is expected to be set.
66
66
67
67
> [!important]
68
-
> Since the migration snippets should be idempotent, and usable from and to any patch version, it is important that they only perform actions when needed, especially in the case of destructive actions!
68
+
> Since the migration snippets should be idempotent and usable from and to any patch version, it is important that they only perform actions when needed, especially in the case of destructive actions!
69
69
>
70
70
> Example: if a major upgrade of a component requires that another component is temporarily removed, then it should **only** remove the component if there is a major upgrade in the first place, if there is a minor upgrade then it should be applied without removing the component.
71
71
72
+
We also need them to be idempotent to be able to reuse them between release series, for example to update Grafana, OpenSearch, Prometheus, or Thanos, if not covered by the general apply snippet.
73
+
Some snippets will still be specific to a specific version and those snippets should be named with the suffix `-version-specific.sh` to easily identify them.
74
+
72
75
## Preparing migration steps for releases
73
76
74
77
When releasing new major or minor versions of Welkin Apps the current upgrade and migration directory should be promoted to the one for the release.
@@ -80,5 +83,5 @@ To do this run:
80
83
81
84
This script will create a new directory for the `vX.Y` release series from the `main` directory, and prune old directories to only include the latest five releases.
82
85
83
-
Once the new directory is created you must manually remove snippets and steps that was specific for the new release, be sure to remove any exclusions from them set in the `80-apply-sh` snippet based on the tip in the previous section.
84
-
General migration steps, such as snippets for upgrading OpenSearch, Prometheus, or Thanos, may be retained as long as they verify beforehand they run that they are needed, and fall back to a generic upgrade steps if not required.
86
+
Once the new directory is created you must manually remove snippets and steps that was specific for the new release named with the suffix `-version-specific.sh`, be sure to remove any exclusions from them set in the `80-apply.sh` snippet based on the tip in the previous section.
87
+
General migration steps, such as snippets for upgrading Grafana, OpenSearch, Prometheus, or Thanos, may be retained as long as they verify beforehand they run that they are needed, and fall back to a generic upgrade steps if not required.
0 commit comments