Clarifications on 'no downtime' during upgrades #1421
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@shainaraskas , this looks good to me, just a few comments for your review:
|
There was a problem hiding this comment.
to address @eedugon's comments:
- linking, or being more precise about what the minimum node configuration is, is a good idea
- kibana link: we could be more precise about the kibana downtime thing, but the other upgrade doc is specific to self-managed might be misleading. Edu, in future, we could maybe use a snippet to reuse this info if you think it's helpful for the other deployment types
provided some suggestions to address this stuff
Comment on lines
+23
to
+24
|
|
||
| During the Kibana instances upgrade, Kibana is inaccessible. |
There was a problem hiding this comment.
I don't think this notice should be in this same important block because the two subjects aren't really related. I'd do this as an additional paragraph instead - see my other comment
| @@ -16,10 +16,12 @@ products: | |||
|
|
|||
| Once you are [prepared to upgrade](/deploy-manage/upgrade/prepare-to-upgrade.md), a single click in the {{ecloud}} console can upgrade a deployment to a newer version, add more processing capacity, change plugins, and enable or disable high availability, all at the same time. During the upgrade process, {{es}}, {{kib}}, Elastic APM, and all of your deployment components are upgraded simultaneously. | |||
|
|
|||
| You can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. | |||
| For HA (high availability) deployments, you can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. | |||
There was a problem hiding this comment.
small edit to add a HA link and move the kib info
Suggested change
| For HA (high availability) deployments, you can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. | |
| For [HA (high availability) deployments](//deploy-manage/production-guidance/availability-and-resilience/resilience-in-ech#ec-ha), you can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. However, when {{kib}} instances are upgraded, all instances are shut down simultaneously, making {{kib}} inaccessible. | |
| {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. |
you say in your overview that it's only single-AZ deployments subject to downtime. our HA definition states something slightly different. would it make sense to be more precise? this is a bad edit but shows you kind of what I mean
Suggested change
| For HA (high availability) deployments, you can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. | |
| For deployments with nodes in more than one availability zone, you can perform minor version upgrades, upgrades from 8.18 to 9.0.0, and cluster configuration changes with no downtime. Deployments with nodes in only one zone might experience downtime. | |
| When {{kib}} instances are upgraded, all instances are shut down simultaneously, making {{kib}} inaccessible. | |
| {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current wording suggests that no downtime is expected during upgrades whatever the deployment topology is.
Non-HA deployments (on single AZ) are subject to downtime as the Elasticsearch node upgrade happens inline with a rolling change.
Also for Kibana upgrade, all Kibana instances are shutdown simultaneously which makes Kibana inaccessible during the Kibana upgrade plan whatever the zone distribution is.