Bonsai has been around for a long time and has supported every major release of Elasticsearch since 0.20 (late 2012). Over the years, Bonsai has rolled out support for a number of versions of Elasticsearch, and in the process developed a time-tested, standardized approach.
When a new version of Elasticsearch is released, we will subsequently deprecate the oldest public version. This is to ensure that we can provide excellent support and reliable operational responses to any incident that may arise.
Dedicated Clusters Exempt!
Clusters in single tenant environments — Business, Enterprise, Dedicated, etc — are not affected by this version upgrade policy. These clusters will remain operational and unaffected by new releases unless/until the owner wishes to upgrade.
A quick summary of Bonsai’s version support policy is as follows:
- Bonsai supports the two most recent major versions on Hobby and Standard tier clusters.
- Bonsai does not automatically upgrade existing clusters when new Elasticsearch versions are released, or when old versions are retired.
- Bonsai offers long-term version support for older major versions of Elasticsearch for Business and Enterprise tier clusters.
- Hobby tier clusters always default to the cutting edge when available.
- Hobby tier clusters are the first to be upgraded.
- Clusters on EOL nodes (see below) will not be serviced and will receive limited technical support.
- Bonsai does not force upgrades, except in cases involving a major security issue. These are rare, and typically patch-level upgrades.
How Bonsai Handles New Version Rollouts
Bonsai will first deploy and validate the new version. Then, when our operations team is satisfied that it safe and reliable for production use, we will begin defaulting new clusters to the latest version.
Clusters running on our oldest supported version receive several notifications about next steps.
The general process is:
- Deploy the new version and make it the default for Hobby clusters. Users with paid clusters can also opt in to the new version where available
- Validate that the latest version is safe for production, and ensure our operational tooling is adequate to respond to any incident that may arise
- Default all new clusters to the latest version
- Deprecate the oldest version:
- Send a notice several weeks in advance to all impacted users, alerting them of the deprecation and providing instructions and guidance for upgrading
- Send a final notice several days in advance to any impacted user who still has not upgraded
- Migrate remaining clusters to the next supported version
- Terminate nodes running the deprecated version
There are some caveats and exceptions here, based on the cluster’s plan level:
Hobby Clusters
These clusters are generally reserved for non-production purposes, like for hobbyists and students, PR-apps and the like. As a result, they are always the first candidates for version upgrades, as well as the first to be mass migrated off of deprecated versions.
In other words, when a Bonsai deploys a new version of Elasticsearch, Hobby clusters will be the first to default to the new version where available. This is one way we can validate performance and safety with minimal risk to production applications.
In a version deprecation, these clusters are also the first to be migrated off of the deprecated version up to the next supported version. Data loss or mapping changes are not common during these events, but are a distinct possibility.
As unpaid resources, we are unable to accommodate special treatment regarding this process. For example, if a user is on a free cluster and requests an extension to prepare, we will not be able to accommodate.
Standard tier Clusters
These clusters are running in multitenant environments, meaning the system resources are shared among many users. We’re not able to selectively upgrade, downgrade or “pin” clusters to a version in these environments. Changing versions literally involves migrating the cluster to another set of servers.
Users who are not able to upgrade to a new version of Elasticsearch have the option of upgrading to a Business or Enterprise tier plan. With these plans, we will provision a new isolated environment running whatever version of Elasticsearch is required, and migrate the cluster there. This obviates the need to worry about future version deprecations.
One other possibility for users who can’t upgrade either their cluster’s plan or Elasticsearch version is to remain on EOL nodes. This approach comes with some risks, which are described below.
Business and Enterprise tier Clusters
Clusters on these plans are running in isolated environments and generally not affected by version rollouts and deprecations on Bonsai. Major version upgrades for these clusters are by request only. Minor version upgrades may be made in the event of a vulnerability disclosure.
For example, if an Enterprise cluster is running on version X.Y.0, and a critical vulnerability is disclosed, we will work with the customer to establish a service window, deploy the patched version, and then perform a rolling restart. Service impacts are generally trivial and without down time.
Otherwise, Business and Enterprise tier clusters are not affected by version deprecations on Bonsai.
What are EOL Nodes?
An EOL node is a server running a version of Elasticsearch that Bonsai no longer supports. It has reached its End Of Life (EOL) and may be terminated at any time, for a variety of reasons. When that happens, our Ops Team will not replace it or address any resulting service interruption or data loss. Additionally, our Support Team will provide limited technical support for issues arising from being on an old version.
When a version of Elasticsearch is officially deprecated by Bonsai, clusters running on that version will be upgraded to the next supported version. In some cases, we will allow users to remain on the unsupported version with the caveat that their cluster is running on EOL nodes. Users with clusters on these resources accept all risks and responsibilities.
Some examples:
- In the event that a security regression is disclosed, we may choose to promptly terminate EOL nodes without advance notice.
- In the event of irrecoverable failure of the underlying EC2 instances, we may choose to terminate the EOL nodes without advance notice.
Users running on EOL nodes should actively work to get their application on a supported version as soon as possible to avoid this kind of outcome.