-
Notifications
You must be signed in to change notification settings - Fork 25.2k
[Deprecation API] Refactor resource deprecation checkers and add new resources. #120505
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.
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
[Deprecation API] Refactor resource deprecation checkers and add new resources. #120505
Conversation
…and other deprecation warnings
…and other deprecation warnings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here for critical level? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gmarouli for improving the deprecation API!
LGTM
… new resources (#120505) (#121016) * [Deprecation API] Refactor resource deprecation checkers and add new resources. #120505 * Fix test * Fix test --------- Co-authored-by: Lee Hinman <[email protected]>
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:
templates
which 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
ResourceDeprecationChecker
which 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_policies
kibana#208496).