{"_id":"5a5574e03f9f210028ac91e1","project":"5633ebff7e9e880d00af1a53","version":{"_id":"5633ec007e9e880d00af1a56","project":"5633ebff7e9e880d00af1a53","__v":16,"createdAt":"2015-10-30T22:15:28.105Z","releaseDate":"2015-10-30T22:15:28.105Z","categories":["5633ec007e9e880d00af1a57","5633f072737ea01700ea329d","5637a37d0704070d00f06cf4","5637cf4e7ca5de0d00286aeb","564503082c74cf1900da48b4","564503cb7f1fff210078e70a","567af26cb56bac0d0019d87d","567afeb8802b2b17005ddea0","567aff47802b2b17005ddea1","567b0005802b2b17005ddea3","568adfffcbd4ca0d00aebf7e","56ba80078cf7c9210009673e","574d127f6f075519007da3d0","574fde60aef76a0e00840927","57a22ba6cd51b22d00f623a0","5a062c15a66ae1001a3f5b09"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"574d127f6f075519007da3d0","project":"5633ebff7e9e880d00af1a53","__v":0,"version":"5633ec007e9e880d00af1a56","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-31T04:26:39.925Z","from_sync":false,"order":4,"slug":"versions","title":"Versions"},"user":"5637d336aa96490d00a64f81","__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2018-01-10T02:05:20.575Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"Bonsai has been around for a long time and has supported every major release of Elasticsearch since 0.20 (late 2012). Over the years, we have rolled out support for a number of versions of Elasticsearch and in the process developed a time-tested, standardized approach.\n\nWhen we roll out a new version of Elasticsearch, 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. Note that clusters in single tenant environments — Dedicated/Business/Enterprise — are not affected.\n\nA quick summary of our version support policy is as follows:\n\n\n- We support the two most recent major versions on Sandbox and Standard tier clusters\n- We offer long-term version support for older major versions of Elasticsearch for Business and Enterprise tier clusters.\n- Sandbox tier clusters always default to the cutting edge when available.\n- Sandbox tier clusters are the first to be upgraded.\n- Clusters on EOL nodes (see below) will not be serviced and will receive limited technical support.\n\n## Upgrade Process\n\nWe deploy and validate new versions first. Then, when we are satisfied that it safe and reliable, we will begin defaulting new clusters to the latest version. Clusters running on our oldest supported version receive several notifications about next steps.\n\nThe general process is:\n\n- Deploy the new version and default Sandbox/Starter/free clusters to it. Users with paid clusters can also opt in to the new version where available\n- Validate that the latest version is safe for production, and ensure our operational tooling is adequate to respond to any incident that may arise\n- Default all new clusters to the latest version\n- Deprecate the oldest version:\n- Send a notice several weeks in advance to all impacted users, alerting them of the deprecation and providing instructions and guidance for upgrading\n- Send a final notice several days in advance to any impacted user who still has not upgraded\n- Migrate remaining clusters to the next supported version\n- Terminate nodes running the deprecated version\n\nThere are some caveats and exceptions here, based on the cluster’s plan level:\n\n## Sandbox and Free Clusters\n\nThese 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.\n\nIn other words, when a Bonsai deploys a new version of Elasticsearch, Starter/Sandbox/free 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.\n\nIn 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. \n\nAs 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. \n\n## Standard tier Clusters\n\nThese 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.\n\nUsers 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.\n\nOne other possibility for users who can’t upgrade either their cluster’s plan or Elasticsearch version is to remain on EOL nodes. In some cases, we will keep a few servers running a deprecated version of Elasticsearch online to accommodate users who need more time. There are risks and consequences for this approach, as outlined below.\n\n## Business and Enterprise Clusters\n\nClusters 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.\n\nFor 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.\n\nOtherwise, Business and Enterprise tier clusters are not affected by version deprecations on Bonsai.\n\n## What are EOL Nodes?\n\nAn 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.\n\nWhen 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.\n\nSome examples:\n\n- In the event that a security regression is disclosed, we may choose to promptly terminate EOL nodes without advance notice.\n- In the event of irrecoverable failure of the underlying EC2 instances, we may choose to terminate the EOL nodes without advance notice.\n\nUsers 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.","excerpt":"","slug":"version-upgrade-policy","type":"basic","title":"Version Upgrade Policy"}

Version Upgrade Policy


Bonsai has been around for a long time and has supported every major release of Elasticsearch since 0.20 (late 2012). Over the years, we have rolled out support for a number of versions of Elasticsearch and in the process developed a time-tested, standardized approach. When we roll out a new version of Elasticsearch, 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. Note that clusters in single tenant environments — Dedicated/Business/Enterprise — are not affected. A quick summary of our version support policy is as follows: - We support the two most recent major versions on Sandbox and Standard tier clusters - We offer long-term version support for older major versions of Elasticsearch for Business and Enterprise tier clusters. - Sandbox tier clusters always default to the cutting edge when available. - Sandbox tier clusters are the first to be upgraded. - Clusters on EOL nodes (see below) will not be serviced and will receive limited technical support. ## Upgrade Process We deploy and validate new versions first. Then, when we are satisfied that it safe and reliable, 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 default Sandbox/Starter/free clusters to it. 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: ## Sandbox and Free 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, Starter/Sandbox/free 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. In some cases, we will keep a few servers running a deprecated version of Elasticsearch online to accommodate users who need more time. There are risks and consequences for this approach, as outlined below. ## Business and Enterprise 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.