Remove obsolete deprecation checks#37510
Conversation
This also updates the old-indices check to be appropriate for the 7.x series of releases, and leaves it as the only deprecation check in place.
|
Pinging @elastic/es-core-features |
|
@elasticmachine run the gradle build tests 1 |
|
@elasticmachine test this please |
| if (createdWith.before(Version.V_7_0_0)) { | ||
| return new DeprecationIssue(DeprecationIssue.Level.CRITICAL, | ||
| "index.store.throttle settings are no longer recognized. these settings should be removed", | ||
| "Index created before 7.0", |
There was a problem hiding this comment.
Can you help me understand why indices created prior to 7.0 is a critical (or even an issue), and why are we linking to the 8.0 breaking changes.
The code looks fine, i think i am just missing something here.
There was a problem hiding this comment.
Absolutely: Our policy as listed in the docs is that each Elasticsearch version supports indices created in the previous major version, but any that are older than that can't be used. That is, 6.x can open indices created in 5.x, but not indices created in 2.x - those must be reindexed, either in 5.x before upgrading or using reindex-from-remote.
Due to that, the Deprecations API reports any indices which need to be reindexed before upgrading to the next major version: in 6.x, we'll flag indices which were created in 5.x and need to be reindexed before upgrading the cluster to 7.x.
With this PR, the Deprecations API on 7.x clusters will report any indices that will need to be reindexed before upgrading to the next major version (assumed to be 8.0). This lets us leave at least one check in place as an example, even though there aren't any breaking changes in 8.0 yet (because 8.0 doesn't exist yet).
We may want to switch out the link, as it is kind of making assumptions about the structure of documentation that doesn't exist yet - I could make it point to the page listing the policy about indices created in previous versions for now.
There was a problem hiding this comment.
Thanks for the explains, that makes sense! I think guessing the 8.0 URL is a safe bet and plenty of time to fix it guessed wrong.
|
Thanks for the review, @jakelandis! |
|
@elasticmachine run the gradle build tests 1 please |
1 similar comment
|
@elasticmachine run the gradle build tests 1 please |
|
Failed downloading the machine learning snapshot @elasticmachine run the gradle build tests 1 please |
* elastic/master: (104 commits) Permission for restricted indices (elastic#37577) Remove Watcher Account "unsecure" settings (elastic#36736) Add cache cleaning task for ML snapshot (elastic#37505) Update jdk used by the docker builds (elastic#37621) Remove an unused constant in PutMappingRequest. Update get users to allow unknown fields (elastic#37593) Do not add index event listener if CCR disabled (elastic#37432) Add local session timeouts to leader node (elastic#37438) Add some deprecation optimizations (elastic#37597) refactor inner geogrid classes to own class files (elastic#37596) Remove obsolete deprecation checks (elastic#37510) ML: Add support for single bucket aggs in Datafeeds (elastic#37544) ML: creating ML State write alias and pointing writes there (elastic#37483) Deprecate types in the put mapping API. (elastic#37280) [ILM] Add unfollow action (elastic#36970) Packaging: Update marker used to allow ELASTIC_PASSWORD (elastic#37243) Fix setting openldap realm ssl config Document the need for JAVA11_HOME (elastic#37589) SQL: fix object extraction from sources (elastic#37502) Nit in settings.gradle for Eclipse ...
In 8.0, Elasticsearch will not start in the presence of indices created in 6.x or earlier versions. This adds a related item to the 7.15 deprecation docs. Relates to #37510
There were some deprecation checks which have been obsolete for a while
and needed to be removed before we officially release the next version.
This PR removes those deprecation checks and brings across some minor
utility methods which have been added to 6.x, but not master.