|
5 | 5 | <@tmpl.guide |
6 | 6 | title="Checking if rolling updates are possible" |
7 | 7 | summary="Execute the update compatibility command to check if {project_name} supports a rolling update for a change in your deployment." |
| 8 | +includedOptions="features features-*" |
8 | 9 | > |
9 | 10 |
|
10 | 11 | Use the update compatibility command to determine if you can update your deployment with a rolling update strategy when enabling or disabling features or changing the {project_name} version, configurations or providers and themes. |
@@ -46,15 +47,7 @@ NOTE: If you do not use `--optimized` keep in mind that an `update` command may |
46 | 47 |
|
47 | 48 | [WARNING] |
48 | 49 | ==== |
49 | | -The `check` command currently offers only a limited functionality. At the moment, it takes into consideration only the version of {project_name} and the embedded Infinispan to determine if a rolling update is possible. |
50 | | -If those are unchanged, it reports that a rolling update is possible. |
51 | | -
|
52 | | -The current version does not yet verify configuration changes and assumes all configuration changes are eligible for a rolling update. |
53 | | -The same applies to changes to custom extensions and themes. |
54 | | -
|
55 | | -A good use case when to use this is, for example, when you want to do a rolling update when you change the {project_name} theme or your custom extensions, and only want run recreate update when the version of {project_name} changes which does not yet allow a rolling update. |
56 | | -
|
57 | | -While consumers of these commands should know the limitations that exist today, they should not rely on the internal behavior or the structure of the metadata file. |
| 50 | +Consumers of these commands should not rely on the internal behavior or the structure of the metadata file. |
58 | 51 | Instead, they should rely only on the exit code of the `check` command to benefit from future enhancements on the internal logic to determine when a rolling update is possible. |
59 | 52 | ==== |
60 | 53 |
|
|
143 | 136 | The feature `rolling-updates` is disabled. |
144 | 137 | |=== |
145 | 138 |
|
| 139 | +== Rolling incompatible changes |
| 140 | + |
| 141 | +The following configuration changes return a "Rolling Update is not possible" result code. |
| 142 | + |
| 143 | +=== Features |
| 144 | + |
| 145 | +==== Recreate always |
| 146 | + |
| 147 | +The enabling or disabling of the following features requires a recreate update: |
| 148 | + |
| 149 | +<@showFeaturesRolling ctx.features.updatePolicyShutdown /> |
| 150 | + |
| 151 | + |
| 152 | +==== Recreate on feature version change |
| 153 | + |
| 154 | +Changing the following features versions triggers a recreate update: |
| 155 | + |
| 156 | +<@showFeaturesRolling ctx.features.updatePolicyRollingNoUpgrade /> |
| 157 | + |
| 158 | +=== Configuration options |
| 159 | + |
| 160 | +Changing the value of one of the following CLI options triggers a recreate update: |
| 161 | + |
| 162 | +[cols="30%,70%"] |
| 163 | +|=== |
| 164 | +| Option | Rationale |
| 165 | +| `--cache` | The `ispn` and `local` configurations are mutually exclusive, changing from one to another will lead to data loss. |
| 166 | +| `--cache-config-file` | Changing the configuration file could result in incompatible cache or transport configurations, resulting in clusters not forming as expected. |
| 167 | +| `--cache-stack` | Changing stack will result in the cluster not forming during rolling update and will lead to data loss. |
| 168 | +| `--cache-embedded-mtls-enabled` | Enabling/Disabling TLS will result in the cluster not forming during rolling update and will lead to data loss. |
| 169 | +| `--cache-remote-host` | Connecting to a new remote cache will cause previously cached data to be lost. |
| 170 | +| `--cache-remote-port` | Connecting to a new remote cache will cause previously cached data to be lost. |
| 171 | +|=== |
| 172 | + |
| 173 | +[WARNING] |
| 174 | +==== |
| 175 | +{project_name} does not verify changes to the content of the cache configuration file provided via `--cache-config-file`. |
| 176 | +If you change this file, you need to review and test your changes to ensure that nodes using the new configuration can form a cluster with the nodes running the old configuration. |
| 177 | +If a cluster cannot be formed, you should shut down {project_name} running the old configuration first before migrating to the new configuration. |
| 178 | +==== |
146 | 179 |
|
147 | 180 | [[rolling-updates-for-patch-releases]] |
148 | 181 | == Rolling updates for patch releases |
@@ -177,3 +210,14 @@ Known limitations: |
177 | 210 | The {project_name} Operator uses the functionality described above to determine if a rolling update is possible. See the <@links.operator id="rolling-updates" /> {section} and the `Auto` strategy for more information. |
178 | 211 |
|
179 | 212 | </@tmpl.guide> |
| 213 | + |
| 214 | +<#macro showFeaturesRolling features> |
| 215 | +[cols="30%,70%"] |
| 216 | +|=== |
| 217 | +| Feature | Description |
| 218 | + |
| 219 | +<#list features as feature> |
| 220 | +| [.features-name]#${feature.versionedKey}# | [.features-description]#${feature.description}# |
| 221 | +</#list> |
| 222 | +|=== |
| 223 | +</#macro> |
0 commit comments