[Deprecation API] Refactor resource deprecation checkers and add new resources.#120505
[Deprecation API] Refactor resource deprecation checkers and add new resources.#120505gmarouli merged 34 commits intoelastic:mainfrom
Conversation
…and other deprecation warnings
…and other deprecation warnings
martijnvg
left a comment
There was a problem hiding this comment.
This looks great 🚀 .
I think only an ResourceDeprecationChecker implementation for composable index templates is missing? And I'm wondering whether we should have something for legacy templates?
dakrone
left a comment
There was a problem hiding this comment.
Generally I think this is a good idea and fits well. I wonder though: should we have a common TemplateDeprecationChecker that works for the template: {…} section of both Composable and Component templates?
I'm not sure whether it's worth trying to inspect legacy templates, especially since we just want people to stop using them anyway.
|
Thank you for your feedback @martijnvg & @dakrone . I also played around with the idea of grouping all the templates together, but then I was afraid for name conflicts. What if we have We could merge the two deprecation warnings under one resource What I am proposing is: This could reduce the footprint of the API and it gives us more flexibility. What do you think? |
dakrone
left a comment
There was a problem hiding this comment.
I left some minor comments, but I think this looks good. I think it would be good also to reach out to the Kibana team to make sure the Upgrade Assistant gets updated to also check the output additions.
Additionally, we need to update the response spec in https://github.com/elastic/elasticsearch-specification/blob/main/specification/migration/deprecations/DeprecationInfoResponse.ts also I think?
...gin/deprecation/src/main/java/org/elasticsearch/xpack/deprecation/DeprecationInfoAction.java
Outdated
Show resolved
Hide resolved
...gin/deprecation/src/main/java/org/elasticsearch/xpack/deprecation/DeprecationInfoAction.java
Show resolved
Hide resolved
...precation/src/main/java/org/elasticsearch/xpack/deprecation/IlmPolicyDeprecationChecker.java
Outdated
Show resolved
Hide resolved
| || containsDeprecatedFilteredAllocationConfig(allocateAction.getInclude()) | ||
| || containsDeprecatedFilteredAllocationConfig(allocateAction.getRequire())) { | ||
| return new DeprecationIssue( | ||
| DeprecationIssue.Level.WARNING, |
There was a problem hiding this comment.
Maybe out of scope for this, but should this be a critical warning, since failure to change this means that the index could fail to allocate on Cloud?
There was a problem hiding this comment.
I was going back and forth on this.
For cloud, I agree this is critical. For self managed, assuming a user is using kibana and UA, I think it's a warning because the user might still be using the data node attribute (which is also a warning).
We could play it safe, and make them all of them critical (including the node attribute), on the combination: data: hot, warm, cold, frozen. It would be more disruptive to users but if the scope is this narrow maybe we can be more assertive. What do you think?
| return null; | ||
| } | ||
| return new DeprecationIssue( | ||
| DeprecationIssue.Level.WARNING, |
There was a problem hiding this comment.
Same here for critical level? What do you think?
In #120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In elastic#120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In elastic#120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In elastic#120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In #120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In #120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In #120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
In elastic#120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`. In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
While preparing for 9.0, we want to add deprecation warnings when we encounter the usage of filtered allocation implementing tiers.
We encounter this setting in many places:
The deprecation API already supports checking the index settings. In this PR:
templateswhich contains component and composable index templates, and ILM policies. We do not check the legacy templates considering that they are already deprecated.We applied a refactoring to make the extension of the deprecation API easier. In this refactoring we introduced
ResourceDeprecationCheckerwhich is a checker that is dedicated to a resource type and groups the deprecation warnings by the resource name.Considering that the component and composable templates have settings, we add them as well in the process of removing skipped settings.
Relates to ES-10298
Post-merge
templates,ilm_policieskibana#208496).