Skip to content

[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

Merged
merged 34 commits into from
Jan 28, 2025

Conversation

gmarouli
Copy link
Contributor

@gmarouli gmarouli commented Jan 21, 2025

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:

  • index settings
  • component templates
  • index templates
  • legacy templates
  • ILM policies.

The deprecation API already supports checking the index settings. In this PR:

  • We add another check to the index settings check.
  • We extend the response of the API to include 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

Copy link
Member

@martijnvg martijnvg left a 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?

Copy link
Member

@dakrone dakrone left a 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.

@gmarouli
Copy link
Contributor Author

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 logs component template and logs composable index template, then the json won't be valid (not the way we have it now at least).

We could merge the two deprecation warnings under one resource logs, one for component template and one for the composable index template.

What I am proposing is:

{
  "index_settings": .....,
  "templates": {
     "deprecated_template_1": [
         {}, <- deprecation warning for component template
         {} <- deprecation warning for index template
     ]
  }
  "ilm_policies": {
     "deprecated_policy_1": [
     ],
    "deprecated_policy_2": [
     ]
  }
}

This could reduce the footprint of the API and it gives us more flexibility. What do you think?

@gmarouli gmarouli requested a review from dakrone January 23, 2025 16:38
@gmarouli gmarouli marked this pull request as ready for review January 23, 2025 16:38
@elasticsearchmachine elasticsearchmachine added the needs:triage Requires assignment of a team area label label Jan 23, 2025
Copy link
Member

@dakrone dakrone left a 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?

|| containsDeprecatedFilteredAllocationConfig(allocateAction.getInclude())
|| containsDeprecatedFilteredAllocationConfig(allocateAction.getRequire())) {
return new DeprecationIssue(
DeprecationIssue.Level.WARNING,
Copy link
Member

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?

Copy link
Contributor Author

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,
Copy link
Member

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?

Copy link
Member

@martijnvg martijnvg left a 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

@gmarouli gmarouli merged commit 7322015 into elastic:main Jan 28, 2025
16 checks passed
@gmarouli gmarouli deleted the handle-9/deprecate-node-attrs-v2 branch January 28, 2025 11:00
elasticsearchmachine pushed a commit that referenced this pull request Jan 29, 2025
… 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]>
gmarouli added a commit that referenced this pull request Mar 27, 2025
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.
gmarouli added a commit to gmarouli/elasticsearch that referenced this pull request Mar 27, 2025
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.
gmarouli added a commit to gmarouli/elasticsearch that referenced this pull request Mar 27, 2025
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.
gmarouli added a commit to gmarouli/elasticsearch that referenced this pull request Mar 27, 2025
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.
elasticsearchmachine pushed a commit that referenced this pull request Mar 27, 2025
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.
elasticsearchmachine pushed a commit that referenced this pull request Mar 27, 2025
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.
elasticsearchmachine pushed a commit that referenced this pull request Mar 27, 2025
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.
omricohenn pushed a commit to omricohenn/elasticsearch that referenced this pull request Mar 28, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/Indices APIs APIs to create and manage indices and templates >enhancement Team:Data Management Meta label for data/management team v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants