Skip to content

Clarifications on 'no downtime' during upgrades #1421

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −1
Open

Clarifications on 'no downtime' during upgrades #1421

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion deploy-manage/upgrade/deployment-or-cluster/upgrade-on-ech.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


::::{important}
Although it’s simple to upgrade an {{ecloud}} deployment, the new version might include breaking changes that affect your application. Ensure you review breaking changes and deprecation logs, make any necessary changes, and test against the new version before upgrading your production deployment.

During the Kibana instances upgrade, Kibana is inaccessible.
Comment on lines +23 to +24
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

::::

## Perform the upgrade [perform-cloud-upgrade]
Expand Down
Loading